Re: Glibc stable release process (Glibc 2.26.1)

[Romain Naour <romain dot naour at gmail dot com>]

Hi All,

Le 17/10/2017 à 23:31, Yann E. MORIN a écrit :
> 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. :-)

Yes, thank you all for the discussion :)

> 
> Regards,
> Yann E. MORIN.
> 
>> Making releases requires resources, people, hardware, attention, and
>> more it has an opportunity cost.

Indeed, I understand that.

>>
>> 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.

Ok, thanks for the summary.

I'll try to give some feedback from Buildroot before the next glibc release.

Best regards,
Romain

>>
>> -- 
>> Cheers,
>> Carlos.
>