Re: removing existing working drivers via staging

[Ingo Molnar <mingo@elte.hu>]

* david@lang.hm <david@lang.hm> wrote:

> On Thu, 15 Oct 2009, Ingo Molnar wrote:
>
>> * david@lang.hm <david@lang.hm> 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