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

[Shuah Khan <shuahkhan@gmail.com>]

On Fri, May 30, 2014 at 10:56 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> 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.
>

In addition to the above, how about keeping a maintainer and sub-maintainer
wish list of tasks and work they would like to see get done in their areas and
don't have time do it themselves. It could be maintained on kernelnewbies site.
Having something like this will help guide and give direction to people looking
to get started in a new area and/or any area of the kernel.

-- Shuah