Re: [PATCH 1/2] send-email: remove non-working support for "sendemail.smtpssl"

From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Drew DeVault <sir@cmpwn.com>
Subject: Re: [PATCH 1/2] send-email: remove non-working support for "sendemail.smtpssl"
Date: Sat, 01 May 2021 11:15:43 +0200	[thread overview]
Message-ID: <87a6peyfry.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <8735vwfvln.fsf@evledraar.gmail.com>

On Sun, Apr 11 2021, Ævar Arnfjörð Bjarmason wrote:

> On Sun, Apr 11 2021, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>>
>>> So let's just remove it instead of fixing the bug, clearly nobody's
>>> cared enough to complain.
>>
>> Hmph, is that a safe assumption?  They may have just assumed that
>> you did not break it and kept using plaintext without knowing?  If
>> we do not give a warning when sending over an unencrypted channel in
>> red flashing letters, that is more likely explanation than nobody
>> caring that we saw no breakage reports, no?
>
> Maybe, I think in either case this patch series makes senes. We were
> already 11 years into a stated deprecation period of that variable, now
> it's 13.
>
> If we're going to e.g. emit some notice about it I think the parsing
> simplification this series gives us makes sense, we can always add a
> trivial patch on top to make it die if it sees the old variable.
>
> I don't think that's needed, do you?

Junio: *Poke*. Was going thorugh my outstanding patches, I still think
it makes sense to just pick this up. Especially with the related
discussion later about how common in-the-wild service providers would
just not support AUTH non-encrypted, so in practice I think it's even
less likely that anyone saw silent breakage as a result of this
already-deprecated variable being ignored.