Re: Confused by y-or-n-p

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: rudalics@gmx.at, juri@linkov.net, emacs-devel@gnu.org
> Date: Tue, 05 Jan 2021 01:25:59 -0500
> 
>   > > That is true, but it may not be a problem.  To get useful results, we
>   > > don't need most of the community to switch.  It is enough to get
>   > > answers from a variety of users.
> 
>   > Which users should they be, and how do we find them and reach out to
>   > them?
> 
> One obvious way is to post an announcement on various mailing lists,
> asking people to repost it.  People will respond.
> 
>   > They should definitely be users who have the just-released version
>   > installed, which is why I mentioned the observation that the process
>   > of upgrading to a new version is slow and takes many moons.
> 
> That's why I suggest waiting before we ask.
> 
>   > Let's say we have half a dozen of such features, and we need to wait
>   > for the answers for a few months about each one of them.  Who can have
>   > a long enough attention span to manage such a polling system?
> 
> I propose a distributed system which needs no management.  The people
> who advocate changing the default to enable a given feature will
> probably speak up about it.  We just need a rule about the minimum
> time to wait after the release.
> 
> If they don't speak up, that suggests that having the new option is
> sufficient ;-}.

You are describing something that is already happening.  In the vast
majority of cases new features don't become the default, they are
introduced as opt-in features and announced in NEWS.  We consider
making them the default after several releases, if and when people
start asking us to enable a feature by default.

This is so even if the new feature is compatible with past behavior.
New features that break compatibility with past behavior are highly
unlikely to be turned on by default, much less so than features that
are deemed compatible.

My conclusion is that what you are proposing regarding the
introduction of new features into official releases already happens,
and there's no need for any changes in the process and the rules we
are using for that, in order to support what you'd like to see.

Once again, mistakes can happen, so please don't bring up this or that
single incident as evidence that the above description is incorrect or
skewed, unless you are prepared to argue that the mistakes happen too
often, and produce evidence of such high frequency.  A single incident
is not evidence strong enough that the process is flawed, and doesn't
justify complicating the process with additional rules associated with
high overhead.

(How to avoid mistakes during development, where some change is deemed
compatible and non-problematic whereas in fact it isn't, is a separate
issue, unrelated to the release process and the way we handle changes
in the defaults from release to release.  But that is not the issue
you raised in the message to which I'm responding.)