I missed this discussion in the thread "Moving drivers into
staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-" and I suspect that
many others did as well
for those that missed it, as I understand it the proposal is that 'ugly'
(working drivers that don't do things the kernel way and are perceived as
not being commonly used anymore) drivers will get moved into staging, and
if the driver maintainers do not clean them up within 6-9 months they will
be removed entirely.
the expectation is that if there are no maintainers for the driver who
care enough to do the cleanup they should be removed (with interested
users being able to take over maintaining the drivers if there the
maintainers are MIA)
I have several reactions to this
I think that 6-9 months (2-3 releases) is _far_ too short for users to
notice. most users will be using a distro kernel that is on a release
cycle longer than this (even if they are not using a 'enterprise' distro),
so their first inkling of a problem will be the driver disappearing on
them. Yes the driver can be recovered through git, bit at that point
there is going to be catch-up changes to make.
What happened to the desire that Linux would be able to use anything, and
once a driver was upstream changes to the kernel that would break it
should be fixed by whoever is introducing those changes? This seems to be
moving in the direction of only having drivers for fairly current, fairly
common hardware.
David Lang
[email protected] wrote:
> I missed this discussion in the thread "Moving drivers into
> staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-" and I suspect that
> many others did as well
>
> for those that missed it, as I understand it the proposal is that 'ugly'
> (working drivers that don't do things the kernel way and are perceived as
> not being commonly used anymore) drivers will get moved into staging, and
There was mention of "abandoned and unused" drivers (rather than "not
/commonly/ used anymore"), see e.g.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-10/msg05204.html
(2nd to last paragraph; thread continues with Greg's follow-up).
> if the driver maintainers do not clean them up within 6-9 months they will
> be removed entirely.
>
> the expectation is that if there are no maintainers for the driver who
> care enough to do the cleanup they should be removed (with interested
> users being able to take over maintaining the drivers if there the
> maintainers are MIA)
>
> I have several reactions to this
>
> I think that 6-9 months (2-3 releases) is _far_ too short for users to
> notice. most users will be using a distro kernel that is on a release
> cycle longer than this (even if they are not using a 'enterprise' distro),
> so their first inkling of a problem will be the driver disappearing on
> them. Yes the driver can be recovered through git, bit at that point
> there is going to be catch-up changes to make.
>
> What happened to the desire that Linux would be able to use anything, and
> once a driver was upstream changes to the kernel that would break it
> should be fixed by whoever is introducing those changes? This seems to be
> moving in the direction of only having drivers for fairly current, fairly
> common hardware.
AFAIU, mostly just code which is known to _not work_ anymore or has been
functionally replaced by an alternative drops out of the mainline. This
idea of using drivers/staging/ in the process is surely not going to
change that in principle; it will only raise awareness among active
kernel developers better than feature-removal-schedule.txt can do.
--
Stefan Richter
-=====-==--= =-=- -====
http://arcgraph.de/sr/
On Thu, 15 Oct 2009, Stefan Richter wrote:
> [email protected] wrote:
>> I missed this discussion in the thread "Moving drivers into
>> staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-" and I suspect that
>> many others did as well
>>
>> for those that missed it, as I understand it the proposal is that 'ugly'
>> (working drivers that don't do things the kernel way and are perceived as
>> not being commonly used anymore) drivers will get moved into staging, and
>
> There was mention of "abandoned and unused" drivers (rather than "not
> /commonly/ used anymore"), see e.g.
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-10/msg05204.html
> (2nd to last paragraph; thread continues with Greg's follow-up).
how can you tell if a driver is "unused"? (other than leaving it broken
for several years and getting no complaints)
>> if the driver maintainers do not clean them up within 6-9 months they will
>> be removed entirely.
>>
>> the expectation is that if there are no maintainers for the driver who
>> care enough to do the cleanup they should be removed (with interested
>> users being able to take over maintaining the drivers if there the
>> maintainers are MIA)
>>
>> I have several reactions to this
>>
>> I think that 6-9 months (2-3 releases) is _far_ too short for users to
>> notice. most users will be using a distro kernel that is on a release
>> cycle longer than this (even if they are not using a 'enterprise' distro),
>> so their first inkling of a problem will be the driver disappearing on
>> them. Yes the driver can be recovered through git, bit at that point
>> there is going to be catch-up changes to make.
>>
>> What happened to the desire that Linux would be able to use anything, and
>> once a driver was upstream changes to the kernel that would break it
>> should be fixed by whoever is introducing those changes? This seems to be
>> moving in the direction of only having drivers for fairly current, fairly
>> common hardware.
>
> AFAIU, mostly just code which is known to _not work_ anymore or has been
> functionally replaced by an alternative drops out of the mainline. This
> idea of using drivers/staging/ in the process is surely not going to
> change that in principle; it will only raise awareness among active
> kernel developers better than feature-removal-schedule.txt can do.
I don't disagree with dropping code that has been replaced by an
alternative. and I don't disagree much with dropping broken code.
however, what I think I saw proposed was to move drivers that need to be
'cleaned up', to staging and then dropping them if they don't get cleaned.
David Lang
On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> however, what I think I saw proposed was to move drivers that need to be
> 'cleaned up', to staging and then dropping them if they don't get cleaned.
What is "proposed" is the following:
- For drivers currently in the kernel tree, that the subsystem
maintainer, for whatever reason, feels is obsolete / broken /
needs major cleaning / wants to get rid of, can be submitted
to the staging maintainer to be moved to the drivers/staging/
directory.
- For a file to be moved into this directory, all of the normal
staging rules apply, including most importantly, a TODO file
listing what needs to be done to the driver in order for it to
be moved back into the main portion of the kernel tree.
- If, after a period of 3 releases, no work has been done on the
driver by anyone, the driver will be removed from the staging
tree, just like all drivers in the staging tree.
Note, as always, if a driver wants to come back from removal of the
staging tree, a simple email to the staging maintainer, along with the
promise that work will be done, is all it takes to resurrect it.
Sound good?
Now, where to put these "rules"? Any suggestions?
thanks,
greg k-h
On Thursday 15 October 2009 18:47:26 Greg KH wrote:
> On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > however, what I think I saw proposed was to move drivers that need to be
> > 'cleaned up', to staging and then dropping them if they don't get cleaned.
>
> What is "proposed" is the following:
>
> - For drivers currently in the kernel tree, that the subsystem
> maintainer, for whatever reason, feels is obsolete / broken /
> needs major cleaning / wants to get rid of, can be submitted
> to the staging maintainer to be moved to the drivers/staging/
> directory.
This is insanity and opens a door for various forms of abuse.
On Thu, Oct 15, 2009 at 07:42:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 15 October 2009 18:47:26 Greg KH wrote:
> > On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > > however, what I think I saw proposed was to move drivers that need to be
> > > 'cleaned up', to staging and then dropping them if they don't get cleaned.
> >
> > What is "proposed" is the following:
> >
> > - For drivers currently in the kernel tree, that the subsystem
> > maintainer, for whatever reason, feels is obsolete / broken /
> > needs major cleaning / wants to get rid of, can be submitted
> > to the staging maintainer to be moved to the drivers/staging/
> > directory.
>
> This is insanity and opens a door for various forms of abuse.
What do you mean by this? What kind of "abuse"?
On Thursday 15 October 2009 19:49:32 Greg KH wrote:
> On Thu, Oct 15, 2009 at 07:42:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 15 October 2009 18:47:26 Greg KH wrote:
> > > On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > > > however, what I think I saw proposed was to move drivers that need to be
> > > > 'cleaned up', to staging and then dropping them if they don't get cleaned.
> > >
> > > What is "proposed" is the following:
> > >
> > > - For drivers currently in the kernel tree, that the subsystem
> > > maintainer, for whatever reason, feels is obsolete / broken /
> > > needs major cleaning / wants to get rid of, can be submitted
> > > to the staging maintainer to be moved to the drivers/staging/
> > > directory.
> >
> > This is insanity and opens a door for various forms of abuse.
>
> What do you mean by this? What kind of "abuse"?
Typical situation:
You have driver for _really_ difficult hardware used by minority of total
users of a given subsystem. Said driver has no major problems except being
f*cking complicated (because of hardware) so it stays in the way of future
changes.
With the current system people making bigger changes have to comprehend
that difficult stuff [*]. This is a good thing in the long-term since it
results in the better overall system understanding, better knowledge of
"DO's and DON'T's" and better users' experience.
Now with the proposed scheme it is sufficient to throw said driver into
staging for few weeks and make future changes. Before users even notice
and complain they are screwed already since bringing the driver back is
no longer possible without big effort (+ subsystem is still evolving)..
This will result in a "new kernel new hardware" world that some distro
people have been silently trying to accomplish and in this brave new world
few key people have way too much advantage over everyone else.
[*] Booing current maintainer and forking also sometimes works.
(Though old drivers are still in place in such situation.)
On Thu, 15 Oct 2009 19:42:40 +0200
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Thursday 15 October 2009 18:47:26 Greg KH wrote:
> > On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > > however, what I think I saw proposed was to move drivers that need to be
> > > 'cleaned up', to staging and then dropping them if they don't get cleaned.
> >
> > What is "proposed" is the following:
> >
> > - For drivers currently in the kernel tree, that the subsystem
> > maintainer, for whatever reason, feels is obsolete / broken /
> > needs major cleaning / wants to get rid of, can be submitted
> > to the staging maintainer to be moved to the drivers/staging/
> > directory.
>
> This is insanity and opens a door for various forms of abuse.
It seems very sensible to me. It could be abused but that overlooks the
fact that Greg administers staging, the kernel community sees everything
and even if Greg doesn't keep things in order Linus would.
There are a pile of serial drivers that I think should get this
treatement (actually I was simply going to submit removal patches for
rio, riscom8, esp and a couple of others until this idea occurred)
On Thu, Oct 15, 2009 at 08:20:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 15 October 2009 19:49:32 Greg KH wrote:
> > On Thu, Oct 15, 2009 at 07:42:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Thursday 15 October 2009 18:47:26 Greg KH wrote:
> > > > On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > > > > however, what I think I saw proposed was to move drivers that need to be
> > > > > 'cleaned up', to staging and then dropping them if they don't get cleaned.
> > > >
> > > > What is "proposed" is the following:
> > > >
> > > > - For drivers currently in the kernel tree, that the subsystem
> > > > maintainer, for whatever reason, feels is obsolete / broken /
> > > > needs major cleaning / wants to get rid of, can be submitted
> > > > to the staging maintainer to be moved to the drivers/staging/
> > > > directory.
> > >
> > > This is insanity and opens a door for various forms of abuse.
> >
> > What do you mean by this? What kind of "abuse"?
>
> Typical situation:
>
> You have driver for _really_ difficult hardware used by minority of total
> users of a given subsystem. Said driver has no major problems except being
> f*cking complicated (because of hardware) so it stays in the way of future
> changes.
>
> With the current system people making bigger changes have to comprehend
> that difficult stuff [*]. This is a good thing in the long-term since it
> results in the better overall system understanding, better knowledge of
> "DO's and DON'T's" and better users' experience.
>
> Now with the proposed scheme it is sufficient to throw said driver into
> staging for few weeks and make future changes. Before users even notice
> and complain they are screwed already since bringing the driver back is
> no longer possible without big effort (+ subsystem is still evolving)..
But a driver in staging still has to be able to build, api changes are
not able to be ignored in it.
> This will result in a "new kernel new hardware" world that some distro
> people have been silently trying to accomplish and in this brave new world
> few key people have way too much advantage over everyone else.
I don't understand what you are referring to here.
How about we take it one proposed (real) situation at a time here? If
anyone objects to what is going on, please let me know.
thanks,
greg k-h
On Thursday 15 October 2009 20:46:56 Greg KH wrote:
> On Thu, Oct 15, 2009 at 08:20:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 15 October 2009 19:49:32 Greg KH wrote:
> > > On Thu, Oct 15, 2009 at 07:42:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Thursday 15 October 2009 18:47:26 Greg KH wrote:
> > > > > On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > > > > > however, what I think I saw proposed was to move drivers that need to be
> > > > > > 'cleaned up', to staging and then dropping them if they don't get cleaned.
> > > > >
> > > > > What is "proposed" is the following:
> > > > >
> > > > > - For drivers currently in the kernel tree, that the subsystem
> > > > > maintainer, for whatever reason, feels is obsolete / broken /
> > > > > needs major cleaning / wants to get rid of, can be submitted
> > > > > to the staging maintainer to be moved to the drivers/staging/
> > > > > directory.
> > > >
> > > > This is insanity and opens a door for various forms of abuse.
> > >
> > > What do you mean by this? What kind of "abuse"?
> >
> > Typical situation:
> >
> > You have driver for _really_ difficult hardware used by minority of total
> > users of a given subsystem. Said driver has no major problems except being
> > f*cking complicated (because of hardware) so it stays in the way of future
> > changes.
> >
> > With the current system people making bigger changes have to comprehend
> > that difficult stuff [*]. This is a good thing in the long-term since it
> > results in the better overall system understanding, better knowledge of
> > "DO's and DON'T's" and better users' experience.
> >
> > Now with the proposed scheme it is sufficient to throw said driver into
> > staging for few weeks and make future changes. Before users even notice
> > and complain they are screwed already since bringing the driver back is
> > no longer possible without big effort (+ subsystem is still evolving)..
>
> But a driver in staging still has to be able to build, api changes are
> not able to be ignored in it.
Sure, it will build at the of being submitted to staging..
> > This will result in a "new kernel new hardware" world that some distro
> > people have been silently trying to accomplish and in this brave new world
> > few key people have way too much advantage over everyone else.
>
> I don't understand what you are referring to here.
See my PM.
On Thu, 15 Oct 2009, Greg KH wrote:
> On Thu, Oct 15, 2009 at 08:20:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> On Thursday 15 October 2009 19:49:32 Greg KH wrote:
>>> On Thu, Oct 15, 2009 at 07:42:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>>> On Thursday 15 October 2009 18:47:26 Greg KH wrote:
>>>>> On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
>>>>>> however, what I think I saw proposed was to move drivers that need to be
>>>>>> 'cleaned up', to staging and then dropping them if they don't get cleaned.
>>>>>
>>>>> What is "proposed" is the following:
>>>>>
>>>>> - For drivers currently in the kernel tree, that the subsystem
>>>>> maintainer, for whatever reason, feels is obsolete / broken /
>>>>> needs major cleaning / wants to get rid of, can be submitted
>>>>> to the staging maintainer to be moved to the drivers/staging/
>>>>> directory.
>>>>
>>>> This is insanity and opens a door for various forms of abuse.
>>>
>>> What do you mean by this? What kind of "abuse"?
>>
>> Typical situation:
>>
>> You have driver for _really_ difficult hardware used by minority of total
>> users of a given subsystem. Said driver has no major problems except being
>> f*cking complicated (because of hardware) so it stays in the way of future
>> changes.
>>
>> With the current system people making bigger changes have to comprehend
>> that difficult stuff [*]. This is a good thing in the long-term since it
>> results in the better overall system understanding, better knowledge of
>> "DO's and DON'T's" and better users' experience.
>>
>> Now with the proposed scheme it is sufficient to throw said driver into
>> staging for few weeks and make future changes. Before users even notice
>> and complain they are screwed already since bringing the driver back is
>> no longer possible without big effort (+ subsystem is still evolving)..
>
> But a driver in staging still has to be able to build, api changes are
> not able to be ignored in it.
a driver in staging will be able to build, but a driver that was removed
after 6-9 months that a user discovered the removal of a year later when
they upgraded to a new distro release (say a normal ubuntu release after
staying on the old one for the 18 month support period) is likely to need
significant work to catch up with kernel changes in the meanwhile.
David Lang
* [email protected] <[email protected]> wrote:
>> But a driver in staging still has to be able to build, api changes
>> are not able to be ignored in it.
>
> a driver in staging will be able to build, but a driver that was
> removed after 6-9 months that a user discovered the removal of a year
> later when they upgraded to a new distro release (say a normal ubuntu
> release after staying on the old one for the 18 month support period)
> is likely to need significant work to catch up with kernel changes in
> the meanwhile.
Where do you get the 6-9 months from? Greg said he'll wait 3 kernel
releases. Here's the timeline of that:
- release x
- [A] driver moves into drivers/staging/ in the staging tree
- release x+1
- drivers/staging/ change gets merged in the x+2 merge window
- release x+2 - first kernel with the driver in staging
- release x+3
- release x+4
- driver gets removed in the staging tree
- release x+5 - 3 kernel releases passed - now it's removed
- removal propagates upstream in the x+6 merge window
- [B] release x+6
from the decision to move it into staging there's 4 kernel releases
during which the information is known, and 3 full kernel releases with
the driver is actually moved, and even in the 4th cycle there's still 3
months to undo the removal if there's objections (i.e. it's a
regression).
This means the timeline is 4*3 = 12 months _at minimum_. In practice it
will be more than a year - up to 1.5 years. Well within most distros ~3
months upstream kernel update schedule.
And if a distro does not follow the upstream kernel ... that's a self
inflicted wound and a distro problem really.
Ingo
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Thu, 15 Oct 2009 19:42:40 +0200
> On Thursday 15 October 2009 18:47:26 Greg KH wrote:
>> On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
>> > however, what I think I saw proposed was to move drivers that need to be
>> > 'cleaned up', to staging and then dropping them if they don't get cleaned.
>>
>> What is "proposed" is the following:
>>
>> - For drivers currently in the kernel tree, that the subsystem
>> maintainer, for whatever reason, feels is obsolete / broken /
>> needs major cleaning / wants to get rid of, can be submitted
>> to the staging maintainer to be moved to the drivers/staging/
>> directory.
>
> This is insanity and opens a door for various forms of abuse.
Being a maintainer, period, give the person these kinds of "abusive"
powers. The same thing that controls them already, will still control
them in this case with this new rule. And that's public pressure and
the will of the larger developer community.
On Thu, 15 Oct 2009, Ingo Molnar wrote:
> * [email protected] <[email protected]> wrote:
>
>>> But a driver in staging still has to be able to build, api changes
>>> are not able to be ignored in it.
>>
>> a driver in staging will be able to build, but a driver that was
>> removed after 6-9 months that a user discovered the removal of a year
>> later when they upgraded to a new distro release (say a normal ubuntu
>> release after staying on the old one for the 18 month support period)
>> is likely to need significant work to catch up with kernel changes in
>> the meanwhile.
>
> Where do you get the 6-9 months from? Greg said he'll wait 3 kernel
> releases. Here's the timeline of that:
that was the timeframe listed in the prior discussion, 3 kernel releases *
2-3 months/release works out to this
> - release x
> - [A] driver moves into drivers/staging/ in the staging tree
> - release x+1
> - drivers/staging/ change gets merged in the x+2 merge window
> - release x+2 - first kernel with the driver in staging
> - release x+3
> - release x+4
> - driver gets removed in the staging tree
> - release x+5 - 3 kernel releases passed - now it's removed
> - removal propagates upstream in the x+6 merge window
> - [B] release x+6
I would have seen this as
release x
driver moves into staging
release x+1
release x+2
release x+3
driver is removed
release x+4 no longer has the driver
> from the decision to move it into staging there's 4 kernel releases
> during which the information is known, and 3 full kernel releases with
> the driver is actually moved, and even in the 4th cycle there's still 3
> months to undo the removal if there's objections (i.e. it's a
> regression).
>
> This means the timeline is 4*3 = 12 months _at minimum_. In practice it
> will be more than a year - up to 1.5 years. Well within most distros ~3
> months upstream kernel update schedule.
yes, this is well past the distro update cycle for new releases, but not
within the user update cycle. there are a LOT of people who don't upgrade
every 6 months. every distro provides support for at least 12 months, if
not more. and even then there are a lot of people who drop out of their
distro support before they upgrade.
it's these users who will discover the missing driver and care about it,
not the distros.
personally, I try to do a kernel update every year (if security concerns
in a feature that I have compiled in don't force me to upgrade sooner)
sometimes with a distro upgrade, sometimes not.
David Lang
[email protected] wrote:
> a driver in staging will be able to build, but a driver that was removed
> after 6-9 months that a user discovered the removal of a year later when
> they upgraded to a new distro release (say a normal ubuntu release after
> staying on the old one for the 18 month support period) is likely to
> need significant work to catch up with kernel changes in the meanwhile.
I don't think this new mechanism is meant to be, or can ever be, a way
to remove things that work and that users need.
Hence the timeline of 3 releases per <[email protected]>
affects developers/ janitors much more than end users.
--
Stefan Richter
-=====-==--= =-=- -====
http://arcgraph.de/sr/
[email protected] wrote:
> it's these users who will discover the missing driver and care about it,
> not the distros.
I think we are talking about stuff of which users will typically
discover that it plainly doesn't work long before it vanishes from any
kernel distribution, or of which there is a superior alternative already
available.
--
Stefan Richter
-=====-==--= =-=- -====
http://arcgraph.de/sr/
On Thu, 15 Oct 2009, Stefan Richter wrote:
> [email protected] wrote:
>> a driver in staging will be able to build, but a driver that was removed
>> after 6-9 months that a user discovered the removal of a year later when
>> they upgraded to a new distro release (say a normal ubuntu release after
>> staying on the old one for the 18 month support period) is likely to
>> need significant work to catch up with kernel changes in the meanwhile.
>
> I don't think this new mechanism is meant to be, or can ever be, a way
> to remove things that work and that users need.
the problem I have is that the criteria that I have seen voiced for why
something would move into staging does not require that it not work. it
just requires that it need 'cleanup' of some sort.
removing something that worked always runs a significant risk that someone
out there 'needs' it (sometimes removing something that's broken, but
works in some cases causes similar problems)
> Hence the timeline of 3 releases per <[email protected]>
> affects developers/ janitors much more than end users.
it may be that I've jumped the gun here with my concerns, and should just
wait until something actually gets moved to staging to see what the actual
policies are going to be in practice, but the policies as written seem to
be very loose.
David Lang
On Thu, 15 Oct 2009, Stefan Richter wrote:
> [email protected] wrote:
>> it's these users who will discover the missing driver and care about it,
>> not the distros.
>
> I think we are talking about stuff of which users will typically
> discover that it plainly doesn't work long before it vanishes from any
> kernel distribution, or of which there is a superior alternative already
> available.
if there's a superior alternative already available staging isn't needed
(like the e1000 split), but I have also seen many new systems added to the
kernel that the author thinks covers all the old ones, only to find out
when people get it in the real world that it doesn't cover all existing
hardware. but this is an existing problem that is already being handled.
if it clearly doesn't work that is also fine with me.
however, that is not the criteria that has been expressed.
from earlier in this thread
- For drivers currently in the kernel tree, that the subsystem
maintainer, for whatever reason, feels is obsolete / broken /
needs major cleaning / wants to get rid of, can be submitted
to the staging maintainer to be moved to the drivers/staging/
directory.
it's the 'needs major cleaning' and 'wants to get rid of' portions that
concern me the most.
'obsolete' can mean that there is a superior alternative available, or it
could mean that the hardware the driver supports has not been manufactured
in several years (or, depending who you ask, several weeks ;-)
David Lang
On Thu, Oct 15, 2009 at 12:49:40PM -0700, [email protected] wrote:
> On Thu, 15 Oct 2009, Stefan Richter wrote:
>
> > [email protected] wrote:
> >> a driver in staging will be able to build, but a driver that was removed
> >> after 6-9 months that a user discovered the removal of a year later when
> >> they upgraded to a new distro release (say a normal ubuntu release after
> >> staying on the old one for the 18 month support period) is likely to
> >> need significant work to catch up with kernel changes in the meanwhile.
> >
> > I don't think this new mechanism is meant to be, or can ever be, a way
> > to remove things that work and that users need.
>
> the problem I have is that the criteria that I have seen voiced for why
> something would move into staging does not require that it not work. it
> just requires that it need 'cleanup' of some sort.
>
> removing something that worked always runs a significant risk that someone
> out there 'needs' it (sometimes removing something that's broken, but
> works in some cases causes similar problems)
>
> > Hence the timeline of 3 releases per <[email protected]>
> > affects developers/ janitors much more than end users.
>
> it may be that I've jumped the gun here with my concerns, and should just
> wait until something actually gets moved to staging to see what the actual
> policies are going to be in practice, but the policies as written seem to
> be very loose.
Loose is good, it gives us much room in which to work with, taking each
case as it comes.
Let's all see how it goes before declaring this whole thing is broken.
There's no reason we can't constantly reevaluate it as time goes on, as
nothing we ever do here is set in stone :)
thanks,
greg "the only constant is change" k-h
* [email protected] <[email protected]> wrote:
>> Hence the timeline of 3 releases per <[email protected]>
>> affects developers/ janitors much more than end users.
>
> it may be that I've jumped the gun here with my concerns, and should
> just wait until something actually gets moved to staging to see what
> the actual policies are going to be in practice, but the policies as
> written seem to be very loose.
Note that nothing has changed: the same fine folks who worked for 15+
years to give you the OS with the most built-in drivers on this planet
(more than 3000 drivers today and counting) are handling this too.
Please dont assume that this trend is now being reversed - to the
contrary - Linux being able to boot out of box on 99% of the systems
out there is one of our biggest strengths.
Ingo
* [email protected] <[email protected]> wrote:
> On Thu, 15 Oct 2009, Ingo Molnar wrote:
>
>> * [email protected] <[email protected]> wrote:
>>
>>>> But a driver in staging still has to be able to build, api changes
>>>> are not able to be ignored in it.
>>>
>>> a driver in staging will be able to build, but a driver that was
>>> removed after 6-9 months that a user discovered the removal of a year
>>> later when they upgraded to a new distro release (say a normal ubuntu
>>> release after staying on the old one for the 18 month support period)
>>> is likely to need significant work to catch up with kernel changes in
>>> the meanwhile.
>>
>> Where do you get the 6-9 months from? Greg said he'll wait 3 kernel
>> releases. Here's the timeline of that:
>
> that was the timeframe listed in the prior discussion, 3 kernel releases
> * 2-3 months/release works out to this
We do 4 kernel releases a year - that's almost exactly 3 months per
release - not 2-3 months.
It's one release per season / per quarter. That is a very natural
frequency for releases: both in the biological and in the socio/economic
spectrum.
Look at the release dates for version x, x-4 and x-8, they line up very
nicely:
v2.6.31: Date: Wed Sep 9 15:13:59 2009 -0700
v2.6.27: Date: Thu Oct 9 15:13:53 2008 -0700
v2.6.23: Date: Tue Oct 9 13:31:38 2007 -0700
And that kind of release date reliability is intentional and i think can
be expected to continue in the future as well. If you want to base
products on Linux you really want to know the latencies of upstreaming
and what to know when a driver or a kernel feature you'll rely on will
be released.
[ .31 was a bit earlier - partly due to the KS (which always delays the
cycle a tiny bit so it's good to save up for it) - and i'd personally
not mind if we did the .33 merge window before Christmas, to avoid the
distraction right in the middle of the holliday season. ]
Plus the inevitable fuzz of 1-2 weeks depending on the momentary QA
situation.
Ingo
Ingo Molnar wrote:
> * [email protected]<[email protected]> wrote:
>
>
>> On Thu, 15 Oct 2009, Ingo Molnar wrote:
>>
>>
>>> * [email protected]<[email protected]> wrote:
>>>
>>>
>>>>> But a driver in staging still has to be able to build, api changes
>>>>> are not able to be ignored in it.
>>>>>
>>>> a driver in staging will be able to build, but a driver that was
>>>> removed after 6-9 months that a user discovered the removal of a year
>>>> later when they upgraded to a new distro release (say a normal ubuntu
>>>> release after staying on the old one for the 18 month support period)
>>>> is likely to need significant work to catch up with kernel changes in
>>>> the meanwhile.
>>>>
>>> Where do you get the 6-9 months from? Greg said he'll wait 3 kernel
>>> releases. Here's the timeline of that:
>>>
>> that was the timeframe listed in the prior discussion, 3 kernel releases
>> * 2-3 months/release works out to this
>>
>
> We do 4 kernel releases a year - that's almost exactly 3 months per
> release - not 2-3 months.
>
> It's one release per season / per quarter. That is a very natural
> frequency for releases: both in the biological and in the socio/economic
> spectrum.
>
> Look at the release dates for version x, x-4 and x-8, they line up very
> nicely:
>
> v2.6.31: Date: Wed Sep 9 15:13:59 2009 -0700
> v2.6.27: Date: Thu Oct 9 15:13:53 2008 -0700
> v2.6.23: Date: Tue Oct 9 13:31:38 2007 -0700
>
> And that kind of release date reliability is intentional and i think can
> be expected to continue in the future as well. If you want to base
> products on Linux you really want to know the latencies of upstreaming
> and what to know when a driver or a kernel feature you'll rely on will
> be released.
>
> [ .31 was a bit earlier - partly due to the KS (which always delays the
> cycle a tiny bit so it's good to save up for it) - and i'd personally
> not mind if we did the .33 merge window before Christmas, to avoid the
> distraction right in the middle of the holliday season. ]
>
> Plus the inevitable fuzz of 1-2 weeks depending on the momentary QA
> situation.
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
man!! well put ingo,well put..
like I like to do:
CONFIG_INGO=y
regardless of what people say, the cycle is
perfect, as for the staging tough to say, I haven't found
anything in there yet that I need, but can only image I would..
Hope you guys enjoy japan for the kernel summit,
and BTW: please checkout "if you have time":
sasuke or "ninja warriror"....
Justin P. Mattock
On Thu 2009-10-15 09:47:26, Greg KH wrote:
> On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > however, what I think I saw proposed was to move drivers that need to be
> > 'cleaned up', to staging and then dropping them if they don't get cleaned.
>
> What is "proposed" is the following:
>
> - For drivers currently in the kernel tree, that the subsystem
> maintainer, for whatever reason, feels is obsolete / broken /
> needs major cleaning / wants to get rid of, can be submitted
> to the staging maintainer to be moved to the drivers/staging/
> directory.
> - For a file to be moved into this directory, all of the normal
> staging rules apply, including most importantly, a TODO file
> listing what needs to be done to the driver in order for it to
> be moved back into the main portion of the kernel tree.
> - If, after a period of 3 releases, no work has been done on the
> driver by anyone, the driver will be removed from the staging
> tree, just like all drivers in the staging tree.
>
> Note, as always, if a driver wants to come back from removal of the
> staging tree, a simple email to the staging maintainer, along with the
> promise that work will be done, is all it takes to resurrect it.
>
> Sound good?
>
> Now, where to put these "rules"? Any suggestions?
I'm not sure it sounds good. It should not be named 'staging' at
least.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
* Pavel Machek <[email protected]> wrote:
> On Thu 2009-10-15 09:47:26, Greg KH wrote:
> > On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > > however, what I think I saw proposed was to move drivers that need to be
> > > 'cleaned up', to staging and then dropping them if they don't get cleaned.
> >
> > What is "proposed" is the following:
> >
> > - For drivers currently in the kernel tree, that the subsystem
> > maintainer, for whatever reason, feels is obsolete / broken /
> > needs major cleaning / wants to get rid of, can be submitted
> > to the staging maintainer to be moved to the drivers/staging/
> > directory.
> > - For a file to be moved into this directory, all of the normal
> > staging rules apply, including most importantly, a TODO file
> > listing what needs to be done to the driver in order for it to
> > be moved back into the main portion of the kernel tree.
> > - If, after a period of 3 releases, no work has been done on the
> > driver by anyone, the driver will be removed from the staging
> > tree, just like all drivers in the staging tree.
> >
> > Note, as always, if a driver wants to come back from removal of the
> > staging tree, a simple email to the staging maintainer, along with the
> > promise that work will be done, is all it takes to resurrect it.
> >
> > Sound good?
> >
> > Now, where to put these "rules"? Any suggestions?
>
> I'm not sure it sounds good. It should not be named 'staging' at
> least.
Why not? It's a good match - a driver gets staged because it's not fit
for upstream.
The usual staging rules apply regardless of where the driver came from
(outside or inside the kernel): someone has to care about it and it has
to be fixed.
Ingo
On Mon, Oct 19, 2009 at 09:32:30AM +0200, Ingo Molnar wrote:
>
> * Pavel Machek <[email protected]> wrote:
>
> > On Thu 2009-10-15 09:47:26, Greg KH wrote:
> > > On Thu, Oct 15, 2009 at 09:39:51AM -0700, [email protected] wrote:
> > > > however, what I think I saw proposed was to move drivers that need to be
> > > > 'cleaned up', to staging and then dropping them if they don't get cleaned.
> > >
> > > What is "proposed" is the following:
> > >
> > > - For drivers currently in the kernel tree, that the subsystem
> > > maintainer, for whatever reason, feels is obsolete / broken /
> > > needs major cleaning / wants to get rid of, can be submitted
> > > to the staging maintainer to be moved to the drivers/staging/
> > > directory.
> > > - For a file to be moved into this directory, all of the normal
> > > staging rules apply, including most importantly, a TODO file
> > > listing what needs to be done to the driver in order for it to
> > > be moved back into the main portion of the kernel tree.
> > > - If, after a period of 3 releases, no work has been done on the
> > > driver by anyone, the driver will be removed from the staging
> > > tree, just like all drivers in the staging tree.
> > >
> > > Note, as always, if a driver wants to come back from removal of the
> > > staging tree, a simple email to the staging maintainer, along with the
> > > promise that work will be done, is all it takes to resurrect it.
> > >
> > > Sound good?
> > >
> > > Now, where to put these "rules"? Any suggestions?
> >
> > I'm not sure it sounds good. It should not be named 'staging' at
> > least.
>
> Why not? It's a good match - a driver gets staged because it's not fit
> for upstream.
>
> The usual staging rules apply regardless of where the driver came from
> (outside or inside the kernel): someone has to care about it and it has
> to be fixed.
Exactly, I'll keep the name for now, it's easier that way.
thanks,
greg k-h
for those who were reading this thread, the topic has come up again in the
thread titled
[PATCH 1/4] strip: move driver to staging
where a driver is being moved to staging because it does not have a
maintainer and the only changes to it for some time have been due to
kernel API changes.
the maintainer of the area feels that it's too much work to allow the
driver to remain because it must be updated when kernel APIs change.
this is exactly the 'wants to get rid of' category I mentioned being
concerned about below.
I don't know what was decided at the kernel summit where this was
discussed, how easy is it supposed to be to drop drivers out of the
kernel?
David Lang
On Thu, 15 Oct 2009, [email protected] wrote:
> Date: Thu, 15 Oct 2009 12:57:49 -0700 (PDT)
> From: [email protected]
> To: Stefan Richter <[email protected]>
> Cc: Ingo Molnar <[email protected]>, Greg KH <[email protected]>,
> Bartlomiej Zolnierkiewicz <[email protected]>,
> linux-kernel <[email protected]>
> Subject: Re: removing existing working drivers via staging
>
> On Thu, 15 Oct 2009, Stefan Richter wrote:
>
>> [email protected] wrote:
>>> it's these users who will discover the missing driver and care about it,
>>> not the distros.
>>
>> I think we are talking about stuff of which users will typically
>> discover that it plainly doesn't work long before it vanishes from any
>> kernel distribution, or of which there is a superior alternative already
>> available.
>
> if there's a superior alternative already available staging isn't needed
> (like the e1000 split), but I have also seen many new systems added to the
> kernel that the author thinks covers all the old ones, only to find out when
> people get it in the real world that it doesn't cover all existing hardware.
> but this is an existing problem that is already being handled.
>
>
>
> if it clearly doesn't work that is also fine with me.
>
> however, that is not the criteria that has been expressed.
>
> from earlier in this thread
>
> - For drivers currently in the kernel tree, that the subsystem
> maintainer, for whatever reason, feels is obsolete / broken /
> needs major cleaning / wants to get rid of, can be submitted
> to the staging maintainer to be moved to the drivers/staging/
> directory.
>
> it's the 'needs major cleaning' and 'wants to get rid of' portions that
> concern me the most.
>
> 'obsolete' can mean that there is a superior alternative available, or it
> could mean that the hardware the driver supports has not been manufactured in
> several years (or, depending who you ask, several weeks ;-)
>
> David Lang
>
From: [email protected]
Date: Mon, 26 Oct 2009 21:23:35 -0700 (PDT)
> where a driver is being moved to staging because it does not have a
> maintainer and the only changes to it for some time have been due to
> kernel API changes.
It's also in a non-working condition and we are very confident
nobody is using it.
It hasn't been maintained at all for years, it's just taking up
space.
On Mon, 26 Oct 2009, David Miller wrote:
> From: [email protected]
> Date: Mon, 26 Oct 2009 21:23:35 -0700 (PDT)
>
>> where a driver is being moved to staging because it does not have a
>> maintainer and the only changes to it for some time have been due to
>> kernel API changes.
>
> It's also in a non-working condition and we are very confident
> nobody is using it.
>
> It hasn't been maintained at all for years, it's just taking up
> space.
this is the first I have seen anyone say that the driver doesn't work,
everything prior had been "I don't know that it works, do you?"
I agree that it's unlikly that many people are using this.
David Lang
> this is exactly the 'wants to get rid of' category I mentioned being
> concerned about below.
Why are you concerned, its dead, its defunct, nobody cares, nobody uses
it. The same is true of a lot of other junk drivers we have and need to
get rid of.
> I don't know what was decided at the kernel summit where this was
> discussed, how easy is it supposed to be to drop drivers out of the
> kernel?
If there is someone with the hardware its a trivial git command to put it
back and they can then maintain it, but I'm pretty sure that there won't
be anyone using this ancient hardware and I really doubt the code even
works after the big tty re-arrange.
There is a difference between ancient junk people care about (however
crazy) and stuff that is just dead and slowing real work (and I have
several serial drivers I want to bit bucket such as rio and esp)
On Mon, Oct 26, 2009 at 10:50:25PM -0700, [email protected] wrote:
> I agree that it's unlikly that many people are using this.
Then why argue about it?