lkml.org 
[lkml]   [2003]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRFC: a code slush for 2.5?
(ponderance on code freezes, releases, and whatnot)

My opinion of 2.5 could be summarized as, looking good, but still needs
some fleshing out.

Linux 2.5 is a really exciting leap forward, in a lot a ways. I'm still
hoping someone will draft a "What's new in 2.6?" document, just so we
have a nice _long_ list of all the improvements that have been made.

There are mumbles of things like "feature freeze" and "code freeze".
Theoretically we already had a feature, but, ahem. So, we need a
yes-really-feature-freeze-this-time.

But at the same time, I _disagree_ with some kernel developers'
assertion that we need a code freeze, if that is strictly the "nothing
but bug fixes" definition.

I believe 2.5/2.6 would be better served by an addition period between
feature freeze and code freeze, where implementation and "fleshing out"
can take place. Minor feature additions -- where required by existing
major features -- should be ok.

Specific areas I think deserve attention before "nothing but bug fixes"
includes a lot of driver implementation and testing for the driver
model. Pat's given us some cool stuff... that isn't used very much so
far. There are some key implementation decisions in that area that need
to be made, before a lot of that can be used, too. Power Management is
another area. That sorta fell by the wayside, IMO, but _is_ doable
given the current infrastructure that 2.5 now has. klibc is yet another
thing that needs tackling.

Maybe I am coming from a "driver guy" bias, but it seems like calling a
code freeze is premature. I know everybody's chomping at the bit for
2.6 to be released, already, gosh darn it. But please consider this
pause, as well.

So, if I had to make the proposal concrete, I would propose:
"code slush" effective immediately
code freeze, Easter holiday (April 19?)

Comments/curses?

Jeff



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.051 / U:3.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site