netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: Andrew Morton <akpm@osdl.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	jgarzik@pobox.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] schedule SHAPER for removal
Date: Sun, 22 Jan 2006 19:20:34 +0100	[thread overview]
Message-ID: <20060122182034.GG10003@stusta.de> (raw)
In-Reply-To: <20060122174707.GC1008@kvack.org>

On Sun, Jan 22, 2006 at 12:47:07PM -0500, Benjamin LaHaise wrote:
> On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote:
> > Do we really have to wait the three years between stable Debian releases 
> > for removing an obsolete driver that has always been marked as 
> > EXPERIMENTAL?
> > 
> > Please be serious.
> 
> I am completely serious.  The traditional cycle of obsolete code that works 
> and is not causing a maintenence burden is 2 major releases -- one release 
> during which the obsolete feature spews warnings on use, and another 
> development cycle until it is actually removed.  That's at least 3 years, 
> which is still pretty short compared to distro cycles.
> 
> There seems to be a lot of this disease of removing code for the sake of 
> removal lately, and it's getting to the point of being really annoying.  If 
> the maintainer of the code in question isn't pushing for its removal, I see 
> no need to rush the process too much, especially when the affected users 
> aren't even likely to see the feature being marked obsolete since they don't 
> troll the source code looking for things that break setups.

The only supported combinations are distributions with the kernels they 
ship.

E.g. running Debian stable with any kernel > 2.6.8 is simply not 
supported.

The only point where users are supposed to see such changes are upgrades 
to new releases of their distribution - and this is anyways a point 
where you have to double-check whether it hadn't broken anything.

And the kernel isn't the main thing where things break during 
distribution upgrades - userspace breakages are much more common.

As an example, not so long ago an upgrade of the hdparm package on my 
Debian unstable system broke one local boot script I'm using because 
upstream removed the short form of an option.

And GNU make 3.81 will contain some backwards incompatible changes for 
being more POSIX compliant.

And many more changes I do not remember.

Distributions can document usespace-visible changes, but avoiding them 
is simply not possible.

> 		-ben

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

  reply	other threads:[~2006-01-22 18:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-19  2:11 [2.6 patch] schedule SHAPER for removal Adrian Bunk
2006-01-19 20:18 ` Jan Engelhardt
2006-01-19 21:57 ` Benjamin LaHaise
2006-01-21  0:48   ` Adrian Bunk
2006-01-22 17:47     ` Benjamin LaHaise
2006-01-22 18:20       ` Adrian Bunk [this message]
2006-01-22 18:32         ` Arjan van de Ven
2006-01-22 21:21           ` Dave Jones
  -- strict thread matches above, loose matches on Subject: below --
2006-01-11  0:37 [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL Adrian Bunk
2006-01-11  0:46 ` David Woodhouse
2006-01-11  0:53   ` Andi Kleen
2006-01-11  1:58     ` Alan Cox
2006-01-13 14:13       ` [2.6 patch] schedule SHAPER for removal Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060122182034.GG10003@stusta.de \
    --to=bunk@stusta.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bcrl@kvack.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).