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

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

[Junio C Hamano]

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.

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

[Tom G. Christensen]

On 01/02/15 23:48, Junio C Hamano wrote:
> 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

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

[Jeff King]

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

> 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

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

[Junio C Hamano]

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...