Andrew van der Stock wrote:
>
> First off, I agree with those people who think that this patch does not fix
> a bug in the 2.3 series, and should be a 2.5 feature.
--- Ok, here's the problem. Last even numbered kernel 2.2.0 came out in January of 1999. It was 2.2.5 before I saw it in any distros. 2.4 has yet to be released -- rumors it would be by Dec 1999, then the Feb 2000 to correspond w/windows 2000, now it's May. So we are talking minimum 16 months + maybe 2-3 for a stable release in a distro for 2.6. Even if 2.6 were to come out in half the time, that would mean a 2.6.0 date of Jan (assuming 2.4 shipped now), By the time it's gone through testing and a couple of dot revisions we're talking late spring/early summer to get something in that we want to have completed in Q3 of this year. The government is being advised to 'prefer' evaluated systems only (non-linux) 01-Jan-2000. So Linux starts 6 months behind right up front.Now what that means for us @ SGI, is that we've missed windows of opportunity. This is bad. We go w/plan B - ship IRIX 6.5.7 for CAPP and Trusted IRIX 6.5.x) for LSPP (evaluation process already underway). The Linux alternative is for us to provide code for 2.5, backport to 2.4 so we can release a stable kernel to customers and possibly backport to 2.2 as well if 2.4 isn't perceived as stable enough. We have limited resources -- we can spend time in innovation or time doing backports for multiple versions. Guess which makes the project more attractive to be funded? If "powers-over-me" decide that CAPP done a year late is too little too late, then it could be a problem -- especially since doing the evaluation evidence and the evaluation can be an expensive proposition (evals can easily run anywhere from $200K-600K depending on how much work the evaluator perceives they will have to do) -- so even if the work gets done later by someone else, there will still be that 'tab' to pay for any official branding.
I'm perfectly willing to put the code in an even release and mark it "experimental"/default to off, but not allowing a merge into the main stream is going to hinder having a useful product within the required time table. I'm trying to optimize for success while providing for safe impact to existing code. Would putting all the work under a config option and marking it EXPERIMENTAL make everyone happy enough for this to proceed? *Please*? :-)
-l -- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:12 EST