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: Siddhesh Poyarekar <siddhesh at sourceware dot org>
- To: Arjan van de Ven <arjan at linux dot intel dot com>, "Andreas K. Huettel" <dilfridge at gentoo dot org>, libc-alpha at sourceware dot org
- Cc: 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>, Joseph Myers <joseph at codesourcery dot com>, "Gabriel F. T. Gomes" <gabriel at inconstante dot eti dot br>, Paul Eggert <eggert at cs dot ucla dot edu>
- Date: Tue, 3 Oct 2017 10:19:32 +0530
- 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> <1a7977d1-d5e5-f87c-40cb-5ad791f96a76@linux.intel.com>
- Reply-to: siddhesh at sourceware dot org
On Monday 02 October 2017 01:50 AM, Arjan van de Ven wrote:
> I've been doing distro work for some 17 years now (including at RH way
> back);
> while the packaging side of it is sort of a noop (you tool that anyway),
> the clarity
> and unambiguity of version numbers (in light of CVEs) is something users
> like, it
> sets a common baseline they don't have to look further at.
In my experience, users look at distro release numbers and notes first
and then upstream if they don't find the necessary information there.
So the idea that they'd look for upstream news to answer questions about
their own distros seems inside out.
> bisecting glibc patches outside of distro packages is mostly beyond end
> users' capability.
Agreed and most users don't even look at the packages, they look at
release notes. I was referring to the QE teams and their convenience of
backing out individual patches in the spec file as opposed to figuring
out bisecting patches in git. They're much more comfortable doing the
former since that is what they do all the time for all packages.
Siddhesh