mb> 3. Use makepatch-generated patches instead of `cvs rdiff' (done). Why is this a good thing? mb> 7. Release some kind of tarball that contains useful packages mb> as well as the C code (details currently being debated). And one for Mule, and one for programmers, and one for DTP, etc .... Wouldn't the effort be better spent making sure the core Lisp contains enough functionality for XEmacs's native pui manager so that the standard procedure of `./configure; make; make install' can, as its last act, drop you into `xemacs -f pui-list-packages' if it doesn't detect an installed package hierarchy? And making pui capable of handling "themes"? People who can't do pui for some reason can fall back to the core tarball plus SUMO approach, or if there's demand for it, a "Konishiki" tarball with absolutely everything in it. mb> 8. Abolish the No-Commit period during releases. The release mb> engineer's computers should, in principle, be able to spend mb> days testing the release before making it official, and other mb> developers should not have to delay their work during this mb> process. What makes you think this is possible? Are there other projects that have done this? What's the point of having weekly (or biweekly) beta "releases" if by the time the tarballs actually get uploaded the active developers all have trees that vary significantly from what the release engineer (RE) is using? How do you handle patches the RE must make to get the thing to build (and pass make check)---and what if it never does? I don't see any particular point in having a "release" that doesn't mean coordinating the various efforts to make sure that the code builds on almost all platforms and passes "make check" on most, with a list of known problem platforms, otherwise you're shipping alpha code to the beta testers. But this really implies either a freeze on non-release-fix commits or a new branch for the RE's fixes (and concommitent merge headaches) for each "release", doesn't it? If you mean a "snapshot," so that people who prefer their alphas a la FTP rather than CVS du hour can get them that way, with no guarantee that they'll build on any platform, no problem. But that doesn't seem to be what you mean (see point 10). I'm also having trouble with the semantics of "developers delay work". Do you mean "developers", or "reviewers"? The former won't notice a few hours or even a couple of days; it's the latter who can't do anything during a freeze. But I thought the point of having frequent "releases" was at least in part to _intentionally_ slow the commit process down every so often so that the reviewers can agree on something something that at least builds and passes tests on some platforms, then start the cycle again. mb> 10. Add a special tag like `xemacs-21-2-latest-beta' for the mb> latest released beta. This is always the latest level of CVS mb> that is *guaranteed* to run `make check' on at least the mb> release engineer's machine. What's special about the RE's machine? What does it mean to have a "release" that only passes tests on one machine? And if it doesn't, then what? You can't guarantee success, even on the RE's box, at regular intervals; you just have to take it when it comes. -- 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."

mb> 8. Abolish the No-Commit period during releases. The release mb> engineer's computers should, in principle, be able to spend mb> days testing the release before making it official, and other mb> developers should not have to delay their work during this mb> process. ST> What makes you think this is possible? Are there other projects that ST> have done this? What's the point of having weekly (or biweekly) beta ST> "releases" if by the time the tarballs actually get uploaded the ST> active developers all have trees that vary significantly from what the ST> release engineer (RE) is using? How do you handle patches the RE must ST> make to get the thing to build (and pass make check)---and what if it ST> never does? I think the trend in free software projects is for the developers to be using CVS, while folks outside the project who are early adopters will get beta releases. So, for example, I am not a gcc developer, but I occasionally get gcc snapshots so that I can check whether our software is compatible with their software. I don't want the instability of their CVS tree. If the release engineer can't make a release because it's broken, fixing that becomes the number one priority for the project. Whatever change caused the problem needs to be backed out, if it cannot be easily fixed. But the fix is made on the main line of development, not another branch. The beta release is delayed until a non-broken state is re-established in CVS. ST> I don't see any particular point in having a "release" that doesn't ST> mean coordinating the various efforts to make sure that the code ST> builds on almost all platforms and passes "make check" on most, with a ST> list of known problem platforms, otherwise you're shipping alpha code ST> to the beta testers. But this really implies either a freeze on ST> non-release-fix commits or a new branch for the RE's fixes (and ST> concommitent merge headaches) for each "release", doesn't it? No. You can do cvs update; build; regression test for a while; tag the workspace with a release tag; build and release tarballs; independently of whether development has continued after the cvs update. The key is that the `tag' command tags the current state of the *workspace*, which is tested, not the CVS HEAD. The only tricky thing is adding those ``XEmacs 21.2.1234 is released'' ChangeLog entries everybody loves, since those need to be added at release time, not `cvs update' time. I like the concept of `tinderbox', that continually builds on multiple platforms to make sure that the tree maintains sanity, and to help identify when a patch introduces a compile problem or test regression. ST> I'm also having trouble with the semantics of "developers delay work". ST> Do you mean "developers", or "reviewers"? The former won't notice a ST> few hours or even a couple of days; it's the latter who can't do ST> anything during a freeze. But I thought the point of having frequent ST> "releases" was at least in part to _intentionally_ slow the commit ST> process down every so often so that the reviewers can agree on ST> something something that at least builds and passes tests on some ST> platforms, then start the cycle again. Slowing down the cycle while there is no feature or code freeze is evil because it makes being a contributor more work. Not only does the developer have to keep track of current freeze/thaw status, which may change hourly, but the release engineer has to make an extra effort to communicate that status (which might change if there is a build problem, for example). I want to eliminate *unnecessary* communication. We already have too much mail on this mailing list. I would think key active developers would use CVS to stay at the bleeding edge. Kyle doesn't use CVS, but the kind of work he does doesn't require that. Similarly, I don't use CVS for packages (yet), since I am mostly a simple `user' of packages, not a developer. The release engineer can push the button for making a release when a particularly important bug fix has been committed to CVS. mb> 10. Add a special tag like `xemacs-21-2-latest-beta' for the mb> latest released beta. This is always the latest level of CVS mb> that is *guaranteed* to run `make check' on at least the mb> release engineer's machine. ST> What's special about the RE's machine? What does it mean to have a ST> "release" that only passes tests on one machine? And if it doesn't, ST> then what? Ideally, the release process would use 10 machines on the Net for doing pre-beta-release testing, mostly guaranteeing that no one will ever get a compile error in a beta release. I don't know if we will find the Net resources to implement that. ST> You can't guarantee success, even on the RE's box, at regular ST> intervals; you just have to take it when it comes. I don't understand. You can't guarantee that the state of the code in CVS is non-broken, but you just don't make a beta release when that happens. Martin

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

mb> I think it would be much easier for the release engineer to mb> get accounts on 20 machines around the Net to do automated mb> testing herself. ST> Aren't those last five words an oxymoron? I don't think you want to live in a world where the computers need *no* supervision.