On Fri, 2026-07-31 at 12:26 +0900, Andreas K. Huettel wrote: > Am Freitag, 31. Juli 2026, 01:21:24 Japanische Normalzeit schrieb Adhemerval > Zanella Netto: > > > > > So, your preference would be that new releases of > > > GNU m4 > > > GNU gettext > > > GNU bison > > > GNU wget2 > > > get made, before distros start rolling out glibc-2.44 at a large scale? > > > (I don't see any other option for avoiding significant numbers of bug > > > reports.) > > > > I don't have a strong opinion, I am more inclined to add this new symbol on > > 2.44. There is the extra annoyance that a lot of consumers do not track the > > release branch, but rather the release package; and I think it highly > > unlikely > > we would release 2.44.1. Andreas might have a different opinion here. > > Well, I don't see doing a point release as an unsurmountable challenge. :) > It's a bit underdocumented at the moment, a good opportunity to change that. > > We should try not to make it the rule but only an exception, and have a good > reason > for it, but here as far as I can see there's a good point for it. > > I should make clear, I would not intend to follow an as involved release plan > for such a point release as for the main version bump. I.e. no long > machine testing phase for many architectures and no call for desirables. > We assume that our release branch is a stabilization/bug fix branch and take > what we have there, maybe with a week quiet time on the branch to ensure > that people have time to build and check it. > > [As a side note, I'm fairly confident we would have caught this problem in > Gentoo > with the modified release procedure (other thread), taking the branch point > as > release candidate and rebuilding our whole package set...]
Side note: I'm a little disappointed by the fact that Fedora has actually caught this two weeks earlier than me but they didn't make a report. -- Xi Ruoyao <[email protected]>
