FWIW, I think the title here is a bit confrontational. ;) I'd suggest more: "Find out how to improve stability and communication between glibc maintainers and the rest of Fedora".

As a counter proposal, perhaps we could get the glibc maintainers (or is there really only one?) to change their workflow to better match our release setup:

• New builds always go to rawhide and 'cook' for a while.

• Only after proving stable in rawhide for a while would they push to branched releases.

• Could the upstream cycle look to have it's stable release by the time of Fedora's "Feature Freeze" instead of just right before Fedora release? Development could continue in rawhide of course after that for the next release.

• Adjusting the Fedora package to carry a upstream snapshot + seperate patches instead of a patch of a patch could help others in Fedora see problems or realize where changes in the Fedora glibc package are being made.

Well, yes. The title is perhaps confrontational. However, I think the glibc maintainer(s) have used up quite a lot of goodwill lately.

I agree that there are plenty of ways that they could improve their process, but I've seen no indication that they're willing to do so. So my proposal is that FESCo needs to put its foot down and "force" them into a maintainable process.

Opening a dialog and saying "It would be nice if you did ''this''" is all well and good, but historically it's been completely ignored.

This bug is also on the common bugs page: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=750361

Bit conflicted here -- glibc did suffer some pretty major problems this time around which point at needing to change something but I'm not sure the solution is a bit too strong this early in the discussion. Trying to keep track of the other threads that feed into this -- it seems there are two and a half frustrations:

1. Large changes to a core system going in when the core needs to be stable so that people can work on stabilizing the things that depend on it.
2. Communication with the maintainers of the core system in question to find out why the changes are occurring and influence the maintainers to weigh the risks of their changes more heavily.
3. Why these changes aren't first making it into rawhide or spending an extended time in updates-testing to be thoroughly vetted before they make it into the stabilizing branch.

(3 is the half since it's really a large, unstated part of the solution we're looking for).

Perhaps instead of leaping to empowering other committers to second-guess the glibc maintainers, making some sort of communication mandatory would be better at this stage (I'm assuming here that this ticket has been opened because "optional communication" is perceived as having been tried and failed)? So something like after beta release, glibc should not rebase and only important bugs should be fixed. As we get closer to release, fixes must become more targeted and fix only more crucial bugs. The glibc maintainers need to discuss the impact of their changes with fesco (or other group empowered by fesco) to weigh the risks and benefits.

I was hoping that last part could just be lumped in with another weekly meeting post-beta release but the only candidates I know of are the weekly blocker-bug-meeting which doesn't seem quite right (since it's addressing what is broken rather than what might be broken with further changes) or the fesco meeting itself (which takes up fesco time and doesn't have quite the right mix of people... the blocker-bug-meeting probably is better in terms of the people that are already participating there).

Anyhow, if there's a way to get communication working properly, that seems like a better way to get across that rawhide is the place for rebases after beta rather than getting into commit wars if you have a watchdog group empowered but still haven't established communication.

I really think that the core pieces of fedora need to be fully feature complete by alpha. gcc, glibc, python. we should only allow bugfixes in after that point. we have a big window where active development can happen and major changes can take place. any feature thats going to need a mass rebuild needs to land before alpha. gcc, glibc and python bumps are likely things to fall into this space. the glibc changes really should have gone into rawhide only.

I mostly agree with Stephen here. I do have nothing against politely asking glibc developers to adjust their schedule and not use branched fedora for development of new features however I am afraid that just asking without having appropriate plan B if the changes are not implemented, in hand, can be easily ignored.

We are removing commit access/ownership on the glibc package for the current maintainer. law will take over fedora maintainership for now and gateway changes into the package.

We will be happy to revist this as needed.