Re: [MAINTAINER SUMMIT] Adding more formality around feature inclusion and ejection

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2025-08-21 at 15:15 -0400, Steven Rostedt wrote:
> On Thu, 21 Aug 2025 18:44:07 +0100
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > > I share my scripts and explain how to do a pull request. How to
> > > use linux-next and what to and more importantly, what not to send
> > > during during the -rc releases.  
> > 
> > I'm not sure that covers it.  As I read the situation it was more
> > about how you work with others when there are things in the kernel
> > you'd like to introduce or change to support your feature.  Hence
> > it's really about working with rather than against the community.
> 
> What I'm suggesting is to have a program to help newcomers that are
> taking on a maintainer role. This program can not only teach what
> needs to be done to be a maintainer, but also vet the people that are
> coming into our ecosystem. If there's a lot of push back from the
> individual on how to interact with the community, then that
> individual can be denied becoming a maintainer.

As I said, I think this is a good idea, it just wouldn't have solved
the problems we saw.  The initial pull request has a huge thread which,
when summarized, pretty much predicted the issues that were seen. 
Although he went into MAINTAINERS with an R tag, Brian Foster did
attempt to act as a buffer, something which I don't think we've thanked
Brian for enough, but something which ultimately failed probably due to
lack of empowerment.

> > > I'm sure others have helped developers become maintainers as
> > > well. Perhaps we should get together and come up with a formal
> > > way to become a maintainer? Because honestly, it's currently done
> > > by trial and error. I think that should change.  
> > 
> > That wouldn't hurt, but that problem that I see is that some fairly
> > drastic action has been taken on what can be characterised as a
> > whim, so I think we need some formality around how and when this
> > happens.
> 
> If it was policy for Kent to work with a mentor before he could send
> patches directly to Linus, would this have uncovered the issues
> before they became as large as they had become?

Well, no, the thread I pointed to as part of this proposal pretty much
predicted what actually happened.  So the problems were known ahead of
time and didn't need to be discovered, we just needed a better
mitigation mechanism (which a supervision program could form part of).

Regards,

James