• Download
• XEmacs in GSoC
• FAQ
• Mailing lists
• Documentation
• People
• How to help
• Bugs
• Links

• Mailing lists
• Status of Services
• Near Future
• History of XEmacs
• XEmacs vs. GNU Emacs
• Screenshots
• Sites Created With XEmacs
• Year 2000 Statement
• Who Wrote XEmacs?
• XEmacs Contributors
• Website

• Download
• Optional Libraries
• Installation HOWTOs
• Quickstart Package Guide
• Documentation
• Installation resources
• Releases

• XEmacs Packages
• Other Interesting Sites
• Customization Links

• FAQ
• Reporting Bugs
• Troubleshooting resources
• Debugging

• How to help
• XEmacs in GSoC
• Open Issues
• Who Wrote XEmacs?
• XEmacs Contributors
• Dev team responsibilities
• Architecting XEmacs

The Release Manager's Role

The Public Release Manager

I have volunteered to act as Public Release Manager as an explicitly term-limited position, and have been accepted by the Review Board. There are a number of tasks in the job list that are currently unfilled. I will also function as Meta-Maintainer Pro Tem, attempting to fill the permanent meta-maintainer position at least.

The term of the Public Release Manager is up when Vin (or his successor) accepts handover of the release as "stable." All experience with free software suggests that no matter what we call it, the first version or so after the public release will hardly be "stable." Vin has been doing an excellent job so far on 21.1. I want to avoid screwing the system up by asking him to take responsibility for the 21.2 body of code before he thinks it's time.

In terms of the release process, the Public Release Manager will be responsible for

1. Chairing discussion of the release process, including discussion of decisions about including or postponing features to the next cycle.
2. Keeping status information up to date, including nagging People With Projects (aka ``PWPs'' or ``taskmasters'') to communicate their projects' statuses. Initially, this means polling known PWPs, checking the BTS and the mailing lists for outstanding issues we should try to deal with, and reviewing Ben's Mule on Windows code (because he is already out of touch, and will not be back in touch until after the date by which a status report on this code should be presented to the board).
3. Communicating with non-reviewer developers, beta testers, and the general community about the release process. This includes drafting and editing RFPs and RFCs, incorporating them into a "release bulletin board" to monitor progress, and informing the Review Board if a "Person With Project" seems to have disappeared, implying that their feature may have to be backed out.
4. Producing timely (weekly?) beta test tarballs.
5. Deciding when to go to "gamma" status.
6. Writing NEWS and similar descriptive stuff.
7. Negotiating promotion to "stable" status with the Stable Release Maintainer.
8. Possibly kicking off a new release cycle, with a (probably) new Public Release Manager.

The Public Release Manager may of course delegate any of these responsibilities; he just has to make sure they get done. In particular, Martin will continue to actually roll the tester tarballs.