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