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: Sun, 03 Jan 2021 17:16:19 +0200 Message-ID: <83lfdacapo.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> <87im8f951f.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36244"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, larsi@gnus.org, juri@linkov.net, drew.adams@oracle.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 03 16:17:37 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 1kw58R-0009IN-5b for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Jan 2021 16:17:35 +0100 Original-Received: from localhost ([::1]:35954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kw58Q-0007xV-6X for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Jan 2021 10:17:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kw57Y-0007MZ-S1 for emacs-devel@gnu.org; Sun, 03 Jan 2021 10:16:41 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43565) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kw57X-0004Hu-Hc; Sun, 03 Jan 2021 10:16:40 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2497 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kw57O-0003DA-Pe; Sun, 03 Jan 2021 10:16:31 -0500 In-Reply-To: (message from Richard Stallman on Sun, 03 Jan 2021 01:06:18 -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:262362 Archived-At: > From: Richard Stallman > Cc: larsi@gnus.org, eliz@gnu.org, rudalics@gmx.at, > emacs-devel@gnu.org, juri@linkov.net > Date: Sun, 03 Jan 2021 01:06:18 -0500 > > The dynamic that results is this: > > * A few people decide to make a UI change, which many have not noticed. > > * Some people eventually notice it in master, or in a release, and maybe > people start objecting. > > * At that point there is resistance to changing back. The resistance is understandable, but when this happens on master, and the objections are valid and supported by enough people, we usually augment or revert the change. When this happens in a released version, the resistance is justifiably stronger. But those cases should be (and are, IME) very rare. > The end result is a tendency to make changes because a few people > are in favor of them, and then it is hard to avoid them. There's no need and no justification for such generalizations based on a single incident. The adverse results you describe are extremely rare in practice. In some cases (some people say too many) the situation is actually the exact opposite: changes are being discussed "to death" and sometimes never implemented due to controversy. However, most changes are discussed by suitable groups of people, the various opinions are heard, and we usually try to accommodate them in the solution that is actually installed. So there's no need to present an isolated and exceptional incident as if it were the rule. > * A few people decide to make a UI change, which many have not noticed. > > * Someone points out that such a change should be discussed on > emacs-devel. So they do that, before installation. That is being done already, where we see it necessary. However, I see no reason to single out emacs-devel as the only medium suitable for such discussions. The Emacs issue tracker is another valid medium for that. Some changes are so significant that we do indeed decide to move them to emacs-devel, but I see no reason to do that for every behavior change. Moving a discussion has its downsides: depending on your MUA you can lose the threading capabilities; some people fail to notice and continue sending messages to the bug list; some people start cross-posting to both lists and thus increase the noise level; future forensics will be harder because references to discussions on emacs-devel are incomplete; etc. Thus, we insist on moving the discussions to emacs-devel only for significant enough issues -- and which ones are significant is a judgment call. > * If some are opposed, they install the feature with a variable to > enable it, disabled by default. This is already being done: every backward-incompatible change is either required to become compatible, or, if that's not feasible, to provide a way to get back the old behavior. In some rare cases this doesn't happen, but such mistakes are rare exceptions, they aren't the rule. > * Some time later -- it need not be soon -- poll the users and see who > likes it _and why_. Maybe change the default. Volunteers are welcome to step forward and take upon themselves the responsibilities for conducting such polls. Failing that, I don't see how we can promise doing this as a matter of routine.