Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

["Luis R. Rodriguez" <mcgrof@suse.com>]

On Mon, Jul 20, 2015 at 12:09:06PM +0100, David Woodhouse wrote:
> On Mon, 2015-07-20 at 11:30 +0100, James Bottomley wrote:
> > Agree ... that's why we need a responsible maintainer, and I believe 
> > it would be an even more onerous task than running the trivial tree.
> 
> I think any scripted change like this would need to come *from* a
> responsible maintainer, not *through* one. I'm not sure we really need
> a 'process' for it other than someone with sufficient credibility
> persuading Linus to run the script.
> 
> Alternatively, it isn't *that* hard for someone like Josh (who was the
> one who said he often finds himself doing this kind of thing) to create
> a git tree which runs the script *regularly* on the tip of Linus' tree
> (or linux-next), creating a new version of the commit which can be
> pulled at that moment.
> 
> Then it should just be case of of asking Stephen to "put this tree last
> in linux-next", and Linus to "pull this one last, right before
> releasing -rc1". And getting the timing right for the script to run.

I ran into quite a bit of delay / coordination through another types of
tree-wide changes recently: tree wide collateral evolutions which affect more
than one subsystem. One of the issues with this is such type of changes
may end up having 1-2 release delays before being complete unless the stars
align and everone can get in sync and agree for all changes to go through
one tree. I'm sure this is not a new thing either, but with tools like
Coccinelle I do suspect the amount of work to do this has reduced and as
such we should be able to more easily make these changes. What I found was
that our pipes were not as smooth to handle these types of changes when
needed, even if everyone was in total agreement.

I proposed a linux-oven tree [0], pricicely as David describes, which can be
used after all trees are merged. So not only would it be useful for scraped
cleanups but also tree wide collateral evolutions which span multiple
subsystems. If such a tree existed and folks knew such maintainer would
go through proper dilligence for testing, review, vetting from maintainers
I think it would make both scripted changes and tree wide collateral evolutions
easier to manage. If done through a separate tree Linus would also not need
to be involved, instread the onus of correcting patches lies on the developers
submitting to the tree and the maintainer.

[0] http://lkml.kernel.org/r/20150619231255.GC7487@garbanzo.do-not-panic.com

  Luis