Re: Release Engineering initiatives for the XEmacs project

I don't see what the objective of Martin's "release" is. Some of his arguments seem to say "it's a snapshot" but others seem to be "it's a beta release which should work for most testers." And none of them satisfy the industry usage of "a beta version should have high correlation with the next public release and work for most testers." I also still think that the emphasis on maximizing the CVS commit rate is misplaced. I see a strong correlation between the fact that Kyle doesn't use CVS (according to Martin) and the high regard in which Kyle's work is held. Code-and-fix sucks; "many eyes, shallow bugs" just mitigates its flaws. Doing a good job is hard, because it requires hard thought. Making it easier to commit is not necessarily good for XEmacs. If what Martin means by "tinderbox" is 1. A script that basically does # I've been writing Python recently & can't remember proper sh while true: if cvs update && make && make check: then cvs tag -r $CONFIG-$UniqueID (I don't see why this necessarily has to be coordinated across different platforms & configurations, but it would be very nice, of course. This could be done in distributed fashion by having a master machine, the RE's presumably, which would advise volunteer hosts around the net of a success, which would start them trying on that tag.) This tag would be aliased to `xemacs-21-2-latest-beta'. 2. A script that checks for the most recent successful tag starting say 10 days after the last beta release. If that hasn't moved, then wait a day. If on last release + 14 it hasn't moved, the RE steps in and starts trying to fix it in the context of the current CVS tree. 3. When you have a new success in 2, you roll the tarballs and repeat. Then I agree that this should get rid of the need for a pre-beta-release commit freeze, and I think it's definitely worth trying as it shouldn't affect the rest of the process. Caveat: Martin's "fixing the release is priority one" should apply only to the RE during the trial period for the tinderbox. If this works out pretty well, then the RE can start asking for help from the rest of the core at crunch time. But if the RE can't handle it alone most of the time, you need to ask whether occasional random crunches at the RE's whim are better or worse than moderately frequent scheduled short freezes. And I still think you should call it a "snapshot" (admittedly, a well-tested highly reliable snapshot), not a "release" of any kind. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."