Re: [PATCH v2 2/2] doc: advise batching patch rerolls

> Sorry for the late reply. I spent some time looking back through the
> discussions on earlier patch series, to check my patch itself, of course
> because I'm apparently a newcomer here.
> 
> On Wed, Jun 17, 2026 at 10:50:53AM -0700, Junio C Hamano wrote:
> > > If the comments require substantial rework, sending a new version
> > > +sooner may save reviewers from spending time on a version you already know will
> > > +change significantly.
> > 
> > I am not sure about this one.  Even though the intention to avoid
> > wasting reviewers' time spent on reading through the previous
> > version that will be invalidated is a good one, by definition, a
> > substantial rework will naturally take time, and it is better not to
> > rush and send an updated version with substantial changes that you
> > yourself haven't had a chance to thoroughly review yet.
> > 
> > In such a case, it would be a better idea to respond to the review
> > that made you realize a substantial rewrite is needed with a simple
> > "I'll make a substantial rework based on this comment, which would
> > invalidate this and that part of the current patch series, so please
> > do not waste reviewer cycles on these parts until I send an updated
> > series out" message.
> 
> I think the approach you recommended is obviously more reasonable.
> 
> It would be better to give everyone a heads-up "I am working on a
> new version."
> 
> I will improve this part accordingly.

> > > If the topic is close to being accepted and the remaining
> > > +comments are small, a quicker new version may also be fine.
> > 
> > I am not sure if this needs to be codified.
> > 
> > I often see (e.g., in patches from Patrick) that an iteration is
> > marked clearly as final candidate that the author is not aware of
> > any outstanding issues.  This encourages reviewers to ask "what
> > about this one raised there?"  to remind what is missed, or chime in
> > with "yup, this looks good" to show support.  Such a note is highly
> > recommended, but I do not see a need to say "the (supposedly) final
> > one is specifically allowed to be sent without waiting" even then.
> 
> Actually I thought Patrick would say something here ;-) so I waited a
> few more days to see whether anyone else had any suggestions.
> 
> But here I think Patrick's original intention is: If your series is
> *close* to be accepted, (while I'm not sure what the precise definition
> of this "close to be accepted", does it means: commented by Junio with
> "Looks good", or reviewed by the community/core contributors with "Makes
> sense"?) and this time there happens to be a small issue, you can
> re-roll quickly to make your series more "sturdy" to wait for
> maintainer's final examination and further merges.
> 
> So, I think the situation you are describing here is that this version
> of the patch has already been declared by the *author* to be the final
> version. (i.e. waiting for Junio to do the last exam)

> Therefore, I do not think the two situations conflict with each other,
> or are directly related. One concerns a patch that is already close to
> receiving the maintainer's final verdict, where a minor issue is
> discovered and the author quickly rerolls it. The other concerns an
> author who, without realizing that some issues remain unresolved, rushes
> to send what they believe to be the final version and then waits for the
> maintainer to review it.
> 
> For the latter case, I think it would be better to add a sentence along
> the lines of: "Before sending a new version/the final version, check
> once more whether there are any unresolved issues," if the existing
> documentation does not already make this clear.