Re: XEmacs 21.4.5 'Civil Service' is released.

Darryl> For future releases, could this be tested before the Darryl> public announcement is made? This can really give XEmacs Darryl> a bad name, especially coupled with the poor mirrors .... Well, we're trying, but the rate of staff attrition lately has been huge. Martin (beta releases) took leave in July; Jason (postmaster) in September. Several reviewers got jobs last spring and have hardly been heard from since. This has really whacked our process hard (not to mention that we had at least seven separate technical failures over the period of trying to put out the release, some of them global like losing our CVS host, others local like the DoS attacks my less-than- clueful colleagues are conducting on me, and Steve Youngs's computer meltdown). XEmacs also had a big development process problem, the wrong person (me) was making decisions about what Windows patches to apply. We've shifted that over to a right person (Andy), but we haven't worked out the release process bugs yet. This is one of them. Request for volunteers: I'm trying to work on these process issues, but if someone who has actually managed a project with a formal process wants to pitch in and help out I would really appreciate it. For example, turn Martin's xre script and my xre.py script into a formal release check list, and then add nitty gritty details like "testing this" (whatever that precisely means) that aren't in there yet. A lot of our release process is implicit in scripts like that; check out xemacs-builds from the repository. CVS committers can access the repository as follows: export CVS_RSH=ssh # adjust to taste cvs -d :ext:xemacs＠tanko.sk.tsukuba.ac.jp:/usr/CVSroot [cvs opts] [cvs cmd] If you don't have commit access but are willing to work on process issues (eg, by documenting the stuff in the xemacs-builds module), send me an SSH public key and I'll fix you up. Or wait for the anoncvs mirror to come up, which should be within a couple of days. I'd also really like an issue tracking system. We tried Jitterbug, that didn't work very well. Bugzilla seems the system of choice, or maybe SourceForge Tracker. If a volunteer with experience in installing and maintaining one of those systems would like to pitch in, that would be great. Of course, we could simply not put out any releases until we're ready. See you in 2010? That was Martin's estimate. :-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.