Recent stable Glibc releases are further maintained in so-called release branches, where they continue to receive backports of bugfixes committed to the main development branch (master). Thus, users will be able to get e.g. 2.11.1 with many bugfixes since fixed in mainline compared to the "main release" 2.11.

Current branches

Currently, these release branches are maintained:

General policy

Each release branch owns a Git ref namespace release/VERSION/, recommended structure being release/VERSION/master for development, while tags are made under the common scheme glibc-VERSION.REVISION (i.e. glibc-2.11.1).

Normally, a release branch is forked off master after the stable version is tagged (usually, commits intended to update the version appear for few days after the version is tagged and the release branch would diverge only right before version.h is updated to reflect start of development for next main version), and consists purely or almost purely of cherry-picked fixes committed to the master branch.

Each branch is maintained by a single release manager, who has the responsibility of maintaining the particular stable branch, has final say on what goes in and tags further revisions on the branch. The branch is expected to receive many liberally merged bugfixes from master at the beginning when many new bugs are found, then become more conservative and decrease the rate of back-ports as most major problems are solved and the branch is being propagated to more mature distribution versions. Usually, the interested committers have discretion over which bugfixes to pick for back-porting, but if discussion arises, general consensus of the community is sought, the default choice being to err on the conservative side.

It should be noted that the decision when to make next stable release is fully in the hands of the main glibc maintainer (UlrichDrepper), only at that point some release manager volunteers (from the population of glibc hackers, generally) and starts maintaining the release branch. Each branch has so-called interested parties, usually glibc maintainers in distributions where the particular branch is being used; tagging revisions on the release branches should result of consensus between the maintainer and interested parties - one workable model is that the maintainer suggests that he wants to release and other people check if they are happy with the set of patches included and the timing is fine-tuned; if a release is important for one of the parties (e.g. distribution nearing a release), they can suggest a release of new revision as well if it is meaningful.

Anyone can suggest a fix committed on master (unless it's N/A for master for some reason - in that case, discussion about the patch is expected) to be included in a release branch, either by marking it by an appropriate keyword in bugzilla, or cherry-picking it themselves and sending a pull request. Developers with glibc commit permissions can in general push into any release branch, but they are expected to execute reasonable judgement and follow the branch policies. All cherry-picked commits should be created using git cherry-pick -x to indicate the id of the original commit in the commit message (see details on cherry-picking in Git). Always aim at having one cherry-picked commit for one original commit.

Note that the above process is still in flux and may change based on our experience with it. Particular release branches may fine-tune these policies in different ways, though the spirit should stay the same. Try to pay attention to what your past (or concurrent) predecessor release managers have done, and learn from their examples and mistakes. It is expected to have discussion on new policies (even per-branch ones) and any unusualities on libc-alpha.

Final words: Always keep in mind the GNU copyright discipline, and finally, Do not taunt Happy Fun Drepper. :-)

Release Managers

New Release Manager

Each release manager should have or gradually obtain:

Starting a Release Branch

When new glibc release is made, Ulrich will create the tag and make a short announcement; at that point, someone should step in as a release manager. If you would like to try this out, and especially if you have some interest in the branch well-being (e.g. you are distro maintainer who will base a distro branch on top of this release), feel free to just suggest yourself on libc-alpha!

The first role of the release manager is to bootstrap the stable branch:

  1. It is advisable to wait with forking off release/2.N/master only after the master's version.h changes from 2.N to 2.N.99 and therefore new development period is started. Use the last commit before version.h change as the base for the release branch; the commits in between should have been hopefully only mostly bug fixes anyway and it saves a confusion of having two divergent trees declaring themselves to be stable 2.N version.
  2. Therefore, start the release/2.N/master branch at the correct base, possibly do the first few cherry-picks too, and push it out to the glibc git repository. You may need to revert any changes that are not for 2.N including NEWS file updates etc.
  3. Create wiki page for your branch, and link it here.
  4. Announce what you did on libc-alpha.

  5. Ask CarlosODonell to update the sourceware bugzilla to add a new keyword to track this release e.g. glibc_M.N.

  6. Ask CarlosODonell to update the sourceware bugzilla to add a new version to track this release e.g. M.N.

  7. Ask CarlosODonell to update the glibc homepage on gnu.org.

  8. Send a mail with announcement to libc-alpha@sourceware.org, libc-announce@sourceware.org, and info-gnu@gnu.org.

    • Recommended contents is git shortlog output since the last release, prepended by some general description and possibly known problems list, and some kind of instructions on where to get the release.

Tagging Revision Release

When the pushed out commits are well tested and you announced your release plans on libc-alpha at least few days in advance, to release a revision of the branch:

  1. Commit an update of the version.h file.
  2. Create signed tag glibc-2.M.N and push it to the public glibc repository

    • Create the tag using git tag -s; verify it's signed by the PGP key you want to sign it with.

    • The tag comment should contain something meaningful, e.g. the git shortlog of the changes since last release; ideally the full announcement you are about to send out as the last step.
  3. Create a tarball of the tagged release.

    • Use make dist in a build tree - it will generate couple of ../glibc*tar* files.

    • Verify the tarballs are sensible, try to build the glibc from the tarball (e.g. using it as source for your distribution package).
  4. Sign + upload your tarball to ftp.gnu.org - see below for a gnupload invocation that can make your life easier.

    • If you don't have PGP key on gnu.org, follow the GNU maintainer guide, again referring to RolandMcGrath for ack; you may also ask AlfredMSzmidt for help.

    • Temporarily, the people listed above may help you with the uploads until you arrange the access.

  5. Ask CarlosODonell to update the glibc homepages at gnu.org and sourceware.org.

  6. Send a mail with announcement to libc-alpha@sourceware.org, libc-announce@sourceware.org, and info-gnu@gnu.org.

    • Recommended contents is git shortlog output since the last release, prepended by some general description and possibly known problems list, and some kind of instructions on where to get the release.

You may use gnupload to easily sign and upload your tarballs: 

gnupload --to ftp.gnu.org:glibc \
    glibc-2.11.1.tar.gz glibc-2.11.1.tar.bz2 glibc-2.11.1.tar.xz

None: Release (last edited 2012-01-24 16:32:47 by CarlosODonell)