From: Julia Lawall <julia.lawall@lip6.fr>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning
Date: Mon, 9 Oct 2017 18:49:34 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1710091848390.3870@hadrien> (raw)
In-Reply-To: <1507567045.3100.16.camel@HansenPartnership.com>
[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]
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-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.
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?
Both are doable.
julia
>
> James
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
next prev parent reply other threads:[~2017-10-09 16:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 19:20 Theodore Ts'o
2017-10-05 20:13 ` Rafael J. Wysocki
2017-10-05 21:55 ` Jiri Kosina
2017-10-06 14:59 ` Takashi Iwai
2017-10-06 15:27 ` James Bottomley
2017-10-06 16:26 ` Josh Poimboeuf
2017-10-06 16:32 ` Jonathan Corbet
2017-10-06 16:51 ` Josh Poimboeuf
2017-10-06 16:56 ` James Bottomley
2017-10-06 17:16 ` Josh Poimboeuf
2017-10-06 20:11 ` Linus Walleij
2017-10-09 8:13 ` Mark Brown
2017-10-09 15:54 ` Jiri Kosina
2017-10-09 16:37 ` James Bottomley
2017-10-09 16:47 ` Joe Perches
2017-10-09 16:49 ` Julia Lawall [this message]
2017-10-09 16:56 ` James Bottomley
2017-10-09 17:04 ` Joe Perches
2017-10-11 18:51 ` Jani Nikula
2017-10-12 10:03 ` Daniel Vetter
2017-10-16 14:12 ` James Bottomley
2017-10-16 14:25 ` Jani Nikula
2017-10-16 16:07 ` Joe Perches
2017-10-17 8:34 ` Jani Nikula
2017-10-18 1:27 ` Joe Perches
2017-10-18 10:41 ` Jani Nikula
2017-10-16 18:52 ` Mark Brown
2017-10-10 8:53 ` Jiri Kosina
2017-10-24 23:03 ` Kees Cook
2017-10-24 23:41 ` Joe Perches
2017-10-25 0:54 ` Kees Cook
2017-10-25 4:21 ` Julia Lawall
2017-10-25 4:29 ` Joe Perches
2017-10-25 4:36 ` Julia Lawall
2017-10-25 6:05 ` Martin K. Petersen
2017-10-25 6:55 ` Kees Cook
2017-10-25 7:34 ` Martin K. Petersen
2017-10-25 6:45 ` Frank Rowand
2017-10-25 7:56 ` Mark Brown
2017-10-25 9:39 ` Laurent Pinchart
2017-10-31 19:19 ` Rob Herring
2017-10-31 19:28 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1710091848390.3870@hadrien \
--to=julia.lawall@lip6.fr \
--cc=James.Bottomley@HansenPartnership.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox