RFC: a code slush for 2.5?

RFC: a code slush for 2.5?

[Jeff Garzik]

(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

Re: RFC: a code slush for 2.5?

[Jeff Garzik]

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

Re: RFC: a code slush for 2.5?

[Dave Jones]

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

Re: RFC: a code slush for 2.5?

[george anzinger]

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   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: RFC: a code slush for 2.5?

[John Bradford]

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

Re: RFC: a code slush for 2.5?

[Gerhard Mack]

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

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: RFC: a code slush for 2.5?

[Alan Cox]

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