From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6DBE8AB2 for ; Mon, 9 Oct 2017 16:56:35 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4301F3F9 for ; Mon, 9 Oct 2017 16:56:32 +0000 (UTC) Message-ID: <1507568189.3100.29.camel@HansenPartnership.com> From: James Bottomley To: Julia Lawall Date: Mon, 09 Oct 2017 09:56:29 -0700 In-Reply-To: References: <20171005192002.hxbjjdjhrfa4oa37@thunk.org> <1507303665.3104.13.camel@HansenPartnership.com> <1507567045.3100.16.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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