Re: [PATCH v4] fast-(import|export): improve on commit signature output format

From: Patrick Steinhardt <ps@pks.im>
Date: Jul 8, 2025, 06:38 UTC
Message-ID: <aGy82TiRFcij5V_9@pks.im>
In-Reply-To: <xmqqwm8jxoj3.fsf@gitster.g>

On Mon, Jul 07, 2025 at 10:03:12PM -0700, Junio C Hamano wrote:

Show 52 quoted lines

> Christian Couder <christian.couder@gmail.com> writes:
> 
> > On Tue, Jul 8, 2025 at 12:58 AM Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> Christian Couder <christian.couder@gmail.com> writes:
> >>
> >> > This v4 is just about fixing a few bugs in the tests using the SHA-256
> >> > object format compared to the v3. (I had issues with CI tests on v3,
> >> > so I sent it without waiting for the results.)
> >>
> >> We haven't heard much after a few comments were posted on this
> >> latest round, since Elijah's
> >> <20250619133630.727274-1-christian.couder@gmail.com>; I understand
> >> that it would be the author's turn to respond (the response does not
> >> necessarily have to be with an updated iteration).  If so, let me
> >> mark the topic as Stalled in the draft of the latest issue of the
> >> "What's cooking" report.
> >
> > I will hopefully send a v5 later today.
> 
> Thanks.
> 
> By the way, I noticed that you often do not respond to reviews until
> the last minute, at the same time as when you send your next
> iteration, or even soon after doing so.
> 
> That is quite different from how other contributors operate, i.e.
> respond and engage in discussions triggered by the reviews, and
> after people involved in discussion got an (even rough) idea of what
> the right next step would be, if not a total consensus, send the
> next iteration.
> 
> I do not know which style is more efficient form of cooperation, but
> it somewhat makes my job harder, if I do not hear much _heartbeats_
> after I see review comments on the list.  I do not mind waiting for
> seeing the next round for quite a while---after all, any substantial
> (re)work takes time.  And responding to reviews may need thinking
> things through carefully, which may take some time, so I would not
> demand an immediate response, either.  But it would be nearly
> impossible to feel the current status of such a topic---a few review
> comments are seen, the author goes silent for a while, we cannot
> tell if the author is working on a new iteration or where the author
> and reviewers agree and disagree.
> 
> Also a review response that comes at the same time or immediately
> after a new iteration is already sent out makes it look like the
> author is refusing to continue discussion and reviewers are not
> welcome to make follow-up suggestions during such a discussion.
> 
> Instead, the next iteration comes as a fait accompli, and makes it
> less useful to continue the review discussion on the previous round
> by responding to such a late response.

I agree with your points. Overall, a fast response cycle is key to good collaboration from my point of view. I think it not only makes your life as a maintainer easier, but it also makes the reviewer feel like they are being heard and is the prerequisite for good discussion.

On our team's handbook page [1] we have the following couple of bullet points regarding how to respond to reviews:

  * Respond to feedback that you have received as fast as possible. A
    fast exchange is a prerequisite for a fruitful discussion and
    ensures that you keep momentum.

  * On the other hand, it shouldn’t be necessary to respond to every
    small typo correction in case you will send out the next version
    soon anyway. If it will take a while before you send the next
    version though it is nice to acknowledge nits, but mention that you
    will hold off sending a new version of the series until you got more
    feedback.

  * Consider the viewpoint of the other person and be ready to disagree and
    commit. Do not ignore feedback that you have received, as that will lead
    to frustration and a decreased likelihood for that person to review your
    future patch series.

Patrick

[1]: https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/git/#iteration