Brad Beveridge wrote: > >This is a good observation. I think that the matrix of libraries vs >implementations is probably the only sensible way to find the bugs. > >Cheers >Brad >
I am more than happy to volunteer for the matrix-building sub-project of the ASDF-installability super-project. I have started playing around with ways to represent it, and I don't think the wiki will work. Effectively, we have (make sure you're using a fixed-width font): | pkg | Impl1/p1 | Impl1/p2 | Impl2 | ... | |pkg1 | yep | nope | ??? | ... | |pkg2 | nope | nope | ??? | ... | ... Unfortunately, we will be adding new implementations and platforms on occasion. This means a static table on the wiki will be unmaintainable by hand. Maintaining an authoritative version off-line and updating the wiki periodically will be a maintenance nightmare. Plus, there really should be an opportunity to include tertiary observations by those who do the testing to fill in a cell -- very hard in an HTML table. We really need a better tool for representing the "installability space". If we were to store it in a database somewhere, it would be very easy, then, to automate the generation of "work-units", for us newbies to pick up and play with. If the asdf-install-tester idea works out, then we could plug its output into the database as well. Am I thinking too far ahead? I don't mind building and hosting something like this on one of my domains, unless someone else has a better idea. I'd prefer not to build it if someone knows a free package out there that solves this problem. As always, I claim newbieness as my excuse for being wrong about anything. -Josh Stone- _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
