Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency

[Takashi Iwai <tiwai@suse.de>]

On Mon, 17 Jun 2019 15:31:15 +0200,
Mauro Carvalho Chehab wrote:
> 
> Em Mon, 17 Jun 2019 09:01:06 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
> 
> > Hi Mauro,
> > 
> > On Fri, Jun 14, 2019 at 7:48 PM Mauro Carvalho Chehab
> > <mchehab+samsung@kernel.org> wrote:
> > > Em Fri, 14 Jun 2019 09:16:34 -0700
> > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:  
> > > > On Fri, 2019-06-14 at 13:04 -0300, Mauro Carvalho Chehab wrote:  
> > > > > Em Fri, 14 Jun 2019 08:49:46 -0700
> > > > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:  
> > > > > > Actually, this leads me to the patch acceptance criteria: Is there
> > > > > > value in requiring reviews?  We try to do this in SCSI (usually
> > > > > > only one review), but if all reviewers add a
> > > > > >
> > > > > > Reviewed-by:
> > > > > >
> > > > > > tag, which is accumulated in the tree, your pull machinery can
> > > > > > detect it on all commits in the pull and give you an automated
> > > > > > decision about whether to accept the pull or not.  If you require
> > > > > > two with one from a list of designated reviewers, it can do that as
> > > > > > well (with a bit more complexity in the pull hook script).
> > > > > >
> > > > > > So here's the question: If I help you script this, would you be
> > > > > > willing to accept pull requests in the media tree with this check
> > > > > > in place?  I'm happy to do this because it's an interesting
> > > > > > experiment to see if we can have automation offload work currently
> > > > > > done by humans.  
> > > > >
> > > > > We could experiment something like that, provided that people will be
> > > > > aware that it can be undone if something gets wrong.
> > > > >
> > > > > Yet, as we discussed at the Media Summit, we currently have an
> > > > > issue: our infrastructure lack resources for such kind of
> > > > > automation.  
> > > >
> > > > This one doesn't require an automation infrastructure: the script runs
> > > > as a local pull hook on the machine you accept the pull request from
> > > > (presumably your laptop?)  
> > >
> > > No, I run it on a 40-core HP server that it is below my desk. I turn it on
> > > only when doing patch review (to save power, and because it produces a lot
> > > of heat at the small room I work).
> > >
> > > Right now, I use a script with converts a pull request into a quilt tree.
> > > Then, for each patch there, after a manual review, I run:  
> > 
> > I think this process can be improved/optimized:
> > 
> > >         - checkpatch --strict  
> > 
> > Should have been done by your (trusted) submaintainer that sent you
> > the pull request.
> 
> Things are getting better with time, but I still catch issues - with
> seems to indicate that people sometimes forget to run it.
> 
> On a recent case, I received a few pull requests lacking the SOB from
> the patch author.

But you can simply refuse pulling in such a fatal-error case, instead
of fixing in your side.  And in a trivial error case, you can apply
the fix after pulling, too.

A push-back stops the flow, but at the same time, it'd help subsystem
maintainers learning something, so it's not always bad.


thanks,

Takashi