[Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

John W. Linville linville at tuxdriver.com
Thu Jul 9 18:08:46 UTC 2015


On Thu, Jul 09, 2015 at 10:45:35AM -0700, Guenter Roeck wrote:
> On Thu, Jul 09, 2015 at 11:09:38AM -0400, John W. Linville wrote:
> > 
> > I guess I'm suggesting the opposite of a "professional maintainer".
> > Some people thrive at being the center of a subsystem, as I did for
> > some time with wireless.  But burnout is a problem, and I think we
> > can limit some of that if somehow we can encourage less expansive
> > roles for individual maintainers.
> > 
> 
> I hear you.
> 
> However, having individual maintainers with a high level of responsibility
> and sense of ownership is one of the reasons why the Linux kernel
> development model works as well as it does.
> 
> In a corporate environment, there is often no sense of ownership in a
> specific piece of code. Quite often there _is_ no owner. As a result,
> engineers don't feel the need to keep the code clean. They need to make
> a change, they make it, they move on. The code gets more and more messy
> and buggy over time, and no one really cares.
> 
> Whatever we change, we need to make sure this doesn't happen with the
> Linux kernel, or it will fall apart quickly.

That is a good point, and I agree in principle.  I would _not_ want
to see any sort of "everyone can commit" model.  Still, I think there
might be ways to spread the maintainership load a bit wider.

I guess the suggestion becomes a deeper maintainer hierarchy where
maintainers only pull from sub-maintainers, and sub-maintainers handle
individual patches and smaller pull requests from contributors.
This is essentially the model used for wireless.  That introduces
the problem of increased patch merge latency, for which I have no
good suggestions...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


More information about the Ksummit-discuss mailing list