public inbox for ksummit@lists.linux.dev
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Greg KH <greg@kroah.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency
Date: Thu, 06 Jun 2019 19:29:29 +0300	[thread overview]
Message-ID: <1559838569.3144.11.camel@HansenPartnership.com> (raw)
In-Reply-To: <20190606155846.GA31044@kroah.com>

On Thu, 2019-06-06 at 17:58 +0200, Greg KH wrote:
> > 2) Patch Acceptance Consistency: At the moment, we have very
> > different acceptance criteria for patches into the various
> > maintainer trees.  Some of these differences are due to deeply held
> > stylistic beliefs, but some could be more streamlined to give a
> > more consistent experience to beginners who end up doing batch
> > fixes which cross trees and end up more confused than anything
> > else.  I'm not proposing to try and unify our entire submission
> > process, because that would never fly, but I was
> > thinking we could get a few sample maintainer trees to give their
> > criteria and then see if we could get any streamlining.  For
> > instance, SCSI has a fairly weak "match the current driver" style
> > requirement, a reasonably strong get someone else to review it
> > requirement and the usual good change log and one patch per
> > substantive change requirement.  Other subsystems look similar
> > without the review requirement, some have very strict stylistic
> > requirements (reverse christmas tree, one variable definition per
> > line, etc).  As I said, the goal wouldn't be to  beat up on the
> > unusual requirements but to see if we could agree some global
> > baselines that would at least make submission more uniform.
> 
> I thought Dan's "maintainer document" was going to help resolve
> things like this, both putting in writing just what those rules were,
> as well as help point out where things might be going too far in one
> direction or another in a much easier way, as they could be compared.

Well, um, I can't really comment on a document that doesn't yet exist. 
However, I can note that the best kernel process documents describe
what we actually do (mostly because attempting to impose additional
processes by fiat [or by document] really doesn't go over well) and
that's orthogonal to what I'm proposing: I'm proposing that we examine
critically what we currently do and see if there aren't any more areas
where we could strive for greater consistency and uniformity. 
Certainly, if Dan's doc exists by KS time it could be a useful input,
but to effect change in this area requires discussion and agreement by
the franchise holders (i.e. the maintainers) which is what I'm
proposing and which KS is the ideal venue to get.

James

  parent reply	other threads:[~2019-06-06 16:29 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06 15:48 [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency James Bottomley
2019-06-06 15:58 ` Greg KH
2019-06-06 16:24   ` James Bottomley
2019-06-13 13:59     ` Mauro Carvalho Chehab
2019-06-14 10:12       ` Laurent Pinchart
2019-06-14 13:24         ` Mauro Carvalho Chehab
2019-06-14 13:31           ` Laurent Pinchart
2019-06-14 13:54             ` Mauro Carvalho Chehab
2019-06-14 14:08               ` Laurent Pinchart
2019-06-14 14:56             ` Mark Brown
2019-06-14 13:58           ` Greg KH
2019-06-14 15:11             ` Mauro Carvalho Chehab
2019-06-14 15:23               ` James Bottomley
2019-06-14 15:43                 ` Mauro Carvalho Chehab
2019-06-14 15:49                   ` James Bottomley
2019-06-14 16:04                     ` Mauro Carvalho Chehab
2019-06-14 16:16                       ` James Bottomley
2019-06-14 17:48                         ` Mauro Carvalho Chehab
2019-06-17  7:01                           ` Geert Uytterhoeven
2019-06-17 13:31                             ` Mauro Carvalho Chehab
2019-06-17 14:26                               ` Takashi Iwai
2019-06-19  7:53                               ` Dan Carpenter
2019-06-19  8:13                                 ` [Ksummit-discuss] [kbuild] " Philip Li
2019-06-19  8:33                                 ` [Ksummit-discuss] " Daniel Vetter
2019-06-19 14:39                                   ` Mauro Carvalho Chehab
2019-06-19 14:48                                     ` [Ksummit-discuss] [media-submaintainers] " Laurent Pinchart
2019-06-19 15:19                                       ` Mauro Carvalho Chehab
2019-06-19 15:46                                       ` James Bottomley
2019-06-19 16:23                                         ` Mark Brown
2019-06-20 12:24                                           ` Geert Uytterhoeven
2019-06-20 10:36                                         ` Jani Nikula
2019-06-19 15:56                                       ` Mark Brown
2019-06-19 16:09                                         ` Laurent Pinchart
2019-06-15 10:55                         ` [Ksummit-discuss] " Daniel Vetter
2019-06-14 20:52               ` Vlastimil Babka
2019-06-15 11:01               ` Laurent Pinchart
2019-06-17 11:03                 ` Mauro Carvalho Chehab
2019-06-17 12:28                   ` Mark Brown
2019-06-17 16:48                     ` Tim.Bird
2019-06-17 17:23                       ` Geert Uytterhoeven
2019-06-17 23:13                       ` Mauro Carvalho Chehab
2019-06-17 14:18                   ` Laurent Pinchart
2019-06-06 16:29   ` James Bottomley [this message]
2019-06-06 18:26     ` Dan Williams
2019-06-07 20:14       ` Martin K. Petersen
2019-06-13 13:49         ` Mauro Carvalho Chehab
2019-06-13 14:35           ` James Bottomley
2019-06-13 15:03             ` Martin K. Petersen
2019-06-13 15:21               ` Bart Van Assche
2019-06-13 15:27                 ` James Bottomley
2019-06-13 15:35                 ` Guenter Roeck
2019-06-13 15:39                   ` Bart Van Assche
2019-06-14 11:53                     ` Leon Romanovsky
2019-06-14 17:06                       ` Bart Van Assche
2019-06-15  7:20                         ` Leon Romanovsky
2019-06-13 15:39                   ` James Bottomley
2019-06-13 15:42                   ` Takashi Iwai
2019-06-13 19:28               ` James Bottomley
2019-06-14  9:08               ` Dan Carpenter
2019-06-14  9:43               ` Dan Carpenter
2019-06-14 13:27               ` Dan Carpenter
2019-06-13 17:27             ` Mauro Carvalho Chehab
2019-06-13 18:41               ` James Bottomley
2019-06-13 19:11                 ` Mauro Carvalho Chehab
2019-06-13 19:20                   ` Joe Perches
2019-06-14  2:21                     ` Mauro Carvalho Chehab
2019-06-13 19:57                   ` Martin K. Petersen
2019-06-13 14:53           ` Martin K. Petersen
2019-06-13 17:09             ` Mauro Carvalho Chehab
2019-06-14  3:03               ` Martin K. Petersen
2019-06-14  3:35                 ` Mauro Carvalho Chehab
2019-06-14  7:31                 ` Joe Perches
2019-06-13 13:28       ` Mauro Carvalho Chehab
2019-06-06 16:18 ` Bart Van Assche
2019-06-14 19:53 ` Bjorn Helgaas
2019-06-14 23:21   ` Bjorn Helgaas
2019-06-17 10:35     ` Mauro Carvalho Chehab

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=1559838569.3144.11.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=greg@kroah.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