Re: Edit (to improve) old NEWS entry
Hi Nicholas,
On Wed, Jun 18, 2025 at 06:58:16PM -0400, Nicholas D Steeves wrote:
> Andrew Bower <andrew@bower.uk> writes:
> > On Mon, Apr 14, 2025 at 09:07:36PM -0400, Nicholas D Steeves wrote:
> >> Lorenzo <plorenzo@disroot.org> writes:
> >>
> >> > Hello Mentors,
> >> >
> >> > a user reported that some NEWS entries I wrote recently are hard to
> >> > understand and suggested few improvements.
> >> > Is it allowed to edit old NEWS entries, at the benefit of users
> >> > upgrading from Bookworm to Trixie?
> >> > (unstable/testing users won't see the edited NEWS)
> >>
> >> I'm not aware of any prohibition against this, and there's at least one
> >> reason why your motivation to improve NEWS entries for Bookworm2Trixie
> >> upgrades is something commendable:
> >>
> >> Debian is for its users; NEWS interrupts upgrades; if NEWS is not
> >> important, or if it isn't useful, then that NEWS wastes an unbounded
> >> number of users' time. Consequently, NEWS should be important, and NEWS
> >> should not taste users' time.
> >>
> >> So thank you! :) Doing this ahead of time, defensively, produces the
> >> situation where no news is good news.
> >>
> >> Oh, but please update (or allow your editor to update) the date stamp on
> >> the relevant NEWS entries. They look something like this:
> >>
> >> -- You Name <your@email.org> Mon, 14 Apr 2025 18:06:58 $timezone
> >
> > I passed on this advice to a maintainer who was consolidating two
> > entries where the second one superseded the first but to my surprise the
> > new consolidated entry was presented again on package upgrade due to the
> > timestamp even though the relevant version had been kept (at the later
> > of the two relevant versions).
>
> Previously we talked about editing entries. That's a simple case. To
> the best of my knowledge, this is the first time you've mentioned
> "consolidating two entries".
I see I have created confusion on multiple fronts... firstly I am not
the original poster, I only just joined the thread to continue the
discussion based on a different scenario where I wanted to apply the
advice from this thread.
> It was Soren who advocated for adding another entry, btw. Is there
> where you got the "superceded" idea? What do you mean by that, and what
> is your source for how entries are supposed to "supercede" each other?
By supersede I mean that there were already 2 news entries where the
*information* in the 2nd entry superseded the information in the 1st
entry. My proposal was to remove the 1st entry and reword the 2nd
entry. This is what I mean by "consolidation" - only leave the "net
effect" for the user to read.
> > Is this what you would expect? It doesn't seem optimal to use the
> > timestamp rather than the package version to decide what to present.
>
> I expected that you would manually test your work before uploading (or
> asking for sponsorship), because this kind of thing cannot be screened
I had offered a caveated suggestion to another maintainer.
> for with CI. As far as I know the timestamp is for human beings. It
That's what I thought but empirically it seems that it is more than
that.
> sounds like what probably happened is that you added a second NEWS entry
> with a new version and assumed that the older NEWS entry would be
> skipped. The logic is like this:
No, the second NEWS entry already existed and I proposed it retain its
version number so that it did not get presented again to users who
already had that version installed.
> Stable has 1.0-1
> Testing has 1.5-1
> Stable-next will have 1.5-1
>
> All up-to-date users in testing have been exposed to all NEWS entries
> between 1.0-1 and 1.5-1, as they updated. When users do stable2testing
> or when they will do an oldstable2stable upgrade (in the future), they
> will get all NEWS entries between 1.0-1 and 1.5-1 as a big batch <- this
> is why I readily agreed with your solution of editing the single bad
> NEWS entry rather than adding a new one.
My suggestion was aimed at future oldstable2stable upgraders.
What has happened is that to reduce noise for this important
constituency, we have increased it for users who were already on
testing/unstable. I think that's a fair trade but the hope and intention
was that there would be no trade-off because the latter would see
nothing.
> Of course, this is all speculation and a probable waste of time. What
> package is this for?
This was for cron: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107677
Perhaps this is a waste of time but if some of us end up with a better
understanding of how NEWS works then there is that.
Andrew
Reply to: