On Tue, May 16, 2017 at 2:37 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > >> On Fri, 12 May 2017, Junio C Hamano wrote: >> >>> Is it really hurting us having to support these old information >>> sources we treat as read-only? >> >> Well, you frequently complain about my patches, claiming that they place >> unnecessary maintenance burden on you. >> >> I would say that the .git/remotes/ and .git/branches/ code is a lot more >> maintenance burden than most of my patches. > > I wasn't going to respond to this thread anymore, because I didn't > feel like the discussion was going anywhere, and you already said > you won't listen to me. > > You seem to be confused between "maintenance burden" and "burden on > the maintainer". I felt that it needs to be corrected for other > people reading this exchange from the sideline. > > When we worked to add feature X in the remotes subsystem, we > were slowed down because we had to adjust the code also for > .git/branches. The same story for feature Y. The same for > feature Z. This is getting ridiculous/cumbersome, especially > given that we know .git/branches is not used by anybody. > > That's a maintenance burden, and the "we" refers to the Git > development community as a whole, not the maintainer. It is not a > burden on _me_. > > Also important to notice is I do not know what X, Y and Z are with > respect to .git/branches feature. That is where "Is it really > hurting?" question comes from, but it hasn't been answered so far. > > What's burden on the maintainer is having to engage in a discussion > like this one, to reject an attempt to remove something that is not > demonstratably a maintenance burden, because the maintainer has to > act as the last-resort champion for the end-users, when others on > the list do not speak up X-<. 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. 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" Another open source community I'm involved in, the Perl language, used to have the same issue. Every time something like adding/changing/removing X came up we'd have the same discussion all over again from scratch. A lot of that was solved by having some written down guide for how deprecations are done: http://perldoc.perl.org/perlpolicy.html#BACKWARD-COMPATIBILITY-AND-DEPRECATION Of course that's not a perfect solution, nothing is, but it makes it much easier to get patches like this on some sort of well-defined track towards deprecation. > Yes, I know that proving that something we currently support is not > used by anybody is HARD [*1*]. That is why removal is costly. And > that in turn is why we need to be careful when adding new things and > making changes in general. >From my reading of this series we already have a solution to that. We start warning and then we find out who's using it. To the extent that that causes issues I think it's better to peel that discussion off this specific topic, i.e. the pain that causes users is not specific to this proposed update, but has to do with how we want to do deprecations in general, and the trade-offs involved with doing that. > [Footnotes] > > *1* Removal of "rsync" transport we did recently was a happy but > rare case. It has been broken for a few years without anybody > complaining.