threads / discuss / 38480

RFD: should we do another 2.3-rc for t9001-noxmailer? I'd say not

Subject: RFD: should we do another 2.3-rc for t9001-noxmailer? I'd say not

## tl;dr

4 messages between Feb 1, 2015 and Feb 2, 2015.

replies: 3people: 3as markdown or json

Junio C Hamano· Feb 1, 2015, 22:48 UTC · lore

I was reviewing the recent bugs and fixes for the last time, and was wondering if we want to do 2.3-rc3 with build fix for those with ancient cURL (tc/curl-vernum-output-broken-in-7.11) and workaround for those with Perl with older Getopt::Long (tc/t9001-noxmailer).

 - The former is not a regression between 2.2 and 2.3 (i.e. 2.2
   already had the same use of curl-config output).

 - The latter, strictly speaking, is a regression in that tests used
   to pass but tests in 2.3 no longer pass for those with older
   Getopt::Long.

But the latter is about a test script that lacks work-around, and more importantly, everybody has lived with unconditional X-mailer: output, and the minority with ancient Getopt::Long will survive without being to able to give the new --no-xmailer (or --noxmailer) option just fine.

So currently I am leaning to keep these two fixes where they are and tag 2.3 final without them in a few days.

Tom G. Christensen· Feb 2, 2015, 09:29 UTC · re: Junio C Hamano · lore

Re: RFD: should we do another 2.3-rc for t9001-noxmailer? I'd say not

On 01/02/15 23:48, Junio C Hamano wrote:

Show 15 quoted lines

> I was reviewing the recent bugs and fixes for the last time, and was
> wondering if we want to do 2.3-rc3 with build fix for those with
> ancient cURL (tc/curl-vernum-output-broken-in-7.11) and workaround
> for those with Perl with older Getopt::Long (tc/t9001-noxmailer).
>
>   - The former is not a regression between 2.2 and 2.3 (i.e. 2.2
>     already had the same use of curl-config output).
>
>   - The latter, strictly speaking, is a regression in that tests used
>     to pass but tests in 2.3 no longer pass for those with older
>     Getopt::Long.
>
> So currently I am leaning to keep these two fixes where they are and
> tag 2.3 final without them in a few days.
>

Leaving them for a later release is fine by me. These two patches cover only what broke from 2.2.2 to 2.3, there are further patches needed to actually complete a build atleast on RHEL3.

-tgc

Jeff King· Feb 2, 2015, 20:38 UTC · re: Junio C Hamano · lore

Re: RFD: should we do another 2.3-rc for t9001-noxmailer? I'd say not

On Sun, Feb 01, 2015 at 02:48:00PM -0800, Junio C Hamano wrote:

Show 20 quoted lines

> I was reviewing the recent bugs and fixes for the last time, and was
> wondering if we want to do 2.3-rc3 with build fix for those with
> ancient cURL (tc/curl-vernum-output-broken-in-7.11) and workaround
> for those with Perl with older Getopt::Long (tc/t9001-noxmailer).
> 
>  - The former is not a regression between 2.2 and 2.3 (i.e. 2.2
>    already had the same use of curl-config output).
> 
>  - The latter, strictly speaking, is a regression in that tests used
>    to pass but tests in 2.3 no longer pass for those with older
>    Getopt::Long.
> 
> But the latter is about a test script that lacks work-around, and
> more importantly, everybody has lived with unconditional X-mailer:
> output, and the minority with ancient Getopt::Long will survive
> without being to able to give the new --no-xmailer (or --noxmailer)
> option just fine.
> 
> So currently I am leaning to keep these two fixes where they are and
> tag 2.3 final without them in a few days.

Yeah, I think that is sensible, especially given that the ancient --noxmailer platform reportedly cannot even fully build with v2.2.

I thought at first that we also had a regression in pruning with alternates, but it looks like that bug actually went into v2.2. I still think we would want the fix fairly promptly, but it does not need to happen before v2.3 is released.

-Peff

Junio C Hamano· Feb 2, 2015, 20:52 UTC · re: Jeff King · lore

Re: RFD: should we do another 2.3-rc for t9001-noxmailer? I'd say not

Jeff King <peff@peff.net> writes:

> I thought at first that we also had a regression in pruning with
> alternates, but it looks like that bug actually went into v2.2.  I still
> think we would want the fix fairly promptly, but it does not need to
> happen before v2.3 is released.

Yes, this was regression in v2.2 we did not catch X-<. The fix looks so obvious that it appears nothing should break, but that tends to be the famous last words, so...