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

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

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

James