Re: Release Engineering initiatives for the XEmacs project

ST> I don't see what the objective of Martin's "release" is. Some of his ST> arguments seem to say "it's a snapshot" but others seem to be "it's a ST> beta release which should work for most testers." And none of them ST> satisfy the industry usage of "a beta version should have high ST> correlation with the next public release and work for most testers." The second of three meanings. ST> I also still think that the emphasis on maximizing the CVS commit rate ST> is misplaced. I see a strong correlation between the fact that Kyle ST> doesn't use CVS (according to Martin) and the high regard in which ST> Kyle's work is held. Code-and-fix sucks; "many eyes, shallow bugs" ST> just mitigates its flaws. Doing a good job is hard, because it ST> requires hard thought. Making it easier to commit is not necessarily ST> good for XEmacs. I don't think there is much correlation between code quality and what mechanism the engineer uses to get the change into the common codebase. ST> If what Martin means by "tinderbox" is ST> 1. A script that basically does ST> # I've been writing Python recently & can't remember proper sh ST> while true: ST> if cvs update && make && make check: ST> then cvs tag -r $CONFIG-$UniqueID ST> (I don't see why this necessarily has to be coordinated across ST> different platforms & configurations, but it would be very nice, of ST> course. This could be done in distributed fashion by having a master ST> machine, the RE's presumably, which would advise volunteer hosts ST> around the net of a success, which would start them trying on that ST> tag.) This tag would be aliased to `xemacs-21-2-latest-beta'. ST> 2. A script that checks for the most recent successful tag starting ST> say 10 days after the last beta release. If that hasn't moved, then ST> wait a day. If on last release + 14 it hasn't moved, the RE steps in ST> and starts trying to fix it in the context of the current CVS tree. ST> 3. When you have a new success in 2, you roll the tarballs and repeat. This method is very ambitious. I think it would be much easier for the release engineer to get accounts on 20 machines around the Net to do automated testing herself. ST> Then I agree that this should get rid of the need for a ST> pre-beta-release commit freeze, and I think it's definitely worth ST> trying as it shouldn't affect the rest of the process. The pre-beta-release commit freeze is gone. I understand how to put out a release with any number of concurrent checkins. ST> Caveat: Martin's "fixing the release is priority one" should apply ST> only to the RE during the trial period for the tinderbox. If this ST> works out pretty well, then the RE can start asking for help from the ST> rest of the core at crunch time. But if the RE can't handle it alone ST> most of the time, you need to ask whether occasional random crunches ST> at the RE's whim are better or worse than moderately frequent ST> scheduled short freezes. ST> And I still think you should call it a "snapshot" (admittedly, a ST> well-tested highly reliable snapshot), not a "release" of any kind. Agreed. `beta' is our historical term. We used to have `alpha's, too. Martin