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: Recentish C-s M-y change Date: Mon, 04 Jan 2021 17:03:25 +0200 Message-ID: <83zh1obv7m.fsf@gnu.org> References: <<87r1na4tyu.fsf@gnus.org>> <<87tus6tj7s.fsf@mail.linkov.net>> <<87a6txigm1.fsf@gnus.org>> <<874kk5lzew.fsf@mail.linkov.net>> <> <<87eej8ifll.fsf@mail.linkov.net>> <> <<87h7o3k5b5.fsf@mail.linkov.net>> <> <> <83wnwwg8iu.fsf@gnu.org> <837dovg687.fsf@gnu.org> <83pn2mcb78.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35858"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ams@gnu.org, juri@linkov.net, larsi@gnus.org, 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 Mon Jan 04 16:07:17 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 1kwRS0-0009EN-Nk for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 16:07:16 +0100 Original-Received: from localhost ([::1]:55146 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwRRz-0000fN-Pu for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 10:07:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51536) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwROi-0006EJ-Oy for emacs-devel@gnu.org; Mon, 04 Jan 2021 10:03:53 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36019) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwROg-0002rL-OY; Mon, 04 Jan 2021 10:03:50 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2505 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwROQ-0007QD-Ln; Mon, 04 Jan 2021 10:03:35 -0500 In-Reply-To: (message from Richard Stallman on Mon, 04 Jan 2021 00:17:45 -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:262432 Archived-At: > From: Richard Stallman > Cc: ams@gnu.org, emacs-devel@gnu.org, larsi@gnus.org, > drew.adams@oracle.com, juri@linkov.net > Date: Mon, 04 Jan 2021 00:17:45 -0500 > > 1. When people see a UI change being discussed in a bug report context, > people should try to speak up and say, "Remember, the rule is we should > discuss this on emacs-devel. Let's move this discussion there now!" > > 2. Someone should send mail to emacs-devel with a Subject line saying > "UI change proposal: ", and a body proposing and explaining > the change. People can always speak up, and someone -- anyone -- can always start a discussion about some change they think deserves a discussion. There's no need for rules to do that. What I object to is a rule that a change cannot be committed before such a discussion happens and runs to its conclusion. > 3. If someone notices the change after it is release, and objects, and > if the discussion on emacs-devel did not happen as the rule calls for, > then we would drop the usual reluctance to undo a change that had been > in a release. I object to this as well. I see no reason to undo a change just because someone objects to it. That'd mean we give single individuals too much power, just because they post to emacs-devel. It's a sure recipe for stalemate. Based on the experience, this is completely unjustified, as in the vast majority of cases the changes are sensible, and mistakes are in good faith and usually quickly fixed. > 4. We would not actually revert the change -- after all, some people > do like the changed behavior. Instead, we would add a variable to > specify whether to use the changed behavior or the old behavior, and > make the old behavior the default. Like I said, this already happens, at least as a policy. You can find many threads here and on the bug list where changes are requested to become backward-compatible or provide options to revert to previous behavior. There's no need for any new rules here, certainly not rules that will so significantly slow down development.