Re: Glibc stable release process (Glibc 2.26.1)

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 03/10/2017 11:57, Andreas K. Huettel wrote:
> Am Dienstag, 3. Oktober 2017, 16:14:52 CEST schrieb Gabriel F. T. Gomes:
>> On 03 Oct 2017, Siddhesh Poyarekar wrote:
>>> On Tuesday 03 October 2017 12:52 AM, Florian Weimer wrote:
>>>> I still don't understand why you need tarballs for releases, though.  or
>>>> put differently, the difference between glibc 2.26.5 and glibc 2.26-40
>>>> seems rather minor to me, and producing the tarballs is quite a bit of
>>>> work for us.
>>>
>>> Right.  To be clear, even if I agree to do one now, it should not be
>>> binding on any future release managers to do the same for their release
>>> branch.  Maybe it makes sense to have a targeted discussion like this
>>> with the final decision being that of the release manager for that release.
>>
>> If you actually agree to do one now, are we going to have something
>> similar to a code freeze?
> 
> Given that your previous recommendation was "stay with the tip of the release 
> branch", that sounds unnecessary. My recommendation from my experience as 
> packager of other software would be, 
> * keep adding backports to the release branches as careful as now
> * tag (and tar?) point releases from the release branches at regular 
> intervals, say every two months.
> This might make releases more comparable between distributions. 
> 
> Of course, alternatively, every distro can do the tag and tar just themselves. 
> And and in any case add patches in between... but the next point release gives 
> a common reference point then again.
> 

The point release of already released versions should be based on defined
branch for ABI stabilization.  Trying to use master branch for point
releases can potentially add symbols that might resulting in releases
with different ABI and this is a potentially source of problems.

Also, keep in mind that release branches are maintained by volunteers that
might not have the required bandwidth to keep active schedule releases.
I do not know how viable would be to have this automated, but even though
it would required infrastructure work we might not have for current work.

I see that for 2.26 for the particular C++ issues might be a good thing
to aim for a 2.26.1, but I see that point releases should always be a
community discussion in concordance with release manager time disposal.