[Ksummit-discuss] More productive uses of enthusiastic new kernel developers (was: Re: [TOPIC] Encouraging more reviewers)

[Theodore Ts'o <tytso@mit.edu>]

Thinking about this some more, what if instead of, or in addition to,
having newcomers work on cleanup patches, what if we encouraged some
of them to help to manually backport patches to the stable kernels
that don't apply automatically?

Currently the stable maintainers will typically send a notification
subsystem maintainer / mailing lists that a particular patch didn't
apply and that it's up some subsystem developers to handle resolving
the patch conflict.

What if those patches were also cc'ed to a separate mailing list which
was also monitored by patchwork, and newcomers were encouraged to grab
patches and try to make a determination whether it's really needed,
and how to handle doing the backport, and once the patch was properly
backported they could cc the subsystem mailing list asking for
approval before the patch could get fed into a long-term stable tree?

It does mean more patches to reviews, but I'd much rather review a
patch going into a long-term stable tree that would otherwise get
dropped (and thus avoid whiny entitled users and/or embedded engineers
who think it's the maintainer's job to backport to N different stable
kernels), rather than review whitespace patches.

If this worked out, I could also imagine encouraging more advanced
newcomers to look for bug fix patches that didn't have an explicit cc:
stable@vger.kernel.org, and look to see if they should be backported.
This would help for certain subsystems that have elected not to
automatically mark their patches.  There are subsystems which don't
like anyone but their experienced developers to handle doing
backports, but I suspect there would also be many subsystems that
would welcome the extra help, especially if it was much more likely to
result in additional reviewers / subsystem developers.

Cheers,

						- Ted