On Wed, Sep 14, 2022 at 11:05:30PM +0200, Tim Düsterhus wrote:
> On 9/14/22 22:43, Willy Tarreau wrote:
> > Thanks, but quite honnestly, even this one is not a commit message.
> 
> There really is not much to be explained for some obvious typo fixes in
> comments (i.e. not even changing the binary). I don't think the commit
> message was worse than Ilya's semi-regular typo patches.

That's what I suspected as well, my point was that encouraging someone
to go figure somewhere by following the link that in the end there was
nothing more to see didn't bring any value. However, just mentioning
the isolated systems touched by the patch can help quickly spot it when
a backport for a fix fails due to slightly different context.

> I've only put the PR link in the description, because I was unable to think
> of literally anything else that might be useful for a typo fix and I didn't
> want to leave the description empty (because CONTRIBUTING says I may not do
> so).

Yep, that rule generally helps thinking about what was not said in the
subject (e.g. "this just fixes 4 trivial typos in comments in mux_quic.c,
ssl_sock.c and xprt_quic.c").

> > You get the idea. Regarding the tag, it's fine (and even preferred) to
> > keep the signed-off-by if you edit the patch, you just add yours below
> > after a short description between square brackets. Example:
> 
> Understood. I've dropped it, because you said in the past that you are not
> editing patches containing a s-o-b.

You're absolutely right, but it's in fact a rule I use to gauge what
a contributor expects without wasting their time or a round-trip on a
trivial change. I think that if you send me a patch, you've rechecked
it 3 times to be certain it's OK before signing it, so what I could
take for a typo could also be a mistunderstanding on my side, thus I
will normally not change it without asking. On the contrary, an unsigned
commit reads to me like "do what you want with it, I don't care", and if
the effort of changing it is lower than that of requesting that it's
updated, and there's no perceived benefit in teaching the submitter how
to improve their future contributions, or it's really trivial, then I 
can update it.

> I'm not sending another patch or pursuing this patch further, because that
> is not a good use of either of our time. I just came across this unhandled
> PR in my Inbox and wanted to save you the effort of replying to the author /
> fixing the message yourself. Seeing that you took the effort of writing this
> long reply, I probably should've just ignored the patch entirely, because it
> ultimately wasted time for everyone involved.

No, not at all, quite the opposite! I just took this opportunity to explain
some tiny improvements to the process for everyone and the rationale behind
them, and also to help you figure more easily how to proceed next time
without having to hesitate too long. I know what it's like to submit a
patch, whatever the project, there's a lot of hesitation, at least 4 or 5
"git commit --amend", sometimes even a last-minute re-edit of the patch
itself. The simple fact that you explained the nature of your changes
indicates that it took you some thinking. That's what I want to help make
smoother so that you don't need to invest as much of your time on such
patches in the future. I could very well have re-edited it myself, but
that would not have been respectful of your effort.

Thanks!
Willy

Reply via email to