Glibc stable release process (Glibc 2.26.1)

[Arjan van de Ven]

On 10/1/2017 12:59 PM, Andreas K. Huettel wrote:
> Am Sonntag, 1. Oktober 2017, 01:36:54 CEST schrieb Siddhesh Poyarekar:
>> On Saturday 30 September 2017 05:27 PM, Zack Weinberg wrote:
>>> I'm a little underslept and I'm not sure I fully understand the issue
>>> here, but would it help if we literally just tagged point releases and
>>> pushed tarballs to ftp.gnu.org from a cron job?  Once a month if there
>>> have been any patches since the previous tag, perhaps?  With the
>>> official line being that all patches on the release branches are
>>> carefully vetted and we recommend tracking the git branch if you can,
>>> but this is easier for some downstream organizations so we offer this
>>> as well.
>>
>> That is probably a waste of resources and also not entirely secure since
>> it would preclude signing packages.
>>
>> As a past Fedora maintainer, the feedback I got from a number of package
>> maintainers and testers in the Fedora community was that it was easier
>> to bisect bad patches when they were backported piece by piece as
>> opposed to looking at two tarballs, getting their tags, downloading
>> upstream sources, making scratch packages for them and then running
>> tests on them.  Given that Debian/Ubuntu follows a similar structure, I
>> suppose they would have similar problems.
> 
> To be honest, if I were a long-time glibc distro maintainer I'd probably agree
> with you and prefer hand-picking. Starting from a tag / tarball is something I
> prefer because I'm not that versed with things yet.
> 

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.

bisecting glibc patches outside of distro packages is mostly beyond end users'
capability.