This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Glibc stable release process (Glibc 2.26.1)
- From: "Tulio Magno Quites Machado Filho" <tuliom at linux dot vnet dot ibm dot com>
- To: Romain Naour <romain dot naour at gmail dot com>, "libc-alpha\@sourceware.org" <libc-alpha at sourceware dot org>
- Cc: Joseph Myers <joseph at codesourcery dot com>, "Gabriel F. T. Gomes" <gabriel at inconstante dot eti dot br>, Siddhesh Poyarekar <siddhesh at sourceware dot org>, "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>
- Cc:
- Date: Fri, 29 Sep 2017 18:38:06 -0300
- Subject: Re: Glibc stable release process (Glibc 2.26.1)
- Authentication-results: sourceware.org; auth=none
- References: <60f78cac-9cf4-51b1-9ade-21cd09783d96@gmail.com>
Romain Naour <romain.naour@gmail.com> writes:
> However, the point is not about choosing what commit to cherry-pick.
> From the downstream perspective, a commit on the maintenance branch is always
> worth it. If it were not needed, it would not have been committed to the
> maintenance branch in the first place.
>
> Gabriel F. T. Gomes suggested the use of a git clone from a given hash instead
> but, as explained by Yann E. Morin, using "2.26.1" is much more descriptive than
> using a random hash from the stable branch.
It isn't random. It helps to track all the objects a point of history has
and all its parent commits.
That information may not be important for everyone, but it is valuable for
some users.
It also helps downstream to follow the "upstream first" ideology. ;-)
> A new dot-release is a strong indication that the most critical fixes have made
> their way to the maintenance branch, and that it has been officially sanctioned
> by upstream (you! ;-)), which is a very important status for downstreams.
This behavior varies according to the community. On glibc, a patch is only
backported to stable branches if it's already reviewed and accepted on master
and if there is consensus they're suitable to a stable branch [1].
You can track these discussions in the libc-stable mailing list. [2]
It doesn't affect only glibc 2.26. If there are older releases downstream
not following a glibc stable branch which aren't cherry-picking backported
patches I strongly advise to start doing so in order to get bugs fixes and
security fixes because the last glibc point release was 2.14.1 in 2011.
I'm not opposing to a point release, but considering how the glibc community
has been working, I don't think it helps to make it more stable, reviewed or
officially sanctioned.
[1] https://sourceware.org/glibc/wiki/Release/#General_policy
[2] https://sourceware.org/ml/libc-stable/
--
Tulio Magno