[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