Re: Reading of release notes (was Re: Still on stretch, getting ready for bullseye)
On Wed 18 Aug 2021 at 07:39:26 (-0400), The Wanderer wrote:
> On 2021-08-17 at 13:36, Brian wrote:
> > On Tue 17 Aug 2021 at 16:00:57 +0000, Andrew M.A. Cater wrote:
>
> >> Do the update to Buster - take it as slow as you need to. Bring it
> >> bang up to date.
> >>
> >> For the Buster to Bullseye -
> >>
> >> READ RELEASE NOTES :)
> >
> > Of course! Do users not do this as a standard procedure? :)
>
> I don't - because I don't upgrade from one stable release to another; I
> track testing, continuously, throughout the development cycle. As such,
> there is no point in the release cycle at which it makes sense for me to
> read the release notes; at the start of the release cycle they don't
> exist yet, so there's nothing for me to read, and by the time they're
> finalized and the release is ready, I'm already fully upgraded.
That seems perfectly reasonable: the issues that get included in the
Release Notes also get discussed here at the time they become issues.
And it also means that you never Upgrade from one release to the next.
> It always bothers me to see "read the release notes!" hammered on as a
> reasonable thing to expect users to do, in terms which presents users
> who fail to do so as unreasonable. It probably does make sense in the
> relatively limited (if also probably relatively common) case of
> upgrading from (old)stable to stable, but it is certainly not so
> universal a matter as to make failing to do it so inappropriate that
> hammering on it in such absolute terms becomes appropriate.
So exactly what's /bothering/ you? As a bystander.
If someone left a job on secondment, and then returned after two years,
they'd expect to be briefed on any changes in their responsibilities,
not just left to find out each time the shit hit the fan because they
hadn't foreseen a problem coming. If I was working under them,
I wouldn't want them shifting all the troubleshooting (or worse, the
responsibility) onto me just because they couldn't be bothered to get
up to speed.
> IMO, "fixing" an upgrade-related issue by documenting it in the release
> notes is not *and cannot be* enough; it has to be fixed in the relevant
> package(s), whether by making it not happen or by documenting it (and/or
> pointing to a place where documentation of that specific issue can be
> found) in a place which will be seen at the time when the upgrade is
> performed.
Many of these "fixes" are actually changes. Some of them are optional
changes that have to be decided upon and, once made, can't be rolled
back. Are you seriously suggesting sysadmins want to make decisions
like that in the middle of the upgrade, rather than at leisure before
they start? Or prolong the upgrade process by being referred to
documentation while services are stopped or being modified?
> Also IMO, the cases in which it is reasonable to expect users to seek
> out and read release notes before upgrading are quite limited; the
> release notes are useful as reference documentation for potential issues
> and for planning an upgrade if one wants to do that, but reading the
> release notes is not an inherent part of the upgrade process, and any
> design which assumes that it is or should be is IMO a broken design.
So it's "broken" for Debian to allow people to run non-Debian packages
(§4.2.2), be behind on point release (§4.2.3), run obsolete packages
(§4.2.5), have any cruft (§4.2.6), use any unofficial sources (§4.2.9)
or pin any packages (§4.2.10).
After all, it's not possible to even detect every one of these,
and certainly not "fix" them. If every package had to be able to
do any of that, nothing would make it out of the door. And how
exactly would you test all these contingencies? You're just
pushing all the sysadmins' responsibilities onto the DDs.
> (That latter is true for any product, not just for Debian.)
Sadly, this attitude has permeated a lot of organisations, which now
feel able to introduce major (changes to their) software with very
little guidance or training. Users are told to just "play around"
with it, to find out how to do the jobs that they were perfectly
able to do before. Never mind the fact that the organisation relies
on those jobs being completed in as timely a fashion as before.
And, of course, one result is that little cheatsheets of poor working
practices get passed around, because one person happens upon a shaky
procedure that might usually work.
> At the very least, if you want to get people to read the release notes
> before upgrading, you should arrange for the upgrade process to include
> a prominent "have you read the release notes yet?" prompt (with an
> option to cancel) before anything irrevocable is done. People could
> still ignore that, but it would at least bring the idea of reading the
> release notes into the actual upgrade procedure itself, rather than
> being an out-of-band thing which people have to think of and go out of
> their way to do manually before starting the upgrade.
Have you got a mechanism for that? Let's see:
. Keep a SHA digest of each machine's sources.list and sources.d/*,
and nag if it is seen to change. Any change.
Synaptic users will love that, as any use of its editor would
have to be followed by a good nagging, in case they might hit
Upgrade.
. Any Release Day should cock the hammer worldwide on any system that
includes any strings like *stable or testing in its sources.list,
so that the next upgrade attempt will trigger a good nagging.
The alternative for people who run rolling upgrades—let the world of
big Upgrades pass you by, without getting concerned or bothered by it.
Cheers,
David.
Reply to: