linux-kernel - Re: removing existing working drivers via staging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AD827B2.1080204@gmail.com>
Date:	Fri, 16 Oct 2009 00:58:42 -0700
From:	"Justin P. Mattock" <justinmattock@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	david@...g.hm, Greg KH <gregkh@...e.de>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: removing existing working drivers via staging

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/