Differences between revisions 148 and 149
Revision 148 as of 2016-08-05 18:14:42
Size: 19745
Comment:
Revision 149 as of 2016-08-11 12:19:09
Size: 19707
Editor: tuliom
Comment: Update Advance Toolchain entries
Deletions are marked like this. Additions are marked like this.
Line 50: Line 50:
|| IBM Advance Toolchain 7.0 || 2.18 ||
|| IBM Advance Toolchain 7.1 || 2.19 ||
|| IBM Advance Toolchain 8.0 || 2.20 ||
|| IBM Advance Toolchain 9.0 || 2.22 ||
|| IBM Advance Toolchain 8.0  || 2.20 ||
|| IBM Advance Toolchain 9.0  || 2.22 ||
|| IBM Advance Toolchain 10.0 || 2.24 ||

Release Process

Stable Glibc releases are further maintained in 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.16.1 with many bugfixes since fixed in mainline compared to the "main release" 2.16.

1. Current branches

Currently, these release branches are maintained:

See Glibc Timeline for the release timelines.

Notes: Copy from Release/X.Y template.

The following branches are closed and further commits to them should not be made:

2. Distribution Branch Mapping

The following is the mapping of actively supported distribution branches, public or private, with respect to the upstream glibc branches.

Distribution

Branch

Red Hat Enterprise Linux 5

2.5

Red Hat Enterprise Linux 6

2.12

Red Hat Enterprise Linux 7

2.17

Fedora 21

2.20

Fedora 22

2.21

Fedora 23

2.22

Fedora 24

2.23

Fedora 25

2.24

Fedora 26 (tentative plan)

2.25

Fedora 27 (tentative plan)

2.26

IBM Advance Toolchain 8.0

2.20

IBM Advance Toolchain 9.0

2.22

IBM Advance Toolchain 10.0

2.24

3. 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).

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. Patch backports to stable branches are discussed on libc-stable, and any patch on master that doesn't change ABI or API is immediately suitable for backporting to a stable branch.

It is best if a release manager volunteers, and is agreed by the community, at the start of mainline development leading to the new release (for example, a 2.17 release manager should be agreed around the time 2.16 is released). If a release manager is agreed at that time, they may then agree a release timetable with the community for the next stable release and branch. 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!

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.

4. New Release Manager [REQUIRED]

Each release manager should have or gradually obtain:

  • Push access to git.sourceware.org. [REQUIRED]
  • A published (preferably well cross-signed) PGP key for signing release tags. [REQUIRED]
  • Have your PGP key in the list of glibc releasers on gnu.org; see below. [RECOMMENDED]

5. Step-by-Step Release

Process

Full Release

Point Release

When?

Development

New development

Backports

6 months before release

Freeze

(./)

(./)

1 month before release

Translations

(./)

(./)

Right after freeze

Testing

(./)

(./)

All through the freeze

RM Testing

(./)

(./)

All through the freeze

News/Contrib

(./)

(./)

Just before release

Regenerate

(./)

(./)

Just before release

Final translations

(./)

(./)

Just before release

Tag

(./)

(./)

At release

Branch

(./)

{X}

At release

Upload release

(./)

(./)

At release

6. Release Steps

6.1. Development [REQUIRED] (6 months before release)

Active development is carried out on master.

  • Create wiki page for the coming branch from Release/X.Y template, and link it here at the top of the page. [REQUIRED]

The release branches receive backports from master:

  1. For every new point release e.g. X.Y.N create a new section in NEWS which will contain the new set of fixed bugs for the point release. Make sure that you copy the bug number and description entry from the NEWS file during the backport (for new-style auto-generated bug lists), and otherwise just the bug number (for old-style releases with bug number lists).
  2. Work through the bugzilla issues tagged with the keyword associated with the release branch you maintain. For example if you are maintaining X.Y and a bug has the keyword glibc_X.Y, then that means the fix for this bug should be backported to glibc_X.Y. As the release manager you have two options, accept the change and carry out the backport or reject the change. If you reject backport you must remove the glibc_X.Y keyword and document in the issue why the bug was rejected for backport to glibc release branch X.Y.

6.2. Freeze [REQUIRED] (1 month before release)

