Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, May 16, 2017 at 11:06 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> This and many other discussions on-list basically come down to:
>>
>> 1. Someone wants to change X.
>> 2. This would have user impact Y.
>> 3. We have no way to quantify Y.
>> 4. X doesn't happen out of fear of unquantifiable Y.
>
> You forgot the step 0. You need to answer two questions: "Is
> changing X necessary?" and "Does that necessity outweigh the
> inconvenience caused to existing users by the deprecation flow?"
>
> You need to answer yes to both before you even consider going into
> the later steps.  Once that happens,...

Leaving this change aside, because I'm not interested in this change,
but the process in general. That seems to be a recipe for leaving
certain types of changes in deprecation limbo.

I.e. we say "don't use this", but can't follow through because users
may be inconvenienced, and we can't get any data on how users may be
inconvenienced because of the chicken & egg problem of not being able
to push those deprecations in any way to users.

One way to bridge that gap would be to e.g. have something similar to
"use <VERSION>" in Perl, where users can opt-in to new features & hard
deprecations.

Plenty of us package up git for other users, and various downstream
distributors (particularly more "bleeding edge" distros, like Arch,
Gentoo, Debian unstable) might be convinced to turn such a switch.

Wouldn't that go a long way to bridging the gap we have between
"surely nobody needs this anymore, let's remove it" and "we don't know
if someone really needs this, so let's keep it forever"?

>> It seems to me that a way out of this that would make everyone happy
>> is to go through some deprecation cycle through several releases with
>> X where:
>>
>> 1. We detect that you're using X, and warn that it's a candidate for deprecation
>> 2. In another release, we turn off the feature by default, threatening
>> that it's going to go away forever unless someone pipes up (this is
>> what we did with rsync:// accidentally)
>> 3. In another release, If you turned on the feature after #2 we emit a
>> noisy warning every time it's used, saying "it'll really be removed in
>> $release+1"
>
> ... the deprecation practice is very well established around here.

It seems pretty haphazard to me, is it even documented somewhere?

I'm talking about an establish process backed up by code, where for
example I can add an experimental feature in v2.14.0, it'll be subject
to change & warn unless you configure core.use_experimental=true or
whatever until v2.16.0, then it'll be considered stable, and changing
the semantics of any stable feature will require opt-in configuration
that'll only become default after N more release cycles where N is
some well-defined number.

Git's deprecation cycles, such as they are, seem to be better
described as: it'll be noted in the release notes or docs, then left
for some indeterminate amount of time until we have the argument on a
case-by-case basis of if/when/how to deal with that specific case.

This causes issues for devs wanting to deprecate things, but more
importantly doesn't at close the loop on deprecations by bringing
users into the loop. What am I to conclude as a user from various
mentions of deprecations in our docs? Some of which have been there
for 5-10  years.