emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Confused by y-or-n-p


From: Gregory Heytings
Subject: Re: Confused by y-or-n-p
Date: Wed, 06 Jan 2021 23:57:02 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)



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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]