Re: removing existing working drivers via staging

["Justin P. Mattock" <justinmattock@gmail.com>]

Ingo Molnar wrote:
> * 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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