From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Confused by y-or-n-p Date: Wed, 06 Jan 2021 23:57:02 +0000 Message-ID: References: <834kkcr1eo.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> <83turva0y2.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36025"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: rms@gnu.org, juri@linkov.net, rudalics@gmx.at, Stefan Monnier , Eli Zaretskii , emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 07 01:01:01 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 1kxIjd-0009FR-8H for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 01:01:01 +0100 Original-Received: from localhost ([::1]:36946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxIjc-00064k-8S for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Jan 2021 19:01:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53390) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxIg7-0003bh-0v for emacs-devel@gnu.org; Wed, 06 Jan 2021 18:57:23 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:51035) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxIg4-0002cI-OE; Wed, 06 Jan 2021 18:57:22 -0500 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 106Nv6cL019487 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 6 Jan 2021 23:57:07 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 106Nvf9u017031; Wed, 6 Jan 2021 23:57:41 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:262639 Archived-At: > > Otherwise, you would have proposed a guideline. Which would be a fine > proposal, and AFAICT equivalent to what we have already. > Perhaps I did not look at the right place, but I do not see such a rule or guideline in CONTRIBUTE or elsewhere. What do you (and others) think of the following: Any change that matters to end-users should have an entry in etc/NEWS. *In principle, any such change should, unless it is an added feature, either require setting a variable to be enabled, or be reversible by setting a variable.* Try to start each NEWS entry with a sentence that summarizes the entry and takes just one line -- this will allow to read NEWS in Outline mode after hiding the body of each entry. >> ... developers start working on something thinking that scratching the >> current state of affairs to create something they believe is better >> without thinking about backwards compatibility ... > > Do you have any evidence to back up the claim that this has happened? > It happened with y-or-n-p; it would not have happened with the above guideline. It is happening in the "Stop frames stealing each other's minibuffers" thread, where it is not clear that the behavior that is being changed should remain available as is, next to other behaviors. Again this would not have happened with the above guideline. >> By the way, the feedback in this case came from Richard, who wanted the >> old behavior back, and he got it back in a few days. I'm curious >> whether this would have happened if the feedback had been sent by a >> random user. > > Of course Richard's word has more weight than that of "a random user". > This is expected in any project. (Guido in Python, Larry Wall in Perl, > Linus in Linux, etc.) > > But in general, backwards compatibility complaints are taken seriously > no matter the sender. In fact, this project sometimes goes to extreme > lengths simply to maintain backwards-compatibility even in the most > minor and inconsequential cases. > Of course I understand and expected that Richard's word has more weight. My fear was that if the same request had been made by someone else it would have been dismissed; I'm glad to read that this wouldn't have happened.