This is the mail archive of the
mailing list for the glibc project.
Re: Approach to backports to release branches
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Allan McRae <allan at archlinux dot org>
- Cc: Ondrej Bilka <neleai at seznam dot cz>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 23 Jun 2014 10:26:59 -0700 (PDT)
- Subject: Re: Approach to backports to release branches
- Authentication-results: sourceware.org; auth=none
- References: <53A6A424 dot 3070007 at archlinux dot org>
The only ironclad policy we have about what changes are appropriate for
release branches is to exclude all ABI changes (except regression fixes)
and nontrivial API changes (except regression fixes). We also have a
pretty solid policy to exclude any new features of any kind (i.e. also ones
that are not ABI or API changes per se). Beyond that, it's really up to
the release manager and consensus of distro maintainers who manage the
releases that actually get used by anyone.
Usually it's wisest to avoid incidental or cosmetic changes just to be
conservative about unintended change. But that can easily trade off with
the risk of nontrivial manual merge fixup in backports having unintended
changes. And the amount of hassle for the person doing the backport
(especially if it's the release manager) is no trivial matter either.
Any time someone doing a backport is less than completely sure about the
safety of it, he should feel free to post the exact backport patch for more
people to review and look for potential problems before committing it. Any
time the manual fixup was not completely trivial, this is probably the wise
So for this kind of case, I'd say the "policy" is to use your judgment and
to lean on the rest of the core maintainer community as much as necessary
to shore up your confidence.
In this particular case, your feeling about the safety of this change is
probably right I'd say. However, I am disturbed to see that the little
change you mentioned (ab7ac0f2cf8731fe4c3f3aea6088a7c0127b5725) has no
ChangeLog entry. The posting of the patch had one, but it was lost at the
actual commit. Ondrej, please put a retroactive (i.e. back-dated and
positioned appropriately) ChangeLog entry on trunk. Allan, if/when you
cherry-pick the change for the release branch, please combine the log entry
addition into the same commit.