Re: release branch policy and distributions

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 16/02/23 19:57, Michael Hudson-Doyle via Libc-alpha wrote:
> I've sat on this for a while, sorry.
> 
> On Thu, 2 Feb 2023 at 11:03, Carlos O'Donell via Libc-alpha <
> libc-alpha@sourceware.org> wrote:
> 
>> Sam James (Gentoo) brought to my attention during the glibc 2.36
>> release that some distributions did not know about the release/*
>> branches. We discussed adding more text to the release announcement
>> to highlight the purpose of the branches.
>>
> 
> So speaking as one of the Ubuntu maintainers, we have historically not done
> a very consistent job of getting glibc updates to stable releases. I would
> like to get to a more consistent schedule of updating glibc in long term
> support releases, maybe every six months for the life of a release. I think
> most of the reason we haven't been good at this is resourcing (hi Simon!
> :-p), but...
> 
> 
>> For glibc 2.37 I've added the following text to the release announcement:
>> ~~~
>> Distributions are encouraged to regularly pull from the release/*
>> branches corresponding to the release they are using.  The release
>> branches will be updated with conservative bug fixes and new
>> features while retaining backwards compatibility.
>> ~~~
>>
> 
> ... I do have qualms about the definition of "conservative" here. The
> updates are certainly conservative wrt ABI but there has also been a trend
> to backport optimizations and this has occasionally led to bugs being
> introduced on the release branch, like
> https://sourceware.org/bugzilla/show_bug.cgi?id=29591.
> 
> Now bugs happen and I don't want to make too much out of any particular
> issue and there is obvious value in getting performance improvements to
> users of stable distributions. But! I think there is an issue of timing: if
> an optimization is backported to release branches before it is included in
> a release, the first time it is exposed to wide usage could be via an
> update to users of a stable release, and that doesn't seem right.
> 
> Would it be unreasonable to suggest a policy where performance improvements
> are not backported to release branches until say a month after they have
> been included in a glibc release? I realize this would add some overhead to
> keep track of these 'pending' backports but I personally would be happier
> consuming the release branches directly if there was this sort of policy.

I am not very found of performance backports either, and I think fair to
setup a buffer time before such  backports are added on release branches.  
I would prefer to be even more conservative and set that only performance 
improvement from a previous release are eligible to backport, it will give 
even more time for users to verify there is no regression on multiple 
different hardwares (which is not readily available for glibc developers). 

> 
> I'm open to any suggestions for specific wordsmithing here, but the
>> intent is to continue to encourage distribution participation in the
>> stable branches as we do today... starting with using them.
>>
> 
> Well. I want to suggest more than wordsmithing I guess!
> 
> Cheers,
> mwh
> 
> The last 3 releases have seen ~700 commits backported to fix bugs
>> or implement ABI-neutral features (like IFUNCs).
>>
>> Thank you to everyone doing the backporting work! :-)
>>
>> I also called out everyone in the release announcement who had their
>> name in a Reviewed-by tag.
>>
>> Thank you to everyone doing reviews! :-)
>>
>> --
>> Cheers,
>> Carlos.
>>
>>