Glibc stable release process (Glibc 2.26.1)

[Siddhesh Poyarekar]

On Tuesday 03 October 2017 07:44 PM, Gabriel F. T. Gomes wrote:
> If you actually agree to do one now, are we going to have something
> similar to a code freeze?  I'm asking because I believe some patches
> should probably be considered release blockers, such as those in these
> threads:
> 
>   - https://sourceware.org/ml/libc-alpha/2017-09/msg00486.html
>     (already committed on the master branch)
>   - 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 agree that a targeted discussion about the need for a point release (as
> you suggested) makes sense, but then it probably would also make sense to
> discuss the relevance of particular patches as release blockers, which adds
> to the work required for the release.

I propose just a 1 week freeze to stabilize the branch before a point
release, the 1 month freeze again does not make sense since we're not
waiting for translations or detailed architecture tests given the
limited scope of the change.  The current guidelines put point releases
and full releases in the same category, so I'd like to hear more
opinions from maintainers on this.

Siddhesh