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.
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.
See the proposed schedule.
Current open questions regarding the release management process.
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.
No one's complained yet, so the working assumption is that it's Just Right.