History and Motivation
Starting with Xorg 6.7, we used a fairly heavyweight release process, in which the entire source tree was frozen for stabilisation during a one to three month process. This led to excessively long release cycles, and frustrated developers who had to wait until the cycle was complete before commiting new code. With the move to modular X, the release process has become more decentralized and asynchronous. Maintainers for individual modules are able to release their subsystems as needed, rather than waiting up to a year or more for a monolithic release.
There is still value in providing accumulated releases on a periodic basis. Much like releases in the Gnome project, these releases indicate that the indicated versions of each module have been tested and are known to work well together. Release management in the modular world is therefore mostly a matter of reviewing the various modules and selecting the appropriate branch to badge as released.
Status
Adam Jackson is currently lead RM, but ideally this will become merely a ceremonial title.
7.1 has been released. This seems to have gone reasonably well for a first effort, but there have been some notable issues.
- The katamari process was almost entirely manual. This needs to be made point-and-shoot. Some inconsistencies in the archive were found afterwards, which is a bit embarassing. ajax is working on scripting this process and placing the scripts and data in CVS so it's all public and easy-access.
- Still poor communication regarding how releases are to be composed by downstream. How do you know which modules to include? How do you know what modules have been deprecated? etc.
Schedule and work in progress
See the proposed schedule.
Future issues
Current open questions regarding the release management process.
Release-wrangler calls
We did this in 6.x, and tried it during the start of the 6.9/7.0 effort, but it was impossible to schedule and the calls burned a lot of time. If 7.1 is anything to go by, they don't seem to be needed.
There is some issue of process transparency during the RC cycle; again, automation should help with this next time around.
Is the six month cycle too aggressive, or not aggressive enough
No one's complained yet, so the working assumption is that it's Just Right.