Re: [RFC] How to accellerate the patch flow (or should we?)

> Taylor Blau <me@ttaylorr.com> writes:
> > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> > index 86ca7f6a78a..789febefff8 100644
> > --- a/Documentation/SubmittingPatches
> > +++ b/Documentation/SubmittingPatches
> > @@ -506,7 +506,10 @@ After the list reached a consensus that it is a good idea to apply the
> >  patch, re-send it with "To:" set to the maintainer{current-maintainer}
> >  and "cc:" the list{git-ml} for inclusion.  This is especially relevant
> >  when the maintainer did not heavily participate in the discussion and
> > -instead left the review to trusted others.
> > +instead left the review to trusted others.  Patch series must receive
> > +a positive "ack" from at least one contributor other than the primary
> > +patch series author in order to begin integrating it, subject to the
> > +maintainer's discretion.
> >
> >  Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
> >  `Tested-by:` lines as necessary to credit people who helped your
> > --- >8 ---
> 
> It would lead us into ugly awkwardness when we start clarifying what
> exactly "contributor" is in the new sentence, though.  If a person,
> whom none of us have ever heard of, sends their first message to
> this list saying "Ack", does that count?  If an active developer,
> who is known to be sloppier than others, sends an "Ack" to somebody
> else's patch that was posted 3 hours before (hence there wouldn't
> have sufficient time to think through the issues), how much should
> that "Ack" weigh?
> 
> Perhaps rephrasing it to "those who have helped in polishing the
> patches with their reviews and discussing the issues with the patch
> author" to tighten the language a bit may help?
> 
> I dunno, as that would still give the "ack right" to a random
> noisemaker who threw a drive-by "review" that did not add much value
> to the patches, if the original author responded "Thanks" out of
> courtesy.

> > I am not sure the idea of adding more maintainers is a good one or not.
> > Since I am not sure exactly what you are envisioning here, I think there
> > are a couple of cases:
> >
> >  - There is a quorum of maintainers, who are all collectively
> >    responsible for building 'jch', 'seen', 'next', and 'master'. Any two
> >    of them are required to agree to move a topic down in order to do so,
> >    without needing the other maintainer to weigh in.
> >
> >  - There are sub-system maintainers who are responsible for their own
> >    trees, and who send pull requests to the primary maintainer to
> >    integrate their trees back into the primary maintainer's.
> 
> Git is not large enough to benefit from the latter arrangement.
> What I had in mind was the former one.