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: "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>
- Cc: Romain Naour <romain dot naour at gmail dot com>, "libc-alpha\@sourceware.org" <libc-alpha at sourceware dot org>, 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>, Paul Eggert <eggert at cs dot ucla dot edu>, Arjan van de Ven <arjan at linux dot intel dot com>
- Cc:
- Date: Mon, 02 Oct 2017 14:31:23 -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> <874lrli3sx.fsf@linux.vnet.ibm.com> <20170930101833.GA2993@scaer>
"Yann E. MORIN" <yann.morin.1998@free.fr> writes:
> Let's say that we decide to use today's last commit on the branch, which
> is d37c951fde57e8acb320a9a7d437ba50a1fc3c8a. That's all good. But then
> tomorrow, new commits get pushed to the maintenance branch, and now the
> head of the same branch is 548cc83c38a91852b1e44045ead3d20ccd5db4cf
> (it is now fdf58ebc60ce0eb459fd616241b52872b3571ac1; writing this mail
> took much longer than I anticipated ;-] ).
>
> So in three days time, our "choice" would look no better as if we had
> randomly choosen a commit on the tree. There is nothing that makes that
> one stand out more than the ones before or after. Except that at some
> point in time, it was the latest. But that is useless past that very
> moment.
Tarballs and tags will have the same problem.
IMHO, the only solution to this is to streamline the process of distributing
the source from upstream to downstream.
> The alternative, that only guarantees the former, but does not help on
> the latter, is to cary the now-42 patches from the branch locally.
>
> This is ugly, because it is very easily prone to bitrot, and like
> explained above, would be missing later patches, so the set of patch
> would look no less randomly chosen that chosing a sha1 would be.
Agreed, although I still believe that carrying a tarball without extra patches
will cause the same issues.
> On 2017-09-29 18:38 -0300, Tulio Magno Quites Machado Filho spake thusly:
>> 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
>
> So, lemme quote this:
>
> 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.
>
> Is there a way to register the Buildroot project as an interested party?
https://sourceware.org/glibc/wiki/Release/#Distribution_Branch_Mapping
But I also suggest to subscribe to https://sourceware.org/ml/libc-stable/
--
Tulio Magno