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: Stefan Monnier
Subject: Re: Confused by y-or-n-p
Date: Mon, 04 Jan 2021 12:17:41 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> I don't mind having such a process,
> Me neither -- I think it sounds like something we should try out.

Indeed, it's something we do on a regular basis, but we only do it for
changes we presume won't be rejected.  I think it would indeed be
beneficial to change our habits in this regard and allow ourselves more
"daring" changes, with the understanding that there is a higher
probability that we may have to revert the default behavior.

[ FWIW, I also think there are changes we should keep enabled only on
  `master` *until* they stop being unpopular.  I'm specifically
  thinking of things like removal of obsolete features.  E.g. we could
  have features obsolete since Emacs-25 removed from `master` right
  now, but with a way to get them back on-demand, and with the
  understanding that they will still be present in the Emacs-28
  release.  ]

> I think the most natural person to manage the process would be the
> person that's proposing the change.  That is, we don't really need much
> formalism around this.

Agred.

> To take the already-mentioned case as an example -- Martin wanted to
> have us try out horizontal scroll bars to see whether they work, so he'd
> flip them on, and announce on emacs-devel "these default to on for a
> week, and then we'll discuss".

IME a week is not sufficient:
- Many users don't update from `master` on a daily basis.
- I `git fetch` daily from `master`, but I don't restart my Emacs
  sessions all the time (hell, I just tried `M-x emacs-uptime` and this
  Gnus-dedicated session "says 184 days, 18 hours, 28 minutes, 38
  seconds").
- Especially for UI changes (i.e. changes which don't break code but
  break muscle memory), it often takes a good month of active use before
  I can honestly say whether I prefer the old or the new behavior
  (rather than just being irked by the change itself).

So I think such changes should be introduced with:
- An explicit announcement.
- A clear way to get back the old behavior.
- A trial period in the order 2-3 months.


        Stefan




reply via email to

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