[Top][All Lists]

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

Following etc/NEWS on the development branch (was: Confused by y-or-n-p)

From: Kévin Le Gouguec
Subject: Following etc/NEWS on the development branch (was: Confused by y-or-n-p)
Date: Sat, 09 Jan 2021 15:06:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Cc: ghe@sdf.org, juri@linkov.net, rudalics@gmx.at,
>>      monnier@iro.umontreal.ca, eliz@gnu.org, emacs-devel@gnu.org
>> Date: Sat, 09 Jan 2021 01:34:32 -0500
>> I think I was the first person to complain about it.  An entry in
>> etc/NEWS would probably not have come to my attention, since I don't
>> check it regularly.  But a posting on emacs-devel is something I would
>> have noticed.
> Reading NEWS each time one updates from the development branch of the
> repository is something we expect from every user.  I suggest to start
> reading it when you build a new development version

FWIW, after pulling changes, one can ask Git "What changed in NEWS since
my last update?" like so:

    git diff @{1} etc/NEWS

"@{1}" means "the previous value of the current branch"
(cf. gitrevisions(7)).

While I personally spend a few minutes reading every commit after
fetching[1], I wouldn't fault anyone for not watching etc/NEWS
conscientiously.  All the ways I can think of[2] (that do not involve
fiddling with Git) fail to limit their output to my last update, so they
are not as user-friendly as ticking messages off a mailing list.

A list like emacs-diffs focusing on etc/NEWS would make sense to me; it
would be lower-volume than either bug-gnu-emacs or emacs-devel, so it
would be harder for readers to miss (documented) user-facing changes.

And such a list would expose those changes once they have taken a
concrete form (committed patches, applied and ready to be tried out);
this is easier to pick apart than week-long exchanges of dozens of
messages, featuring half as many versions of one (or more) patch(es),
all of them possibly dismissed because of unevocative subject lines.

NB: these are just ideas to make user-facing changes more visible for
people tracking the development branch; they are orthogonal to Gregory's
tentative guideline of considering new user settings for every change
worth mentioning in NEWS, to allow users to opt out of new features.

[1] With some amount of arbitrary filtering, e.g.
    - Is there a bug ID?
        ⇒ skim (probably saw it on bug-gnu-emacs)
    - Does the title refer to platforms/packages I don't care about?
        ⇒ skim (maybe some nice coding tricks to glean from the diff)
    - Does the message contain a non-ChangeLog summary?
        ⇒ read it (less noisy than ChangeLog entries IMO)
    - Does the commit have NEWS entries?
        ⇒ read them (to learn about new knobs to tweak)
    - Does the commit touch on areas of personal interest?
        ⇒ read the diff

[2] C-x p f etc/NEWS RET C-x v l

reply via email to

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