A general development freeze should be declared some time before release.

During this period before the release, the release manager may ask committers to limit commits to master. Changes to avoid include:

  • Anything requiring ports architecture maintainers to update their ports (the period should allow them to catch up with any updates left from the previous development).
  • Anything changing the public ABI and so requiring check-abi updates on each architecture, or adding libm tests that will require ulps updates on each architecture (again, the period allows for architecture maintainers to update these files and get them ready for the release).
  • Anything that subjectively seems too risky.

6.3. Translations [REQUIRED] (Right after freeze)

Some time before the release, regenerate libc.pot. See Regeneration for details.

If there are any new messages or changes to messages since the last libc.pot submitted to the Translation Project, generate a snapshot tarball. Submit it to the Translation Project so translations can be updated before the release.

The step by step process is like this:

  • Regenerate libc.pot, review the changes and check it in.
  • Generate tarballs using make dist.

  • Upload snapshot to alpha.gnu.org using gnupload e.g. ./gnupload --to alpha.gnu.org:glibc glibc-2.20-546-ga8db092.tar.bz2 (Careful that absolute path to tarball is also appended on the remote host). Do not upload to ftp.gnu.org, only official releases should be uploaded there.

  • Email coordinator@translationproject.org with the URL of the snapshot tarballs, for example:

    From: You
    To: coordinator@translationproject.org
    Subject: libc-2.15.90.pot
    
    Translation Project,
    
    The GNU C Library is about to release version 2.16.
    
    * Complete snapshot of 2.16 release containing `po/libc.pot':
    ftp://alpha.gnu.org/gnu/glibc/glibc-2.15-???-????????.tar.bz2
    
    Cheers,
    You.

6.4. Testing [REQUIRED] (All through the freeze)

Architecture maintainers should test glibc for their architectures using the testsuite to make sure it is working well (the release manager should ask them to do so). [REQUIRED]

Architecture maintainers should update ABI baselines; see Regeneration. [REQUIRED]

All architecture maintainers should update the ulps baselines for libm tests as needed; see Regeneration. [RECOMMENDED]

6.5. RM Testing [RECOMMENDED] (All through the freeze)

In an attempt to increase the quality of a release we run the following additional testsuites at this time:

6.6. News [RECOMMENDED] (Just before release)

Shortly before the release, look for any significant user-visible changes not mentioned in the NEWS file and add them to that file.

6.7. Insert list of fixed bugs in NEWS [REQUIRED]

There should be a placeholder at the bottom of the NEWS file section for the new release:

The following bugs are resolved with this release:

  [The release manager will add the list generated by
  scripts/list-fixed-bugs.py just before the release.]

Replace that last paragraph by the (UTF-8) output of scripts/list-fixed-bugs.py (with version number as argument, e.g. scripts/list-fixed-bugs.py 2.123) and commit the result.

6.8. Update manual/contrib.texi [RECOMMENDED]

Shortly before the release, check that the contributors for this releases are given credit in manual/contrib.texi.

6.9. Update manual/install.texi [RECOMMENDED]

Shortly before the release, test building with the most recent GCC release and update the statement in manual/install.texi about the most recent GCC release with which building glibc was tested. Similarly for binutils and texinfo. Regenerate the INSTALL file.

6.10. Regenerate [REQUIRED]

After testing and shortly before the release (perhaps a week before) regenerate all files that need regeneration. See Regeneration.

Please note that make dist-prepare is not sufficient for this use case since it should regenerate files even if the timestamps are up to date.

6.11. Final Translations [REQUIRED] (Just before release)

Check for new translations at the Translation Project site and install them.

Example script to fetch new translations:

#!/bin/bash
glibc_version=2.21
file_template=libc-${glibc_version}-pre1.XX.po
url_template=http://translationproject.org/PO-files/XX/${file_template}
for i in be pt_BR bg ca zh_CN zh_TW hr cs da nl eo fi fr gl de el hu id ia it ja rw ko lt nb pl ru sk sl es sv tr uk vi;
do
  wget $(echo $url_template | sed -e "s,XX,$i,g")
  mv $(echo $file_template | sed -e "s,XX,$i,g") po/${i}.po 
done

6.12. Tag [REQUIRED] (At release)

The release is tagged. Send an email to libc-alpha@sourceware.org with a developer announcement about the tag.

  • Update RELEASE to "stable" and VERSION to "X.Y" e.g. "2.16" in version.h.

  • Update __GLIBC_MINOR__ in include/features.h.

  • Create signed tag glibc-X.Y or glibc-X.Y.Z 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 shall contain the full announcement you are about to send out as the last step.
    • Push the tag git push origin glibc-X.Y to the remote server for everyone to reference.

6.13. Branch [REQUIRED] (At release)

This step is skipped for point releases.

Branch the release from master:

  • Create a release/X.Y/ branch from master on glibc using the tag made in the previous step.

Development starts for the next major release:

  • Update RELEASE to "development" and VERSION e.g. "2.16.90" in version.h on master.

  • Create a section for the next release in the NEWS file:

    Version 2.NN
    
    [Add important changes here]
    
    Security related changes:
    
      [Add security related changes here]
    
    The following bugs are resolved with this release:
    
      [The release manager will add the list generated by
      scripts/list-fixed-bugs.py just before the release.]

6.14. Upload release [REQUIRED] (At release)

The release manager creates tarballs and sends announcements.

  1. 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).
  2. Sign + upload your tarballs to ftp.gnu.org - see below for a gnupload invocation that can make your life easier.
    • 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
    • If you don't have PGP key on gnu.org, follow the GNU maintainer guide, again referring to RolandMcGrath for authorization; you may also ask CarlosODonell or AlfredMSzmidt for help with the uploads until you arrange the access.

  3. Ask the Bugzilla Admin Team to update the sourceware bugzilla to add a new keyword to track this release e.g. glibc_M.N.

  4. Ask the Bugzilla Admin Team to update the sourceware bugzilla to add a new version and milestone to track the next release e.g. M.N. Versions and milestones are best added when development starts for a release, not after branching (for example, create those for 2.17 at the time 2.16 branches), but if the newly branched version does not already have them, then they should be created at that time.

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

    • Recommended contents is as follows:
      FROM: Release Manager <you@exmaple.com>
      SUBJECT: The GNU C Library version X.Y is now available
      
      The GNU C Library
      =================
      
      The GNU C Library version X.Y is now available.
      
      The GNU C Library is used as *the* C library in the GNU system and
      in GNU/Linux systems, as well as many other systems that use Linux
      as the kernel.
      
      The GNU C Library is primarily designed to be a portable 
      and high performance C library.  It follows all relevant 
      standards including ISO C11 and POSIX.1-2008.  It is also 
      internationalized and has one of the most complete 
      internationalization interfaces known. 
      
      The GNU C Library webpage is at http://www.gnu.org/software/libc/
      
      Packages for the X.Y release may be downloaded from:
              http://ftpmirror.gnu.org/libc/
              http://ftp.gnu.org/gnu/libc/
      
      The mirror list is at http://www.gnu.org/order/ftp.html
      
      NEWS for version X.Y
      ====================
      
      <Cut and paste from NEWS file>
      
      Contributors
      ============
      
      This release was made possible by the contributions of many people.
      The maintainers are grateful to everyone who has contributed
      changes or bug reports.  These include:
      
      <git shortlog --summary -w72 glibc-(Previous X.Y tag).. | sed -e 's,^.*\t,,g'>
    • Also announce the release in the news feed of the Savannah site for aggregation at planet.gnu.org.

    • See general GNU instructions on announcing releases.

    • Announce it on Google+ and Google+ The GNU C Library (glibc) community.

    • Announce it on Twitter with #GLIBC and @gnutools.
    • Announce it on LinkedIn and LinkedIn glibc developers group.

  6. Ask the Web Admin Team to update the glibc homepage at gnu.org with a NEWS item that links to the release announcement (main index.html and download.html with examples). Also have them updated the online manual to the latest version.

  7. Update the release page e.g. https://sourceware.org/glibc/wiki/Release/2.23, with status.

  8. Update HomePage and Glibc Timeline.

None: Release (last edited 2016-08-11 12:19:09 by tuliom)