Re: RCS, again: another removed functionality: undo last-checkin

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 1 Oct 2015 20:36:19 +0300
> 
> On 10/01/2015 04:07 PM, Eli Zaretskii wrote:
> 
> > No.  Existing features might make no sense if (a) they didn't make
> > sense when introduced (it happens!),
> 
> You mean features that were useless or broken from the start?

Yes, something like that.

> > or (b) if the reason for their
> > existence is no longer valid, like a program that is no longer
> > available, or operation that is impossible with today's platforms, or
> > so clearly unused that there's no doubt it could be still useful to
> > anyone.
> 
> ...or became irreparably broken over time. That's a pretty high standard 
> to consider a feature for removal.

I indeed think that features should rarely be removed, only added.

> When I said "doesn't make sense", I meant sense in the context of the VC 
> framework. Which supposedly has some internal logic, ergonomics, etc.

Yes, but different VCSes have different internal logic, so something
might make sense with RCS, but not with Git, or vice versa.  That's
the crux of the problem we are discussing, I think, so the question is
whether a feature must make sense for every back-end for it to be
considered as sensible.

> > Breaking backward compatibility is about the worst crime package
> > maintainers could commit, in my opinion.  (I know it's not shared by
> > many of the others.)
> 
> This general opinion (and you're not alone holding it) is one of the 
> most tedious parts of the Emacs ecosystem, IME. It's not that I *love* 
> removing features, but being unable to do that at all makes the burden 
> of a maintainer harder when making changes or adding new features.

We do remove features that are obsolete or no longer needed.  E.g.,
see the 'lisp/obsolete' directory.  And yes, it is harder to make
changes while keeping backward compatibility.  But I don't think the
"solution" of breaking backward compatibility is the main or even
desirable one.  It should be the last resort, unless we are sure the
feature is of no use.

> > It makes veteran users of a package feel like
> > second-class citizens whose needs and workflows can be disregarded all
> > too easily.
> 
> Removing features is always a tradeoff. While no one wants to make old 
> users sad, if their needs would still be achievable at the cost of 
> workflow changes, we should be able to make that sacrifice.

For some features, a change of the workflow could be justified, for
others, those which are too popular and ubiquitous with their users,
it can't.  I disagree that this sacrifice is always possible, let
alone desirable.  Especially when the change in the workflow boils
down to "do it from outside Emacs".

> At some point in the future (distant, in all likelihood, so this is just 
> a rough example), I imagine that would mean sacrificing support for 
> antique VC backends entirely, in favor of simpler VC implementation, or 
> better support of the newer backends.

I think there's a better alternative: start a new front end, which
will only support a subset of back-ends.  Then the elders can
peacefully continue using the old front-end, which will more or less
stop being developed, only maintained whenever some of the
infrastructure changes absolutely require that.

> There's nothing stopping the veterans from adopting modern VCSes,
> you know.

Muscle memory is what stopping them.  It's a powerful thing.