(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
Jeff Garzik wrote:
> 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.
To clarify a bit, _CPU_ power management is looking quite nice, I was
referring mainly to PCI bus power management, and other host/bus PM issues
On Mon, Feb 03, 2003 at 03:01:23AM -0500, Jeff Garzik wrote:
> 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.
Feel free to munge http://www.codemonkey.org.uk/post-halloween-2.5.txt
into whatever you were thinking of. Or send me bits to add to it.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> My opinion of 2.5 could be summarized as, looking good, but still needs
> some fleshing out.
Agreed.
> Linux 2.5 is a really exciting leap forward, in a lot a ways.
Definitely, the new input layer is particularly cool, in my opinion.
Plus, it's still usable on my 8Mb laptop, and usable, but impractical
on my 4Mb laptop.
> 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 don't think a code freeze is appropriate yet, especially for small
additions, (auto-detection of more keyboards, and some kind of
blinking light output device, come to mind).
> 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.
Agreed.
> Specific areas I think deserve attention before "nothing but bug fixes"
I think we should separate areas in to, 'may have to justify patch !=
bug fix', and 'need a very good reason indeed why patch!=bug fix'.
> So, if I had to make the proposal concrete, I would propose:
> "code slush" effective immediately
Good idea.
> code freeze, Easter holiday (April 19?)
Might be too early for some areas. I think we should have two code
freeze dates, and assign as much as possible to the earlier one, and
all the rest 6-8 weeks later, (or whatever it takes).
We need as close to 100% of developers as possible saying that
2.5.final is perfect before we make is 2.6.0. Otherwise we are just
bumping the version number for the sake of it.
For example, modules have to be working 100%, (I don't mean everything
has to be compilable as a module, but rather that those that are need
to work), and this needs to have been tested for a couple of months,
in my opinon. Also, we are still getting loads of reports of problems
with ACPI and APICs, and we need to specifically document that these
are completely different things, (we have had some ambiguous bug
reports in the past).
John.
On Mon, 3 Feb 2003, Jeff Garzik wrote:
> 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?
It would be wise if a freeze was delayed until after at least IDE and
console switching both work reliably with preempt enabled.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
Dave Jones wrote:> On Mon, Feb 03, 2003 at 03:01:23AM -0500, Jeff
Garzik wrote:
>
> > 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.
>
> Feel free to munge http://www.codemonkey.org.uk/post-halloween-2.5.txt
> into whatever you were thinking of. Or send me bits to add to it.
>
> Dave
>
Back before halloween Linus said that he only required the code to be
in his in box by halloween and that he would continue to move stuff
into the kernel post halloween, but would not accept any new features
that were not already in his in box.
Has he ever said that he has finished the post halloween processing of
these new features?
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Mon, 2003-02-03 at 18:18, Gerhard Mack wrote:
> > So, if I had to make the proposal concrete, I would propose:
> > "code slush" effective immediately
> > code freeze, Easter holiday (April 19?)
> >
> > Comments/curses?
>
> It would be wise if a freeze was delayed until after at least IDE and
> console switching both work reliably with preempt enabled.
In which case April is unrealistic. Actually given the huge backlog
from Linus holiday its pointless to even try and guess at things right
now. We need to see what it looks like by about 2.5.63 to judge
Alan