Re: Glibc stable release process (Glibc 2.26.1)

[Carlos O'Donell <carlos at redhat dot com>]

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.

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.