From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Confused by y-or-n-p Date: Tue, 05 Jan 2021 16:54:45 +0200 Message-ID: <83turva0y2.fsf@gnu.org> References: <834kkcr1eo.fsf@gnu.org> <43b24209-fa65-0e26-7cbd-f99175a7ffd8@gmx.at> <87wnx7j5is.fsf@mail.linkov.net> <83im8qnyca.fsf@gnu.org> <83bleinmse.fsf@gnu.org> <56435592-d2d0-5fb6-977f-01e1931da835@gmx.at> <87k0t38g1z.fsf@mail.linkov.net> <83czyvkts6.fsf@gnu.org> <87bleetirr.fsf@mail.linkov.net> <87y2hhri3n.fsf@mail.linkov.net> <83pn2tkfg8.fsf@gnu.org> <871rf7ippu.fsf@mail.linkov.net> <83a6trg6mc.fsf@gnu.org> <83mtxqcauz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37725"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, emacs-devel@gnu.org, juri@linkov.net To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 05 16:23:50 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kwoBa-0009jY-NY for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 16:23:50 +0100 Original-Received: from localhost ([::1]:50122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwoBZ-0000Se-P2 for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 10:23:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54836) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwoAT-00083g-3N for emacs-devel@gnu.org; Tue, 05 Jan 2021 10:22:42 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35382) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwoAS-0006Hu-Fo; Tue, 05 Jan 2021 10:22:40 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2607 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwnjZ-0003Qv-4f; Tue, 05 Jan 2021 09:54:54 -0500 In-Reply-To: (message from Richard Stallman on Tue, 05 Jan 2021 01:25:59 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262525 Archived-At: > From: Richard Stallman > 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.)