This page describes the process used by stable branch maintainers for the XServer.
DONT PANIC!
As maintainer, you get to decide the schedule of the stable branch series as well as what patches you will accept in the tree. We ask that once you decide on a schedule for the next release, you stick to that schedule (within a reasonable margin). Sometimes things get in the way though. If there is a need for changing the schedule announce it so others are aware of the change. Of course, the further ahead this can be announced the better. An email along the lines of "the 1.x.y+1 release will follow a 8 week release schedule" is perfect.
Either way, the point of a stable branch is to provide stable fixes. Any scheduling issues are less important.
A patch must be on the master branch unless the specific issue is either diverged too much from master or only occurs on the stable branch to begin with. If the master branch suffers from the same bug but a different patch is required (due to differences to the stable branch), the bugfix must be on master first. This allows us to detect potential side-effects from fixing a bug.
Getting a patch onto the stable branch is largely the job of the developers, but they usually need a bit of prodding. As branch maintainer, don't shy away from asking people to send you pull requests or clarify if a specific patch proposed for master is suitable for stable.
Creation of the stable branch (only needed once) should be done based on the released tag
git checkout xorg-server-1.13
git checkout -b server-1.13-branch
git push origin server-1.13-branch
The stable branch is now visible on the remote.
Patches can be cherry-picked onto the branch from master. Always use -x to record the original commit
git cherry-pick -x 1234deadbeef
And once the branch is ready to push
git push origin server-1.13-branch
Alternatively, in the case of a pull request simply run git pull on the remote (with the branch name)
git pull git://people.freedesktop.org/~jbond/xserver.git server-1.13-fixes
Before pushing, the maintainer should ensure that the tree builds and performs adequate on their machine.
See the ReleaseHOWTO for instructions on how to invoke the release script. To make releases, the maintainer must have a gpg key to sign tags and announce emails.
Each release has a version number and a git tag named after the module. The version number is set in configure.ac, the module name (and thus git tag prefix) for the XServer is xorg-server.
The patchlevel version increases once with each stable release, release candidates for future stable releases use a trailing 901, 902, etc. Example tag names for the 1.13 stable branch series
xorg-server-1.13.0 # stable release
xorg-server-1.13.0.901 # 1.13.1RC1
xorg-server-1.13.0.902 # 1.13.1RC1
xorg-server-1.13.1 # 1.13.1 stable update