Hi! On Sun, Jun 15, 2025 at 05:52:50PM +0200, Mark Wielaard wrote: > On Wed, Jun 11, 2025 at 10:40:02AM -0500, Segher Boessenkool wrote: > > On Wed, Jun 04, 2025 at 05:53:18PM -0600, Jeff Law via Gcc wrote: > > > On 6/3/25 1:41 PM, David Edelsohn via Gcc wrote: > > > >What is not working with the current system? What is this fixing? > > > It relies on the someone to shepherd the process and it's something that > > > often gets pushed down on my daily todo list. As a result nominations > > > don't happen or are extremely delayed. > > > > > > Additionally there's no visibility into the process. It's a total black > > > hole, particularly for cases where I'm on point. > > > > > > This isn't necessarily a steering committee problem, but a time problem. > > > > > > If we make things simpler for those cases where it is actually simple > > > and increase visibility so that folks know state I think it would be a > > > welcome improvement to the process. > > > > Yup. And it might not be a bad plan to get some people who still are > > active onto the GCC steering committee, as well! > > > > It is as important now as ever that there *is* such a thing as the SC: > > all decisions need to be taken responsibiliity for by some final > > authority, which we (as a project) have all decided to have that > > authority. > > Agreed, having active developers taking responsibility is > important. But it doesn't really have to be through a steering > committee imho.
I specifically said that there *is* a need for something like the SC. There needs to be a final authority. Without that there will be eternal (and eternally lasting) fights. > We (as a project) can decide that the authority lies > with the active maintainers as a whole getting to concensus. Just like > any maintainer can appoint new write after approval accounts. Or, as WaA is decided by the sourceware maintainers. The request form says "email address of person who approved request", but that is not who has the final call :-) Which of course makes sense, the sourceware maintainers primarily need to keep their system safe and working! > in this case, the active maintainers of a subsystem decide on who else > becomes a reviewer or maintainer for that subsystem. The release > managers could decide if and when to accept a new front or > backend. etc. That is not how things work. The SC decides who does and does not become maintainer (reviewer is just a hobbled kind of maintainer, there is no real difference). Maintainers for frontends, backends, subsystems can recommend things, sure. But they have no separate authority, there can not be fiefdoms. This is Good(tm). Segher
