Hi Andrew, 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". 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? > 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 for with CI. As far as I know the timestamp is for human beings. It 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: 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. Of course, this is all speculation and a probable waste of time. What package is this for? Thanks, Nicholas
Attachment:
signature.asc
Description: PGP signature