Re: Gitlab Migration

[Eli Zaretskii]

> Cc: rms@gnu.org, danflscr@gmail.com, philipk@posteo.net,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 31 Aug 2021 22:17:10 +0300
> 
> Or as I've been saying, we love additions but hate changes.

Emacs is an old and _stable_ package.  "Stable" means just that:
features burned into users' muscle memory don't just change every
weekend.  So we do it slowly, cautiously, and preferably via opt-in
features, because we respect our users and their habits.  It is
maddening to have to re-learn your editor just because you've
upgraded.

> we could start a discussion into changing this, or at least
> instituting some procedures for making important
> non-backward-compatible changes.

We _have_ procedures for making backward-incompatible changes, and we
use those procedures all the time.

> Nobody with power to make decisions has shown any interest, however.

Please forgive me the lecture that you don't need: talking never moves
anything in Emacs, never did, never will.  Change in Emacs comes when
motivated individuals sit down and do the work.  If someone presents
the code to make some backward-incompatible change in a way that
leaves it opt-in, the resistance is likely to be much lower than it
may seem when such changes are just "discussed".  For the same reason,
it is hard to show interest in an Nth theoretical discussion that
never results in any code; by contrast, having a code presented to us
_requires_ "The Powers That Be" to make decisions, whether they want
it or not.

Backward-incompatible changes in the _defaults_ take much longer and
might be met with more resistance, that's true.  But this is a feature
in Emacs; see above.  My advice is not to insist on having each
incompatible change to become the default the moment it is coded: it
will in the long run make such changes much easier to introduce, and
everyone wins.