Re: [PATCH v5] http: do not ignore proxy path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux