Signed-off-by: Adrian Bunk <[email protected]>
---
This patch was already sent on:
- 13 Jan 2006
--- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old 2006-01-13 15:02:15.000000000 +0100
+++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt 2006-01-13 15:06:19.000000000 +0100
@@ -164,0 +165,6 @@
+---------------------------
+
+What: Traffic Shaper (CONFIG_SHAPER)
+When: July 2006
+Why: obsoleted by the code in net/sched/
+Who: Adrian Bunk <[email protected]
--- linux-2.6.15-mm3-full/drivers/net/Kconfig.old 2006-01-13 15:06:34.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/Kconfig 2006-01-13 15:06:49.000000000 +0100
@@ -2663,7 +2663,7 @@
"SCSI generic support".
config SHAPER
- tristate "Traffic Shaper (EXPERIMENTAL)"
+ tristate "Traffic Shaper (OBSOLETE)"
depends on EXPERIMENTAL
---help---
The traffic shaper is a virtual network device that allows you to
>Subject: [2.6 patch] schedule SHAPER for removal
Replaced by what; the QoS subsystem?
> config SHAPER
>- tristate "Traffic Shaper (EXPERIMENTAL)"
>+ tristate "Traffic Shaper (OBSOLETE)"
> depends on EXPERIMENTAL
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
On Thu, Jan 19, 2006 at 03:11:50AM +0100, Adrian Bunk wrote:
> +What: Traffic Shaper (CONFIG_SHAPER)
> +When: July 2006
> +Why: obsoleted by the code in net/sched/
> +Who: Adrian Bunk <[email protected]
This length of obsolete cycles is way too short -- it's not even enough
time for a single release of a distro to ship with the feature marked as
obsolete.
-ben
On Thu, Jan 19, 2006 at 04:57:22PM -0500, Benjamin LaHaise wrote:
> On Thu, Jan 19, 2006 at 03:11:50AM +0100, Adrian Bunk wrote:
> > +What: Traffic Shaper (CONFIG_SHAPER)
> > +When: July 2006
> > +Why: obsoleted by the code in net/sched/
> > +Who: Adrian Bunk <[email protected]
>
> This length of obsolete cycles is way too short -- it's not even enough
> time for a single release of a distro to ship with the feature marked as
> obsolete.
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.
> -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
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.
-ben
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
On Sun, 2006-01-22 at 19:20 +0100, Adrian Bunk wrote:
> 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.
I think you're being unreasonable here.
Removing unused code from the kernel, I'm all for that. Really.
But this is userspace visible functionality, and more care needs to be
taken than just adding a few lines to an obscure file in the kernel.
I agree with Ben that the kernel needs to printk a stern warning *AT USE
OF THE FEATURE* for at least a year before such a feature can be
removed. In addition I think that in case such a feature isn't actually
harmful of further development (for example, it could be because it's
fundamentally broken locking wise, or holding back major improvements)
then a longer period of warnings should be no problem. Together with
that should probably be something to ask distros to stop enabling the
feature asap, or at least communicate it as deprecated in their
respective release notes.
On Sun, Jan 22, 2006 at 07:32:56PM +0100, Arjan van de Ven wrote:
> > The only supported combinations are distributions with the kernels they
> > ship.
>
> I think you're being unreasonable here.
Absolutely. The statement is also completely false.
Fedora rebases to a new point release shortly after they become available
(in reality usually just after the .1 -stable release).
At least part of the reason is that with 3-4000 changes going in upstream
per release, the amount of work backporting fixes is just totally impractical.
I just looked over feature-removal-schedule.txt for things that are probably
going to impact us due to our rebasing.
The only thing there that could cause major heartburn for FC4 users is
Dominik's proposal to remove PCMCIA control ioctl (scheduled for Last November).
Migrating already working setups from pcmcia-cs to pcmcia-utils when an
update kernel gets pushed out gives me the creeps, especially as we're still
not at a state where 'everything works' in our FC5-development branch.
(I'd feel more comfortable retrofitting this after its been through a stable
distro release and got a lot of exposure).
So if the old pcmcia code got ripped out in 2.6.17, chances are I'd carry
a 'revert this bunch of changes' patch for future FC4 updates.
Not that big a deal, but probably a days work to build & test,
plus ongoing maintainence to rediff the patch on future updates.
Pretty much everything else there is either only of impact to out-of-tree
modules, for which I couldn't really care less, or they're bits of functionality
that we have moved off already, or have disabled. (Though I'm not entirely
sure everything has moved off of V4L1 yet without going and checking)
> In addition I think that in case such a feature isn't actually
> harmful of further development (for example, it could be because it's
> fundamentally broken locking wise, or holding back major improvements)
> then a longer period of warnings should be no problem. Together with
> that should probably be something to ask distros to stop enabling the
> feature asap, or at least communicate it as deprecated in their
> respective release notes.
Sounds very practical, and something I'd be totally open to doing for Fedora.
Dave