At 2024-08-02 14:13-0700, Junio C Hamano <gitster@xxxxxxxxx> sent:
Is this blocking feedback? This strikes me as speculative
over-engineering
No, it is loosening a pattern that is overly tight and as a side
effect shortening the line to more readable length ;-).
Blocking or not?
If we are updating anyway, that question is irrelevant, no? This
version may hit 'seen' but until the next version comes it will not
advance to 'next'.
I can't figure out what you mean by this so I am going to proceed as
if you had simply said ‘non-blocking’.
It does not make much sense to ask if a suggestion is "blocking" or
"non-blocking". If you respond with a reasonable explanation why
you do not want to take a suggestion, I may (or may not) say that
your reasoning makes sense. IOW, making me say "it is blocking"
means you want to me to say that I won't listen to you no matter
what you say. That is rarely be the case.
I want you to do what Documentation/ReviewingGuidelines.txt says reviewers
should do:
- When providing a recommendation, be as clear as possible about whether you
consider it "blocking" (the code would be broken or otherwise made worse if an
issue isn't fixed) or "non-blocking" (the patch could be made better by taking
the recommendation, but acceptance of the series does not require it).
Non-blocking recommendations can be particularly ambiguous when they are
related to - but outside the scope of - a series ("nice-to-have"s), or when
they represent only stylistic differences between the author and reviewer.
Because I would rather not have what is likely to be a highly subjective
argument about this particular choice in a test script if we don't have
to have one.
I would also rather not put time into figuring out how best to rename the
function "old_curl_version" if it no longer checks for the particular
error produced when the curl version is too old, nor would I want to think
ahead about whether it is correct for these tests that use this function
to continue to pass if different variations on this error are raised.
There is one qualifying error currently, and that's what the test matches
against. Matching against hypothetical future errors is speculative
overengineering if it is not obvious how the errors will vary and what it
may mean if they do.
R
