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

[Jason Cooper]

On Fri, May 30, 2014 at 01:54:49PM -0600, Shuah Khan wrote:
> On Fri, May 30, 2014 at 10:56 AM, Theodore Ts'o <tytso at 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 at 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.

There was some previous discussion on this that I can't locate atm.  In
short, the staging tree already has TODO files in-tree.  The advantage
being the patch handling the todo item should also delete the item from
the list.

Keeping it on a separate website just means additional out-of-workflow
maintenance for people who are already saturated.

thx,

Jason.