I've forwarded this ramble onto perl-qa. Seems relevant. One of our goals is to work on the change and review process of Perl and Aegis is a good place to learn from other's mistakes, err, successes. ;) FYI Aegis is a Free CASE tool (automated, enforced change, review and testing) which help coordinate development amongst many programmers. Comparable to something like ClearCASE, but in a different league (nay, a different sport!) than something like CVS. http://www.pcug.org.au/~millerp/aegis/aegis.html It has its problems. On Wed, Mar 14, 2001 at 04:47:23PM -0800, Russ Allbery wrote: > The enforced testing I like a lot; the mechanism by which test suites are > run I don't like at all. I like Perl's a lot better, plus Aegis's > framework seems somewhat less than ideal for developing a Perl module that > needs to be able to run its tests for the end user under make check as > well as for the developer as part of the Aegis cycle. The concepts can be merged fairly easily. See below. > I also didn't really like the "every test is a stand-alone shell script" > model (some of the packages I need testing for are doing unit tests on C > libraries, which means that such a shell script would have to compile a > program and execute it, which seems like a pain). That shell script bit is a white lie. It'll run anything I think. > If you have a moment to ramble on, I'd be very curious about how it's > working for you? Have you run into a lot of problems with it? Oh, I've had more than a moment. aegis-users is probably sick of my "why can't I do *this* in Aegis?" posts. You might want to skim through the archives for my postings: http://groups.yahoo.com/group/aegis-users You'll probably also want to read their (largely biased) CVS Comparison FAQ. It comes with the distribution. Its best facet is the CVS-to-Aegis command listing. To sum up, Aegis is better than nothing for change, review and quality control. As a version control system, its lacking. That's is biggest weakness. They decided to remake a VC system along with everything else rather than just making a wrapper around some existing one. Its very C, shell and Unix oriented out-of-the-box. To make it work with Perl requires some wrappers. Fortunately, they provide hooks for all that. For example, we have our own BlackStar::Test module which has an end() routine. All test scripts (which are otherwise normal MakeMaker style) must call end() which checks to make sure everything ran (ok() simply increments a counter) and then exits with either 0 or 1. Another way to have done that would be to stick a program into the Aegis testing hook which runs the tests, parses the outputs (as Test::Harness) and exits appropriately. Test::Harness will be able to do this soon. So there's plenty of flexibility in the system for Perl and such. Only problem is, everyone's got their own little site-specific setup and there's little work being done writing more generic set-ups for common environments and distributing them with their distribtion. I'm trying to drag them in that direction. If you're a CVS/RCS user, Aegis will prove foreign, yet strangely familiar. Its philosophy is very different, and alot of the features you expect from a decent version control system (file change logs, diffing between any version, cvs annotate, etc...) don't exist because of this philosophical breach. It can get frustrating. I'm working on "Aegis for CVS users" and "Aegis for Perl programmers" tutorials. Maybe I'll try and wedge in a YAPC talk or something. Anyhow, last word. A certain amount of problems come from Aegis itself, but a certain amount comes from switching over to strict review and change control. One of the most annoying at the moment is large-scale refactorings. The system I'm working on has a very, very, very tangled class hiearchy (like, "Let's make the credit card class inherit from the customer class and use the same ID in the database! Then you can ask credit cards what their customer is and their address, etc...") and very, very, very tangled database access (several classes have *no* way to create new objects in the database. Other classes do the INSERT ad-hoc. Nearly all the table schemas are undocumented.) So when I rewrite one function, I inevitably wind up adding several methods to other classes (misplaced functionality that I tore out and encapsulated) along with a few private methods. Not to mention extra tests for those new methods, more tests for the undocumented (yet relied upon) functionality in the now refactored method, documentation for undocumented methods I run into along the way, minor fixes for bits of other classes that were throwing warnings... etc.... All this leads to one mother of a huge change. A huge change which I couldn't have anticipated when I started. Such a huge change is a royal pain in the ass to review (a diligent reviewer could take all day reviewing it, and that's a programmer who doesn't program for that day) and will cause all sorts of conflicts when integrating with other changes. You have to artificially break down that big change into small changes (basically each module that you did a bit of cleanup work on becomes its own change), which isn't hard. The problem is now that your original change (cleaning up the one method) has to wait for all those other changes to get reviewed and integrated before you can go forward. And god forbid if there's interdependencies between your minor changes. And then some of then could fail review and you have to go back through the cycle, etc... So a big "finished" change that took 20 hours of work could stall for an extra week in the split-up-and-review cycle. This is frustrating, but probably for the best. Large-scale refactoring should be carefully reviewed (espcially when the regresion tests are still getting their legs under them as here) and is only necessary in a really messy system. And the messier the system, the more the need for careful review. And the week "lost" is not really lost. Review and coding is still going on, just down different tracks. So an individual change might take more schedule time, but you can work in parallel so overall work is greater. PS I've only been using Aegis now for a few weeks. After this contract, I might launch into rebuilding an Aegis-like system as a wrapper around CVS. The concept is good, the implementation could use a little work. PPS There is a first-cut, read-only Aegis module for Perl. -- Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One grep { ref and ref !~ /^[A-Z]$/ } kill 9, @ARGV;
