Niels Thykier wrote...
> I appreciate it was (hopefully) not your intention. But with that
> remark you make me feel like I have wasted my time and effort trying to
> the write the Jessie release notes.
Niels,
offending you was certainly the least of my interests. If I did, please
accept my apologies.
The snide remark aimed against certain people who, usually in IRC,
answer questions mostly to demonstrate their arrogance like in
<a> Why is feature X in the new Debian release broken?
<b> Because you haven't read the release notes.
(Same for NEWS.Debian)
While technically true, that kind of behaviour drives people away from
Debian for no good reason.
Still, the release notes leave me somewhat unsatisfied.
As for jessie, the document (i.e. chapter 5) is quite handy to read and
tells you where you will certainly experience problems. You did a good
job about this. The sad part is there where many, many more issues,
I've already forgotten most of them and telling them now wasn't helpful
either.
You (i.e. the release team) are not to blame for this. You just collect
and edit what you get.
There was no input from my side. One reason was specific for jessie: It
took me until June 2015 to get systemd running reliably. That was of
course way too late to share experiences from the upgrades that
followed.
Second is a problem of social interaction. If I notice an upgrade issue
in a package, I'll have to deal with two parties instead of just one.
Should I ask the maintainer to submit the text to you, or do this on my
own at the risk this is considered hostile? Also the release notes
editors wish to be convinced, might deny the necessity, argue ... more
time needed to write things down ... there's so little incentive to
contribute to the release notes, and passing the information but other
means like blogs or (for the maintainer) NEWS.Debian avoids all the
hazzle.[1]
The third reason is the question of how much in detail the release
notes should actually be. In a strange way in the past they were too
short. That made me reluctant to suggest entries for low-popcon
packages as their significance doesn't match the prominence of being
mentioned in the notes.
So for example, of the many other things that bit me in the jessie
upgrade, the following two come to my mind:
- rss2email changed the configuration and database file, and their
location. A migration tool is provided (it caused grief, different
story, mostly PEBKAC).
- libnet-dns-perl had incompatible API changes, breaking applications.
Or for the upcoming stretch release: Perl will, among other things, now
check format strings at run time, whether the number of format
specifiers matches the number of parameters, and create warnings
otherwise.
Aside: Accidentially, two of these three are not administrative
issues. Are the release notes restricted to that area by intention or
did this just happen?
>From past upgrades I estimate I could easily create 20 to 30 bits of
that kind, and also that size. Do you consider such information
relevant for the release notes? Then, given enough input, that document
would become huge and rather a knowledge database. Probably nobody
would read that completely. But wouldn't have to: Per package
information, assessment ("you should know", "cosmetic issue", "manual
intervention suggested", "will break your package", and a few more), a
client using the list of packages actually installed - and I'd have a
list of issues I should be prepared for on this very computer. That was
nice to have.
This raises the old question: What needs to be done people will share
their upgrade experiences? A lot of knowledge is out there, it just
doesn't hit the release notes.
Regards
Christoph
[1] As an example for jessie:
| Package: munin-node
| Importance: should-know
|
| The ntp_* plugin now takes the ntp server address in numerical form
| instead of hostnames. You will have to install libnet-dns-perl before
| and re-run munin-node-configure after the upgrade. This will also
| break historical data. If that's an issue rename the rrd files on the
| server side accordingly, e.g. from
| <host>-ntp_time_fu_berlin_de-offset-g.rrd to
| <host>-ntp_130_133_1_10-offset-g.rrd
[ aside: Will this worked for me, it might not be the best solution ]
I can think of several ways getting flamed for this.
