Release Engineering initiatives for the XEmacs project

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."