Re: Confused by y-or-n-p

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: monnier@iro.umontreal.ca, juri@linkov.net, rudalics@gmx.at,
> 	eliz@gnu.org, emacs-devel@gnu.org, larsi@gnus.org,
> 	drew.adams@oracle.com
> Date: Tue, 05 Jan 2021 01:33:50 -0500
> 
>   >   So here's a suggestion: perhaps we should think about
>   > sometimes carrying out time-boxed experiments on the master branch in
>   > controversial cases.  For example: we add this keybinding now, to be
>   > revisited in 14/21/30 days and then a final discussion is taken to keep
>   > or revert it once people have gotten some experience with it.
> 
> That's fine with me, but there should be a variable to enable the
> changed behavior.  That makes the experiment painless for everyone else.

It is impractical to make a variable for every change in behavior.

In some cases the change itself is a variable: for example
introduction of a new option or a new binding gives you that variable
as a side effect.

In other cases we think we are fixing a bug or a confusing or
incorrect behavior.  In these cases we don't provide variables to get
back the incorrect behavior, nor should we.

In yet other cases the changes are so deep and significant that
providing backward compatibility would impose an impossible toll that
makes the entire changeset impractical.

The rare problematic cases are when the judgment call about the nature
of the change turns out to be a mistake.  We should try to minimize
such mistakes, but introducing a rule that _every_ change should
necessarily come with a variable to disable or revert it is a cure
that is much worse than the disease.  I'm against such absurd
measures.

To be practical, a rule like this would need to come with some
elaborate set of allowed exceptions, and that will undoubtedly trigger
endless discussions about whether this or that particular change is or
isn't an exception (because adding such compatibility shims is never a
job developers like).  We have such disputes already, because we do
attempt to provide such options where deemed necessary.  The proposed
rule will make that much worse, so I'm against such an absolute rule.