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: "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: 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>
- Date: Tue, 17 Oct 2017 23:31:50 +0200
- Subject: Re: Glibc stable release process (Glibc 2.26.1)
- Authentication-results: sourceware.org; auth=none
- References: <60f78cac-9cf4-51b1-9ade-21cd09783d96@gmail.com> <b87c295c-101b-c97f-460d-70676af52b32@redhat.com>
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. |
'------------------------------^-------^------------------^--------------------'