On Mon, 2015-07-20 at 11:04 +0100, David Woodhouse wrote:
> On Mon, 2015-07-20 at 10:23 +0100, James Bottomley wrote:
> > On Mon, 2015-07-20 at 01:44 -0700, Josh Triplett wrote:
> > > On Mon, Jul 20, 2015 at 08:08:25AM +0100, James Bottomley wrote:
> > > > the mechanical one file at a time fixing
> > > > X.  I think we need someone to be the gatekeeper and review and apply
> > > > the script in one go.
> > > 
> > > I often find myself writing this kind of tree-wide fix, and I find it
> > > frustrating that it can't get merged as a unit; that would avoid the
> > > inevitable pile of merge conflicts, as well.  For anything that can be
> > > reliably applied as a script, I'd love to see it actually run as a
> > > script and the result committed.
> > 
> > Can you propose a mechanism?  We already have the trivial tree ...
> > should we have the script tree, and would you volunteer to maintain it?
> > Probably we'd run the script just after the merge window closes, so it
> > would likely be a late merging tree.
> 
> We have done that a few times, with Linus actually running the script
> for himself just after the last pull for -rc1.
> 
> I think last time he may have said "never again", but perhaps that was
> the nature of the changes (the include/uapi moves iirc) rather than the
> act of running a script per se.
> 
> I'm not sure we need a way to handle such scripted changes in bulk.
> They are relatively infrequent, aren't they?
> 
> The problem is that a lot of these really do need to be checked by a
> real human after the scripted change (even Coccinelle-type changes) is
> made. And thus we can't easily just let a script run free.

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.

James