git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good
Date: Tue, 16 May 2017 12:02:53 +0200	[thread overview]
Message-ID: <CACBZZX5oVKGZLKgS4aF0=XXtHO67ynS+zxSopDN9ErJGzV9n-A@mail.gmail.com> (raw)
In-Reply-To: <xmqqh90l188a.fsf@gitster.mtv.corp.google.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.

  reply	other threads:[~2017-05-16 10:03 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 13:47 [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good Johannes Schindelin
2017-05-11 13:47 ` [PATCH 01/11] git-parse-remote: fix highly misleading man page Johannes Schindelin
2017-05-11 17:21   ` Stefan Beller
2017-05-11 19:14     ` Johannes Schindelin
2020-11-11 15:17     ` [PATCH 0/5] Remove now-unused git-parse-remote Ævar Arnfjörð Bjarmason
2020-11-11 17:37       ` Jeff King
2020-11-11 19:29         ` Junio C Hamano
2020-11-12 14:09         ` Ævar Arnfjörð Bjarmason
2020-11-12 18:42           ` Jeff King
2020-11-12 14:19       ` How do I "git fetch" with a custom <refspec> but a default remote? Ævar Arnfjörð Bjarmason
2020-11-12 18:51         ` Jeff King
2020-11-12 19:26           ` Chris Torek
2020-11-12 20:48             ` Jeff King
2020-11-12 21:22               ` Junio C Hamano
2020-11-14 12:12         ` Ævar Arnfjörð Bjarmason
2020-11-11 15:17     ` [PATCH 1/5] parse-remote: remove unused GIT_DIR variable Ævar Arnfjörð Bjarmason
2020-11-11 15:17     ` [PATCH 2/5] parse-remote: remove long-dead rebase code Ævar Arnfjörð Bjarmason
2020-11-11 15:17     ` [PATCH 3/5] parse-remote: remove long-dead git-pull.sh code Ævar Arnfjörð Bjarmason
2020-11-11 15:17     ` [PATCH 4/5] parse-remote: move used code to git-submodule.sh Ævar Arnfjörð Bjarmason
2020-11-11 15:17     ` [PATCH 5/5] parse-remote: remove this now-unused library Ævar Arnfjörð Bjarmason
2020-11-11 16:33       ` Junio C Hamano
2020-11-12 20:31         ` [PATCH v2 0/2] Retire git-parse-remote Junio C Hamano
2020-11-12 20:31           ` [PATCH v2 1/2] parse-remote: move used code to git-submodule.sh Junio C Hamano
2020-11-12 20:31           ` [PATCH v2 2/2] parse-remote: remove this now-unused library Junio C Hamano
2020-11-12 20:49           ` [PATCH v2 0/2] Retire git-parse-remote Jeff King
2020-11-12 21:25             ` Junio C Hamano
2020-11-13  9:42           ` Ævar Arnfjörð Bjarmason
2020-11-14 12:21           ` [PATCH v3 0/3] submodule sh->C & retire parse-remote Ævar Arnfjörð Bjarmason
2020-11-14 12:21           ` [PATCH v3 1/3] submodule: use "fetch" logic instead of custom remote discovery Ævar Arnfjörð Bjarmason
2020-11-16 21:13             ` Junio C Hamano
2020-11-14 12:21           ` [PATCH v3 2/3] submodule: remove sh function in favor of helper Ævar Arnfjörð Bjarmason
2020-11-14 12:21           ` [PATCH v3 3/3] parse-remote: remove this now-unused library Ævar Arnfjörð Bjarmason
2020-11-16 21:19             ` Junio C Hamano
2020-11-17 14:24               ` Ævar Arnfjörð Bjarmason
2017-05-11 13:47 ` [PATCH 02/11] Documentation: really deprecate .git/remotes/ and .git/branches/ Johannes Schindelin
2017-05-11 13:47 ` [PATCH 03/11] remote: warn loud and clear when .git/branches/ is *still* used Johannes Schindelin
2017-05-11 13:47 ` [PATCH 04/11] remote: warn loud and clear when .git/remotes/ " Johannes Schindelin
2017-05-11 13:47 ` [PATCH 05/11] Revert "Revert "Don't create the $GIT_DIR/branches directory on init"" Johannes Schindelin
2017-05-11 17:26   ` Stefan Beller
2017-05-11 13:47 ` [PATCH 06/11] PREVIEW: t5510: convert .git/remotes/ test to use a regular remote Johannes Schindelin
2017-05-11 13:47 ` [PATCH 07/11] PREVIEW: t5516: stop testing .git/branches/ functionality Johannes Schindelin
2017-05-11 13:47 ` [PATCH 08/11] PREVIEW: remote: remove support for migrating ancient remotes Johannes Schindelin
2017-05-11 13:48 ` [PATCH 09/11] PREVIEW: t5515: remove .git/remotes/ and .git/branches/ tests Johannes Schindelin
2017-05-11 13:48 ` [PATCH 10/11] PREVIEW: t0060: stop testing support for .git/remotes/ and .git/branches/ Johannes Schindelin
2017-05-11 13:48 ` [PATCH 11/11] PREVIEW: remove " Johannes Schindelin
2017-05-11 18:19   ` Stefan Beller
2017-05-11 19:19     ` Johannes Schindelin
2017-05-12  1:14 ` [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good Junio C Hamano
2017-05-12 10:18   ` Johannes Schindelin
2017-05-16  0:37     ` Junio C Hamano
2017-05-16  8:05       ` Ævar Arnfjörð Bjarmason
2017-05-16  9:06         ` Junio C Hamano
2017-05-16 10:02           ` Ævar Arnfjörð Bjarmason [this message]
2017-05-17  0:51             ` Junio C Hamano
2017-05-12 12:00   ` Junio C Hamano
2017-05-12 14:19     ` Johannes Schindelin
2017-05-12 17:38       ` Jonathan Nieder
2017-05-13 10:13         ` Junio C Hamano
2017-05-12 21:11       ` Junio C Hamano
2017-05-15  8:42         ` Johannes Schindelin
2017-05-12  9:11 ` Jeff King
2017-05-12 11:09   ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACBZZX5oVKGZLKgS4aF0=XXtHO67ynS+zxSopDN9ErJGzV9n-A@mail.gmail.com' \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).