The X.Org Foundation X11R6.8.2 Release Plan
Table of Contents
Contents
Motivation
Currently, most X.Org distributors maintain a number of bug fix patches that are applied to the X.Org 6.8 release when they build it. The motivation behind this proposal is to pool the maintenance work done by distributors and collaborate on maintaining the stable branch. This would benefit all distributors as well as users compiling X.Org themselves. Ideally, distributors should only apply distribution specific patches, bug fixes should be upstream, available to everybody.
The overall idea is to take a pragmatic approach, and adopt a conservative policy for accepting patches. If a patch proposed for the stable branch is controversial in some way, we would not include it in the stable branch. It is probably not possible to set up strict rules for what kind of patches should be accepted. Each case will be a judgment call, but we're optimistic that there will be a large body of simple fixes that can be applied and that disputes will be rare.
With the shorter release cycles we now have, a strict bug-fix-only stable branch could work, since there will be less pressure to get new features into the stable branch. Distributors will of course still be able to apply rejected patches to their builds if they so choose. Another way to think of this is that the stable branch should be the intersection of the patch sets the various distributors apply, as opposed to the union of the patch sets.
Guidelines
The following are the currently set of guidelines as discussed on the release wranglers mailing list and conference calls.
- This release is for bug fixes only. It is the release wranglers' intention that no new features will be included.
- Bug fix patches that are to be considered for the stable branch can be nominated by anyone.
- With the patch, a brief description is encouraged to help the release wranglers decided whether or not to approve it.
- It is expected that obvious fixes will require little to no discussion.
- However, if further discussion is needed, it can take place on the release wranglers mailing list and subsequently on the weekly conference call (as required).
Each nominated patch must be trackable to allow the release wranglers to know exactly what they are approving. The method used during previous X.Org releases for tracking bugs was to enter them into bugzilla and include a reference to the bugzilla bug in the corresponding ChangeLog entry at check-in time. However, some complaints have been raised regarding this method, and the following two alternatives were proposed:
Entering bugs into bugzilla along with their associated patch, and then using bugzilla's attachment flags to track nominated patches (as is done by the Mozilla project). See Roland Mainz's e-mail for details.
- Delegating patch approval to module maintainers. De facto module maintainers would need to be established and agreed upon. The release wranglers would still have the ability to veto patches that are controversial and back them out.
- 1 For each point-release there must be a method for tracking which patches have been approved and checked in. This is required for preparing release notes.
- If bugs are entered into bugzilla and tracked via the attachment flags, then this information will be available in the bugzilla report.
- If patch approval is delegated to module maintainers, then this information will need to be provided by the module maintainer to the release wranglers.
- When fixing a bug in the stable branch, the bug must be fixed in head as well; it doesn't need to be the exact same patch of course (and indeed, that may not be possible), but we should work to make sure that there will be no regressions from the next major release to the latest point release.
- There should be no obligation to commit a fix to the 6.8 branch when committing to HEAD. This is encouraged and appreciated, of course, but the motivation here is that mainly the distributors benefit from the stable branch, and thus, they should take on the work.
Schedule
(Note: The schedule is currently upside-down after the freedesktop.org break-in which happened around Nov 15. Anything beyond that date is currently marked as Date X which marks the day when we resume normal work on the X11R6.8.x stable branch)
05 Nov 2004: Proposal for X11R6.8.2 release presented to release wranglers for approval
08 Nov 2004: Open bug fix patch nomination phase begins
Anyone can nominate bug fix patches through the process described in Roland Mainz's e-mail at this time.
- Note that after this open bug fix patch phase, it will become much more difficult to get a nominated patch accepted, so everyone is encouraged to nominate patches during this first phase.
- Note that some patches have already been nominated.
12 Nov 2004: Open bug fix patch nomination phase ends
- Discussion of the patches nominated during the open bug fix patch phase will begin on 12 Nov 2004 and end on 19 Nov 2004.
- Discussions will take place on the release wranglers mailing list, on IRC and conference calls as necessary.
- As patches are approved by the release wranglers, they will be checked into the 6.8 branch.
Date X: Critical bug fix patch nomination phase begins
- Only critical bug fix patches can be nominated at this time.
Date X + one week: Critical bug fix patch nomination phase ends
- Discussion of the patches nominated during the critical bug fix patch phase will begin on 19 Nov 2004 and end on 26 Nov 2004.
- Discussions will take place on the release wranglers mailing list, on IRC and conference calls as necessary.
- As patches are approved by the release wranglers, they will be checked into the 6.8 branch.
Date X + two weeks: First release candidate is tagged
- All approved patches should be checked in by the time the first release candidate is tagged.
- Testing of the release candidates begins.
- Additional patches or reversions will be made during the testing as required.
- Press release process begins (e.g., initial text, soliciting quotes, etc.).
Date X + five weeks: Completed press release text due
- Final editing and formal approval of press release
Date X + six weeks: Advanced posting of press release
Date X + seven weeks: Finalize release
- Release tagged.
- Documentation updated with final release date.
- Final tarballs created.
- Release uploaded to primary (and mirror sites).
- Release announced on mailing lists at same time press release goes out.
Responsibilities
- Release manager's responsibilities:
- Scheduling meetings
- Organizing/moderating discussions
- Building consensus on debatable patches
- Creating the release tar balls and documentation
- Release wranglers' responsibilities:
- Reviewing, testing and then approving or rejecting patches
- Participating in e-mail, IRC and conference call discussions whenever possible
- Testing the release
Open questions
- What testing is required before the release is finalized?
- Should the tinderboxes be switched over to the 6.8 branch during this release process?
- Should we use the same testing procedure that we used during the 6.8 release (i.e., build, install, conformance/xtest, run tests)?
- Who actually checks in the patches as they are accepted by the release wranglers?
Credits
This release plan is based on the strawman proposal by Kristian H�gsberg and followup discussions by Kristian, Donnie, Torrey, Mike, Roland, Daniel, Alan, Leon and Jim on the mailing list and Jim, Kevin, Stuart K. and others on the conference calls on 22 Oct 2004 and 29 Oct 2004. Kevin pulled all of these discussions together into a proposal, which was accepted with modification by the release wranglers on 05 Nov 2004.
-- Main.RolandMainz - 03 Dec 2004