Glibc stable release process (Glibc 2.26.1)

[Yann E. MORIN]

Carlos, All,

On 2017-10-17 14:19 -0700, Carlos O'Donell spake thusly:
> On 09/29/2017 01:17 PM, Romain Naour wrote:
> > We do understand that getting a new release out can be quite some work, and we
> > do acknowledge the efforts that are made to provide those releases.
> > 
> > Yet, being able to refer to human-readable versions is very important.
> > 
> > Maybe a middle ground is that a tag is pushed to the repository, just to
> > identify a specific sha1 as "this is 2.26.1". This is relatively lightweight (a
> > signed tag) and gives downstream users that need it a clear identification of a
> > blessed version.
> 
> I waited a while for this thread to die down, before summarizing.

Thank you for this summary; it is much appreciated. Thanks also to all
involved in the discussion. :-)

Regards,
Yann E. MORIN.

> Making releases requires resources, people, hardware, attention, and
> more it has an opportunity cost.
> 
> The release process as we have it today is the realization of a minimized
> process that attains the following important goals:
> 
> * Make a time boxed release every 6 months that is tested on all
>   supported architectures by the machine maintainers themselves, and
>   provides a strong foundation upon which distributions can build their
>   operating system around. This release is the *basis* for ABI and API
>   stability guarantees given to our users.
> 
> * Continue the stabilization efforts on a rolling branch that receives
>   ABI/API stable changes. Each commit should be more stable than the
>   last.
> 
> I worked with several downstream maintainers to get them involved in the
> upstream stable branches. If you see something broken, please go upstream.
> Cherry pick from master to the stable branch and sync again with downstream.
> Debian does it. Fedora does it. Gentoo does it. Patching locally stops
> becoming expedient once you get to pull in other well tested patches that
> other distros have also tested.
> 
> In summary:
> 
> - Giving a name, or releasing a named point release from the release branches
>   implies something it is not, namely a fully tested release. The release branch
>   is incrementally tested and ready for distribution use. If distributions
>   want to work together to coordinate and name specific release branch commits
>   as being important, we can help facilitate that.
> 
> - Between Florian Weimer, Dmitry V. Levin, and others, tags have been added to
>   git, along with Release process adjustments to keep adding these tags, which
>   should add more descriptive names to all the branches. Having meaningful names
>   for things is important.
> 
> -- 
> Cheers,
> Carlos.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'