Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

On Thu, Aug 04, 2016 at 02:12:22PM -0700, Junio C Hamano wrote:

quoted

  2. Minor fixups noticed by maintainer, fixed while applying.

This includes different kinds of things:

    a) Trivially correct fixes given in other people's review.

    b) Minor fixups by the maintainer, to code.

    c) Minor fixups by the maintainer, to proposed log message.

    d) "apply --whitespace=fix" whose result I do not even actively
       keep track of.

[...]

I think I can

 * stop taking 2-a).  This is less work for me, but some
   contributors are leaky and can lose obviously good suggestions,
   so I am not sure if that is an overall win for the quality of the
   end product;

Actually, I think the 2-a class is what often saves a re-roll. Somebody
points out a typo in a commit message or a comment, and it quite often
gets picked up by you without having another round-trip to the list.

If you want to save work by not doing so, that's fine with me. But this
is the gamble I was talking about. I think it's actually often less work
to do the fixup than to look at another re-roll (especially with the
"leaky contributor" thing where you have to make sure all fixes were
applied). So it's a win if it saves the re-roll, but sometimes you end
up having to look at the re-roll anyway.

 * do a separate "SQUASH???" commit and send them out for 2-b).
   This is a lot more work for a large series, but about the same
   amount of work (except for "remembering to send them out" part)
   for a small-ish topic.  A contributor needs to realize that I
   deal with _all_ the incoming topics, not just from topics from
   one contributor, and small additional work tends to add up.

I think these are largely the same as 2-a. You are just wearing two
hats, reviewer and maintainer. Which I guess lets you take a shortcut
sometimes (and just fix without mentioning it), but fundamentally the
"gamble" aspect is the same, I think.

-Peff