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: Zack Weinberg <zackw at panix dot com>
- To: "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>
- Cc: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Romain Naour <romain dot naour at gmail dot com>, "libc-alpha at sourceware dot 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>
- Date: Sat, 30 Sep 2017 07:57:55 -0400
- 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>
On Sat, Sep 30, 2017 at 6:18 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> What Romain and I were trying to say was that we would have to
> arbitrarily choose the commit on the tree. That choice would look
> random.
>
> 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.
[...]
I'm a little underslept and I'm not sure I fully understand the issue
here, but would it help if we literally just tagged point releases and
pushed tarballs to ftp.gnu.org from a cron job? Once a month if there
have been any patches since the previous tag, perhaps? With the
official line being that all patches on the release branches are
carefully vetted and we recommend tracking the git branch if you can,
but this is easier for some downstream organizations so we offer this
as well.
zw