Release Engineering initiatives for the XEmacs project

I've recently put on the Release Engineer hat to try to make some improvements with XEmacs beta releases and developer productivity in general. Here are my medium-term goals: 1. Automate the release process sufficiently that putting out a new release will require minimal effort on my part. Guarantee that generated files in CVS and in released tarballs are always up-to-date. 2. Automate pre-release testing so that every beta release is guaranteed to pass minimal testing on a number of platforms. I'm planning on automatically testing at least: - optimized and debug builds - Linux and Solaris 2.6 - Mule and non-mule - Latest gcc and Sun native compilers I hope to add Cygwin at least as a tested platform. 3. Use makepatch-generated patches instead of `cvs rdiff' (done). 4. Switch the HEAD so that it reflects 21-2, make xemacs-21.1 into a branch. I don't know quite how to do this yet. I'm thinking of starting a new CVS tree. In this case, of course, we would keep the old tree for the history information. Nothing would be lost; old information would merely be slightly less convenient, while development at the bleeding edge would be faster and more convenient. 5. Put the Web site under CVS control. 6. Upload public files so that they are non-readable during upload, then chmod 0444'ed to make them readable. Keep all other files and directories readable during a beta release. 7. Release some kind of tarball that contains useful packages as well as the C code (details currently being debated). 8. Abolish the No-Commit period during releases. The release engineer's computers should, in principle, be able to spend days testing the release before making it official, and other developers should not have to delay their work during this process. 9. Work on getting a permanent home for XEmacs on a machine administered exclusively by us, with a reasonably high-bandwidth and stable network connection. 10. Add a special tag like `xemacs-21-2-latest-beta' for the latest released beta. This is always the latest level of CVS that is *guaranteed* to run `make check' on at least the release engineer's machine. 11. Our CVS server is unreliable. It has serious known bugs. I am working on fixing this by eiher switching CVS versions or getting a better machine. 12. I have an experimental implementation that makes it easier for us to add CVS committers securely and without root access to cvs.xemacs.org (i.e. no need to add new Unix accounts). 13. Increase our use of ssh throughout the project. All developers should be identified for security purposes through their ssh public key. We should be using ssh mechanisms exclusively to update CVS, Web, and ftp resources for xemacs, to reduce the chance of the bad guys sniffing our passwords on the wire.