Re: Distribution and support for Debian-502-i386-netinst
- To: email@example.com
- Subject: Re: Distribution and support for Debian-502-i386-netinst
- From: Marc Haber <firstname.lastname@example.org>
- Date: Fri, 02 Dec 2011 19:21:49 +0100
- Message-id: <[🔎] E1RWXk5-0005xC-Ji@swivel.zugschlus.de>
- In-reply-to: <E1RRSKB-00089n-D9@mail.einval.com>
- References: <72D9A65742E17940B20894B08AA2AAA64B2C7F@nasanexd01g.na.qualcomm.com> <1321511968.2885.87.camel@deadeye> <20111117100026.GA24175@angband.pl> <E1RR8Ft-0004Mf-BG@swivel.zugschlus.de> <20111117202633.GH3366@decadent.org.uk> <20111117202633.GH3366@decadent.org.uk> <E1RRRmD-0008Id-BC@swivel.zugschlus.de> <E1RRSKB-00089n-D9@mail.einval.com>
On Fri, 18 Nov 2011 17:34:03 +0000, Steve McIntyre <email@example.com>
>Marc Haber wrote:
>>On Thu, 17 Nov 2011 20:26:33 +0000, Ben Hutchings
>>>I can't imagine why you would expect this to work.
>>I wouldn't. The site was just surprised by the point release and did
>>notice the deployment failure well before the announcement of the
>>point release was received. This deployment setup has been in effect
>>for a while, so I'd guess that this point release was the first to
>>break compatibility between older kernel/initrd and current kernel
>>udebs. If this is in fact the rule, I need to investgate why things
>>used to work for years, but not having older point releases around any
>>more, this is kind of hard to reproduce.
>snapshot.debian.org is very helpful if you want to try to
>reproduce/test this kind of thing.
Indeed, but it is considerably harder to do with the installer.
>>>Just point to the bug report and stop stirring.
>>Do you really think that this tone to users of your software will get
>>you any friends? You're being unnecessarily rude and impolite.
>You already posted a bug report and complained at Ben there, please
>don't continue here.
I still think that it is wrong to throw away the old kernel and the
old installer during a point release. Ben is not at fault for that, so
I'd really like to raise the issue here.
We don't even do that when stable transitions to oldstable, why do we
do this during a stable point release?
>>In nearly all non-kernel issues, we don't care zilch about enhancing
>>support and new features if there is the slightest chance of breaking
>>existing setups inside a stable release. I fail to see why the kernel
>>is so special that it warrants an exception. In fact, the kernel is
>>the last component of a distribution I would be willing to accept a
>>"more features" upgrade in a stable point release because of the vast
>>variety of things that can go wrong when a driver is updated _and_ the
>>fact that there is no way to install x.y.z-1 after the release of
>The kernel team have done an excellent job of backporting drivers for
>newer hardware for a number of releases now. Mistakes occasionally
Yes, the biggest of these being that we throw away the known-good old
version. snapshot.debian.net is a last resort.
>In terms of *why* those updates happen, that's quite simple: if Debian
>won't run on a user's new hardware, that user will typically simply
>ignore Debian. In (most) other packages, this isn't so critical - the
>latest shiny version doesn't matter that much.
When will we start allowing new shiny Libreoffice, KDE and GNOME?
> Up-to-date hardware
>support is one of the biggest issues I see reported about Debian with
>our long release cycles, so I'm very supportive of people like Ben who
>are directly spending a lot of their time on trying to solve the
I also support this and think it is a really good idea. But please
keep x.y.z-1 around and easily accessible when x.y.z is released.
-------------------------------------- !! 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