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: "Gabriel F. T. Gomes" <gabriel at inconstante dot eti dot br>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Siddhesh Poyarekar <siddhesh at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>, "Andreas K. Huettel" <dilfridge at gentoo dot org>, <libc-alpha at sourceware dot org>, Zack Weinberg <zackw at panix dot com>, "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Romain Naour <romain dot naour at gmail dot com>, "Paul Eggert" <eggert at cs dot ucla dot edu>, Arjan van de Ven <arjan at linux dot intel dot com>
- Date: Wed, 4 Oct 2017 10:30:28 -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> <CAKCAbMj3ByTofE=WsKV-SXOCWyJYStRKvP3DA9ttiW2hUNZffA@mail.gmail.com> <5c98c67b-52a9-dcff-eda7-0f16b8ab478d@sourceware.org> <2839686.ckfu0BZrXq@porto> <a30cc34e-f71f-8e8a-1b99-1c3c1b798e84@redhat.com> <93d68f19-73a0-d906-ece2-bdc002507ca5@sourceware.org> <20171003111452.57b93728@keller.br.ibm.com> <31ca9f87-52e1-2f87-c471-7a55c2af0db3@sourceware.org> <alpine.DEB.2.20.1710041316380.3865@digraph.polyomino.org.uk>
On 04 Oct 2017, Joseph Myers wrote:
>On Wed, 4 Oct 2017, Siddhesh Poyarekar wrote:
>
>> > - https://sourceware.org/ml/libc-alpha/2017-10/msg00102.html
>> > (not yet on master, but probably relevant to the point-release)
>> >
>> > Maybe there are more, and eventually others will emerge, so I have no idea
>> > what criteria should be used to decide what goes in and what stays out of
>> > this point release.
>>
>> There's no strict limitation on what goes into a stable branch, but I
>> think the following guidelines should be followed if in doubt:
>>
>> 0. Must not break ABI on that branch
>> 1. Reasonably limited in scope (i.e. isolated to an architecture, bug
>> fixes, CVE fixes, small feature additions)
>> 2. Should not affect translation strings (flexible, could be overridden
>> for serious bugs/CVEs)
>
>I would suggest:
>
>3. Wait a few days after committing to master before cherry-picking to the
>branch, in case any problems with the patch show up on master (the above
>patch being a case in point). When applying a patch to a branch, make
>sure to watch out for any followup patches that were applied to master to
>fix such problems, and cherry-pick those to the branch as well.
Totally agree. I felt unnecessarily rushed.