Re: [Ksummit-discuss] More productive uses of enthusiastic new kernel developers

[Li Zefan <lizefan@huawei.com>]

On 2014/5/31 0:56, Theodore Ts'o 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?
> 

This is similar to my idea in "stable issues" to find a co-maintainer
for Greg to do this work. While I sugguest to find a experienced and
trustful person, you sugguest newcomers.

I share the same concern with David, and I doubt newcompers are
enthusiastic in doing backport for stable trees.

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