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

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

On Thu, 2025-08-21 at 12:27 -0400, Steven Rostedt wrote:
> On Thu, 21 Aug 2025 09:56:15 +0100
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> What exactly do you mean by "feature inclusion"?

It's deliberately vague. I am aware we include many new features (like
new SCSI or nvme drivers) every year that don't lead to this type of
conflict.  The last one in SCSI I recall was the aic94xx driver writer
demanding the SCSI subsystem change for his driver rather than vice
versa.
> 
> Something that requires a new maintainer? As with the bcachefs, the
> issue was with how the new maintainer worked with the current
> workflow.

That's not really it either: new drivers tend to get an entry in
MAINTAINERS as well.

> Maybe you mean "maintainer inclusion and ejection"?
> 
> > However, I'm sure others will have different ideas.

I think this is technical not personal, so I'd like to keep it at
features.

> The thing is, I believe there's a lot of features and maintainers
> that are added. Most go unnoticed as the feature is a niche (much
> like bcachefs was).

Yes, except the likely problems with bcachefs were pointed out ahead of
time so we had warning there were likely to be problems.

> Perhaps we should have a maintainer mentorship program. I try to work
> with others to help them become a new maintainer. I was doing that
> with Daniel Bristot, and I've done it for Masami Hiramatsu and I'm
> currently helping others to become maintainers for the trace and
> verification tooling.
> 
> 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.

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

Regards,

James