Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote:
> 
> On Mon, 9 Oct 2017, James Bottomley wrote:
> 
> > 
> > On Mon, 2017-10-09 at 17:54 +0200, Jiri Kosina wrote:
> > > 
> > > On Fri, 6 Oct 2017, James Bottomley wrote:
> > > 
> > > > 
> > > > 
> > > > 2) Trivial patches (again). OpenStack has recently started to
> > > > become annoyed by these 
> > > > 
> > > > http://lists.openstack.org/pipermail/openstack-dev/2017-Septemb
> > > > er/t
> > > > hread.html#122472
> > > > 
> > > > I thought about our process around the trivial tree, but it
> > > > hasn't been updated in the last few releases, so effectively we
> > > > no longer use it.
> > > 
> > > This has been caused solely by me being buried in other things,
> > > and there was always something else that overrode trivial tree in
> > > priority.
> > > 
> > > > 
> > > > 
> > > >  So is what we're currently doing (variable standards by tree)
> > > > OK, or should we have a more concerted trivial policy?
> > > 
> > > My original plan was to revive trivial tree for 4.15, as there
> > > are quite a few patches in the queue (that still apply). But if
> > > it's generally considered annoying (although I am pretty sure we
> > > don't suffer from what's in the openstack thread), I don't object
> > > and can ditch it completely.
> > 
> > Well, their objection was core (by which they mean Maintainer)
> > review and merge time, plus the interference to higher priority
> > patches caused by mismerges.  I was actually thinking a trivial
> > tree might help them because it would offload all the mismerges and
> > review and they only need do a real merge just before release
> > stabilisation.
> > 
> > > 
> > > The thing is that such patches will keep coming anyway, and I
> > > think they have the value (although the priority is really lower
> > > than other changes of course). I still believe that having
> > > greppable comments, for example, is nice to have.
> > 
> > Well, we tend to veto changes to old drivers in various subsystems
> > anyway (having been burned by the this is only a trivial change and
> > then finding out six months later that the driver is broken).
> > 
> > Trivial changes seem to fall broadly into three categories:
> > 
> >    1. spelling fixes
> >    2. whitespace changes (I ran checkpatch.pl on your file and it
> > returned
> >       these issues).
> >    3. pattern imposition (we now have a new API for this so lets
> > change
> >       all prior open coded incarnations)
> >    4. trivial pattern fixes (things like replacing if(x) kfree(x);
> > with
> >       kfree(x);)
> > 
> > I don't want to open the whole spelling/whitespace can of worms,
> > but perhaps we could have a more meaningful discussion about the
> > pattern based issues ... for instance if we agree it's useful and
> > coccinelle can do it, then tree wide replacement at -rc1 might be a
> > better solution than ad-hoc application of hundreds of patches.
> 
> Do you suggest one big patch, that goes to who?  Or lots of little
> patches that go out at once to the individual maintainers of the
> affected code?

I was actually thinking we validate the script and if there are no
problems, apply it at -rc1 ... so effectively one big patch.  What
actually gets applied (script or big patch) would be up to Linus ...
he's the one that makes the -rc1 changes.  However, if we agree a
curation path for the script, the application could be done by Jíři as
a pull from the trivial tree (unless Linus wanted to do it himself or
someone else wanted to manage this).

James