Re: Debian i386 architecture now requires a 686-class processor
On Tue, 10 May 2016 08:13:40 +0200, Christoph Biedl
<debian.axhn@manchmal.in-ulm.de> wrote:
><a> Why is feature X in the new Debian release broken?
><b> Because you haven't read the release notes.
>(Same for NEWS.Debian)
Would you instead want the text part from release notes and/or
NEWS.Debian pasted in IRC?
>While technically true, that kind of behaviour drives people away from
>Debian for no good reason.
Those people who complain about releases changing things in a
distribution won't find a OS fitting their needs at all.
>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.
In my experience, and contrary to my own loudly voices predictions,
the sysvinit -> systemd migration was quite painless aside from a lot
of local changes getting lost during the upgrade because systemd
doesn't care. That's something one needs to get used to, but the
apache 2.2 => 2.4 upgrade was much more painful than all systemd
issues I experienced with jessie combined. Incidentally, the (few)
wheezy systems that are left up to now are those running more complex
apache setups.
>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]
File a bug against the package, slap the future "release-notes" tag on
it, and let automatism and check lists do the rest.
>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.
We could have a "show-release-notes" package containing a script that
scans (pre-upgrade) the installed packages and shows all release-notes
relevant to those packages. This would need the release notes to be in
a somewhat automatically-selectable format, most easily a http-served
directory somewhere with a packagename.txt for each package that has
relevant text that went past the package maintainer and the release
team. Some thought needs to go in there for the cases where package
foo is superseded by foo2. Most easily this could be a simple symlink
in the releasenotes directory.
>>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.
Oh, You were faster with the idea than I was.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: