[OKS] Kernel release management

[OKS] Kernel release management

[Bill Davidsen]

I suggested that 2.5 be opened when 2.4 came out, so I like the idea of
2.7 starting when 2.6 is released. I think developers will maintain the
2.6 work out of pride and desire to have a platform for the "next big
thing." And their code can always be placed on hold for 2.7 until they
clarify their thinking on 2.6, if that's really needed.

Most of the developers take pride in what they did in the recent past and
would certainly not be a problem if a fix were needed. And if there is a
reasonable -rc process there shouldn't be any major bugs of the "start
over" variety.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [OKS] Kernel release management

[Adrian Bunk]

On Mon, 1 Jul 2002, Bill Davidsen wrote:

> I suggested that 2.5 be opened when 2.4 came out, so I like the idea of
> 2.7 starting when 2.6 is released. I think developers will maintain the
> 2.6 work out of pride and desire to have a platform for the "next big
> thing." And their code can always be placed on hold for 2.7 until they
> clarify their thinking on 2.6, if that's really needed.
>
> Most of the developers take pride in what they did in the recent past and
> would certainly not be a problem if a fix were needed. And if there is a
> reasonable -rc process there shouldn't be any major bugs of the "start
> over" variety.

This is IMHO a very bad idea:
- A stable base to start new development upon is a very good thing
  (and I don't believe in the stability of 2.6.0).
- Something I'd call the "Debian syndrome" will appear:
    There are only very few developers who run Debian stable because even
    during the release cycle there's always an unstable tree. One of the
    results is that many of the Debian developers aren't that much
    focussed on working on the next stable release (the current stable
    release of Debian is nearly two years old and doesn't support kernel
    2.4...).
  If 2.7 doesn't start before 2.6 is _really_ stable everyone who wants
  to have a new development tree is more interested in making 2.6 a really
  good kernel instead of focussing immediately on 2.7 .


Just my 0.02 (Euro-)cent
Adrian

-- 

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
								Alan Cox

Re: [OKS] Kernel release management

[Justin M. Forbes]

On Mon, 1 Jul 2002, Adrian Bunk wrote:

> On Mon, 1 Jul 2002, Bill Davidsen wrote:
> 
> > I suggested that 2.5 be opened when 2.4 came out, so I like the idea of
> > 2.7 starting when 2.6 is released. I think developers will maintain the
> > 2.6 work out of pride and desire to have a platform for the "next big
> > thing." And their code can always be placed on hold for 2.7 until they
> > clarify their thinking on 2.6, if that's really needed.
> > <Snip>
> 
>   If 2.7 doesn't start before 2.6 is _really_ stable everyone who wants
>   to have a new development tree is more interested in making 2.6 a really
>   good kernel instead of focussing immediately on 2.7 .
> 
> 
> Just my 0.02 (Euro-)cent
> Adrian
> 

I would have to agree with Adrian here.  I think that with the feature 
freeze happening in October, many people will be sitting on new ideas for 
immediate implementation into 2.7 as soon as that kernel is available.  If 
the venue is there for 2.7 work to really begin, alot of attention will be 
taken away from the 2.6 tree.  If 2.6 is out for a while before 2.7, 
people will spend more time stabilizing the 2.6 tree, and can continue to 
test their pre 2.7 work against current 2.6.  Waiting doesnt stifle the 
work process for new features too much, but tends to encourage 
stabilization of 2.6 in the meantime.

Justin

Re: [OKS] Kernel release management

[Bill Davidsen]

On Mon, 1 Jul 2002, Adrian Bunk wrote:

> This is IMHO a very bad idea:
> - A stable base to start new development upon is a very good thing
>   (and I don't believe in the stability of 2.6.0).
> - Something I'd call the "Debian syndrome" will appear:
>     There are only very few developers who run Debian stable because even
>     during the release cycle there's always an unstable tree. One of the
>     results is that many of the Debian developers aren't that much
>     focussed on working on the next stable release (the current stable
>     release of Debian is nearly two years old and doesn't support kernel
>     2.4...).
>   If 2.7 doesn't start before 2.6 is _really_ stable everyone who wants
>   to have a new development tree is more interested in making 2.6 a really
>   good kernel instead of focussing immediately on 2.7 .

Seems the reason this is being suggested is that lots of new stuff got
shoved into 2.2 and 2.4 in the early stages, and they were NOT stable.
Since far more influential people than I are suggesting this, obviously at
least some of the folks feel it's worth trying something different.

The maintainer can alway push really new stuff into 2.7, and Linus can
always refuse to take a feature into 2.7 until something else is fixed in
2.6. Looking at how hard people are working to backport things from 2.5 to
2.4 I have faith that extra effort will be taken.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [OKS] Kernel release management

[Rob Landley]

On Tuesday 02 July 2002 11:13 am, Bill Davidsen wrote:

> The maintainer can alway push really new stuff into 2.7, and Linus can
> always refuse to take a feature into 2.7 until something else is fixed in
> 2.6. Looking at how hard people are working to backport things from 2.5 to
> 2.4 I have faith that extra effort will be taken.

People using the systems in production are going to care about stability.  
People selling systems to people using them in production are going to care 
about the stable series.  This means most of the people who have day jobs 
working with Linux at places like Red Hat and IBM.

Look at the pressure to get stuff into 2.4 when it's already in 2.5.  Because 
2.4 is what people are actually using, and 2.5 is really just for os 
development and testing (and general playing with) at this point.

Looking at it another way, Kieth Owens writing kbuild 2.5 and pushing hard 
for its inclusion didn't stop other people from patching the endless series 
of bugs in the old one.  Even when Kieth at least considered this 
counterproductive.

Rob

Re: [OKS] Kernel release management

[Matt Bernstein]

On Jul 2 Rob Landley wrote:

>People using the systems in production are going to care about stability.
>People selling systems to people using them in production are going to care
>about the stable series.  This means most of the people who have day jobs
>working with Linux at places like Red Hat and IBM.

So maybe look at it the other way around. You can start running Linux 2.6
on your Really Important Machines when Linux 2.7 forks. There'll be plenty
of version-number-junkies who will find the 2.6 bugs under common loads;
until the fork, 2.4 ought to be adequate. Except of course for your Scary
Desktop Machines, where you'll find the Mega Features (eg low-latency) a
bit harder to resist :)

Matt

Re: [OKS] Kernel release management

[Russell King]

On Tue, Jul 02, 2002 at 09:19:41PM -0400, Rob Landley wrote:
> Look at the pressure to get stuff into 2.4 when it's already in 2.5.  Because 
> 2.4 is what people are actually using, and 2.5 is really just for os 
> development and testing (and general playing with) at this point.

If stuff in 2.5 wasn't soo broken (looking at IDE here) then more people
would be using it, and less people would be wanting the 2.5 features back
ported to 2.4.  IMHO, at the moment 2.5 has a major problem.  It is not
getting the testing it deserves because things like IDE and such like
aren't reasonably stable enough.

Some developers in the ARM community have been to use 2.4 because 2.5
IDE has been broken for soo long.  Having initially based their
development on 2.5, then being forced to switch to 2.4, they're not
going to switch back to 2.5 unless there's a _really_ good reason to.
Fixing IDE isn't "a really good reason" as far as they are concerned.

If we're going to make the 2.5 freeze in October and IDE remains as
unstable as it has since 2.5.4-ish, the months^wyears after that are
going to be a rough ride, and it will take a long time to shake the
bugs out.

At OLS, I was suggesting to people that 2.6 might happen in the summer of
2003.  I'm seriously considering moving that estimate to Christmas 2003
or first couple of months of 2004 now.

Feel free to prove me wrong in one and a half years time. 8)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [OKS] Kernel release management

[Theodore Ts'o]

On Thu, Jul 04, 2002 at 01:16:54PM +0100, Russell King wrote:
> On Tue, Jul 02, 2002 at 09:19:41PM -0400, Rob Landley wrote:
> > Look at the pressure to get stuff into 2.4 when it's already in 2.5.  Because 
> > 2.4 is what people are actually using, and 2.5 is really just for os 
> > development and testing (and general playing with) at this point.
> 
> If stuff in 2.5 wasn't soo broken (looking at IDE here) then more people
> would be using it, and less people would be wanting the 2.5 features back
> ported to 2.4.  IMHO, at the moment 2.5 has a major problem.  It is not
> getting the testing it deserves because things like IDE and such like
> aren't reasonably stable enough.

And the obvious answer to this is a backport of the 2.4 IDE subsystem
to 2.5.....  CONFIG_IDE_WONT_FIND_NEW_E2FSCK_BUGS, anyone?  :-)

						- Ted

Re: [OKS] Kernel release management

[Bernd Eckenfels]

In article <20020706124534.GA476@think.thunk.org> you wrote:
> And the obvious answer to this is a backport of the 2.4 IDE subsystem
> to 2.5.....  CONFIG_IDE_WONT_FIND_NEW_E2FSCK_BUGS, anyone?  :-)

Isnt that a forward port? :)

Greetings
Bernd

Re: [OKS] Kernel release management

[Russell King]

On Tue, Jul 02, 2002 at 11:13:01AM -0400, Bill Davidsen wrote:
> Seems the reason this is being suggested is that lots of new stuff got
> shoved into 2.2 and 2.4 in the early stages, and they were NOT stable.

That is where davej, the "help Linus say NO!" guy comes into play.

I'm maintaining the 2.5 and 2.4 ARM trees here in parallel, and it is
*really* tough to handle.  There are several problems:

1. finding the time to build and test each kernel version on hardware
   reasonably well.

2. keeping track of what has been applied to which kernels

3. getting down-stream developers to produce patches for the stable and
   development kernels generally doesn't happen.

The net effect is I have more support for various ARM machines in 2.4 at
present than in 2.5, but 2.5 only contains my new features.

If 2.6 and 2.7 appear at the same time, you _will_ run into the same
problems across the community.  Unless people are willing to put lots
of work in to making patches apply to two widely different kernel
source trees, you could end up in the same situation.  And it's no
fun to be there.

> The maintainer can alway push really new stuff into 2.7, and Linus can
> always refuse to take a feature into 2.7 until something else is fixed in
> 2.6.

And you expect Linus to track every single feature and fix that exists in
2.6 and 2.7?

If 2.6 and 2.7 come out at the same time, I'll have to ignore one or either
of the source trees completely.  As an architecture maintainer, that would
be *bad*.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [OKS] Kernel release management

[Bill Davidsen]

On Thu, 4 Jul 2002, Russell King wrote:

> > The maintainer can alway push really new stuff into 2.7, and Linus can
> > always refuse to take a feature into 2.7 until something else is fixed in
> > 2.6.
> 
> And you expect Linus to track every single feature and fix that exists in
> 2.6 and 2.7?

The maintainer should have a handle on the serious problems in 2.6, and
should be able to tell Linus who needs to look at a problem before moving
on. Not having a development kernel didn't work well for 2.2, it didn't
work well in 2.4, and now some people say "we've always done it that way"
while others say "we'll do it better this time." It's my feeling that
trying something else would be a good thing, if 2.6 doesn't get attention
2.7 could always be frozen after it exists, and you would still avoid
having totally new featues shoved in 2.6.
 
> If 2.6 and 2.7 come out at the same time, I'll have to ignore one or either
> of the source trees completely.  As an architecture maintainer, that would
> be *bad*.

If 2.6 is so buggy that it takes your full time to fix, it should still be
2.5. And it should take your full time. And that wouldn't be one bit
different than if 2.7 wasn't out, would it? 

If I understand what you do, it is limited to things related to your
architecture, and not general bugs like IDE eats the filesystems, stuff
won't compile as modules, smp locks up under high network multicast load,
etc. Unless changes in 2.6 break your area, which will be MUCH less likely
if new features are going in 2.7, I really wouldn't expect it to take all
your time.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [OKS] Kernel release management

[Russell King]

On Thu, Jul 04, 2002 at 09:33:19AM -0400, Bill Davidsen wrote:
> On Thu, 4 Jul 2002, Russell King wrote:
> > And you expect Linus to track every single feature and fix that exists in
> > 2.6 and 2.7?
> 
> The maintainer should have a handle on the serious problems in 2.6, and
> should be able to tell Linus who needs to look at a problem before moving
> on.

"tell Linus who needs to look at a problem" is an interesting concept.
I think many people here will know you can't do that with Linus.  Linus
makes his own decisions about what is important to x86 and no more.

> Not having a development kernel didn't work well for 2.2, it didn't
> work well in 2.4, and now some people say "we've always done it that way"
> while others say "we'll do it better this time."

There are two problems here:

1. Some maintainers won't have time to follow two trees.
2. Other maintainers continue to develop against stable trees and try to
   push their new features into stable trees.

> It's my feeling that trying something else would be a good thing, if 2.6
> doesn't get attention 2.7 could always be frozen after it exists, and
> you would still avoid having totally new featues shoved in 2.6.

Then 2.6 gets more stuff fixed and 2.7 bitrots.  It doesn't make the
problem go away.

> If 2.6 is so buggy that it takes your full time to fix, it should still
> be 2.5.

*I* can't make those decisions; they're out of my control.

> And it should take your full time. And that wouldn't be one bit
> different than if 2.7 wasn't out, would it?

The problem here is that 2.7 kicks off.  Changes are made that impact
the architecture specific code that need fixing up.  Lots of changes
happen.  These may be generic changes impacting the architecture specific
interfaces, or they may be changes that require architecture drivers to
be fixed.  Either way they need work, and there are a hell of a lot of
them over time.  This time around, I'm tracking 2.5 closely because I
don't want to spend massive amounts of time trying to fit ARM stuff into
an interface that it doesn't fit well.  I'd rather work *with* people
during design stages and sort the problems out as they come up.

Now think about what one person has to do when there's a stable tree and
a development tree...  Not only do they have to do all the above, but
they also have to handle the pressure of their respective communities
to merge developmental patches/large changes into the stable kernel.
They have to track bugs, and get stuff fixed.  Yada yada yada.

I'm completely happy the way 2.4/2.5 happened.  It worked well for me.
However, at present I'm completely ignoring the 2.4.19pre and rc stuff
at the moment because _I_ don't have time to follow it; all my recent
2.4 patches are against 2.4.18.  I hardly ever push 2.4 ARM stuff to
Marcelo.  And I don't see this changing.  So the 2.4 ARM stuff in
Marcelo's tree is set for a life of bitrot.

Ok, so 2.4 is rather stable.  Now think about the situation where 2.4
and 2.5 happen simultaneously.  I'll probably end up ignoring the stable
kernel series completely.

> If I understand what you do, it is limited to things related to your
> architecture, and not general bugs like IDE eats the filesystems, stuff
> won't compile as modules, smp locks up under high network multicast load,
> etc. Unless changes in 2.6 break your area, which will be MUCH less likely
> if new features are going in 2.7, I really wouldn't expect it to take all
> your time.

I end up doing *everyhing* (and people wonder why I sometimes get pissed
off when things change...)  An architecture maintainer isn't limited to
just the architecture specific code.  They normally get to play with
drivers and the internals of many of the kernels subsystems.  Eg, I tend
to touch at least the following areas:

1. IDE drivers.
2. SCSI drivers.
3. Network drivers.
4. Serial drivers.
5. Framebuffer drivers.
6. Filesystems.
7. MM subsystem cache and TLB stuff.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [OKS] Kernel release management

[Dave Jones]

On Mon, Jul 01, 2002 at 02:25:16PM -0400, Bill Davidsen wrote:
 > I suggested that 2.5 be opened when 2.4 came out, so I like the idea of
 > 2.7 starting when 2.6 is released. I think developers will maintain the
 > 2.6 work out of pride and desire to have a platform for the "next big
 > thing." And their code can always be placed on hold for 2.7 until they
 > clarify their thinking on 2.6, if that's really needed.

Unfortunatly, there's the possibility of people thinking
"I'll fix it properly in 2.7, and backport", during which time,
2.6 doesn't get fixed any faster.  People diving into 2.7 development
and leaving 2.6 to those that actually care about stabilising it was
Linus' concern if I understood correctly at the summit.

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [OKS] Kernel release management

[Rob Landley]

On Wednesday 03 July 2002 11:34 am, Dave Jones wrote:
> On Mon, Jul 01, 2002 at 02:25:16PM -0400, Bill Davidsen wrote:
>  > I suggested that 2.5 be opened when 2.4 came out, so I like the idea of
>  > 2.7 starting when 2.6 is released. I think developers will maintain the
>  > 2.6 work out of pride and desire to have a platform for the "next big
>  > thing." And their code can always be placed on hold for 2.7 until they
>  > clarify their thinking on 2.6, if that's really needed.
>
> Unfortunatly, there's the possibility of people thinking
> "I'll fix it properly in 2.7, and backport", during which time,
> 2.6 doesn't get fixed any faster.  People diving into 2.7 development
> and leaving 2.6 to those that actually care about stabilising it was
> Linus' concern if I understood correctly at the summit.

And leaving stabilization to the people who care about stabilization would be 
a bad thing why?  2.4's first ten releases are a marvelous counter-example to 
the "stonewall new development to speed up bugfixing" theory of software 
development.  The musical rotating feature freeze/thaw/slush/slurpee halfway 
through development cycles haven't been that effective either.

Linus ain't so good at maintenance, and he has said as much on this list.  
Linus's kernel sets the direction for Linux evolution, but he couldn't get 
the 2.4.0 VM stabilized and Alan Cox did.  (Better than mainline, anyway.)  
If Linus had handed over the stable series to Alan right after 2.4.1, taken a 
month long vacation, and then opened a new branch that was a bit selective at 
first about what it took and from who, does anybody think 2.4 would have 
taken any longer to properly stabilize than it wound up doing?  (Did Jens's 
bio patches really need to wait on the VM stabilization work?  Did Jens help 
stabilize the 2.4 VM?)

We live in a world of multiple Linux kernel trees already, each with a 
different maintainer who is good at different things.  Linus is a brilliant 
architect who is great at plucking the best ideas from the cream layer of the 
churning mass of Sturgeon's Law flung at him on a daily basis.  When 
presented with four ways to do something, he'll spot the hidden fifth better 
way like nobody else can.  But saying no in such a way as to promote 
stability is a different skill, and last time Linus went into big time 
"saying no" mode he wound up dropping VM stabilization patches from the then 
VM maintainer.  And the feature freezes haven't historically been remarkably 
effective at producing a stable kernel soon after either.

A "stabilization fork" off of the development series could be done, as an 
experiment, during the next "feature slush".  A maintainer who specializes in 
stabilizing code (You, Alan, and Marcelo are all doing a decent job at this 
now: it's not a common skill but not as rare as being a brilliant architect 
like Linus) can fork a "fixes only" tree that may or may not become 2.6, and 
see how it goes.

It it works, great, if it doesn't work, fine.  You already maintain a fork 
off of Linus's tree, and Alan maintains one off of Marcelo's tree.  Red Hat 
and SuSE maintain their own forks as well.  The existence of such a fork, 
with a compentent maintainer and its own user base, is not inherently 
disruptive to the rest of the world.  Feeding patches from one tree into 
another and dropping the rest until they're merged is what you and Alan do 
normally anyway, so the down side of it NOT working (giving up after a few 
months and going "shucks, people just won't listen to anyone but Linus") 
isn't exactly catastrophic.  As long as the maintainer is competent at 
merging to clean up the fork afterwards, and if they're not they can't 
effectively maintain their own tree in the first place anyway.

An explicit stabilization-only fork could even be a tool to help Linus's fork 
stabilize (if that is or becomes the goal), by tracking down bugs and 
performance tuning in a less turbulent environment while trying hard to 
introduce as few new problems as possible, and that being the ONLY goal of 
the fork.  Lots of bugs have been tracked down in -dj or -ac and the fix then 
ported to the appropriate mainline later.

If the stabilization fork DOES become 2.6, then 2.6 can START with a new 
maintainer, like Marcelo for 2.4 and Alan for 2.2.  Stable branch maintainers 
aren't normally expected to make major new architectural decisions anyway, 
that's what development kernels are for. :)

And if nothing else, it reduces the likelihood of development being stuck in 
a nebulous "no new features, well, okay, one more but that's it" mode for 
most of a year.

Yes, in theory 2.5 should BECOME a stabilization fork, under Linus, during 
the feature freeze.  It might even happen this time.  But how would hedging 
the bet hurt?

>         Dave

Rob

Re: [OKS] Kernel release management

[jw schultz]

On Wed, Jul 03, 2002 at 10:24:20AM -0400, Rob Landley wrote:
> On Wednesday 03 July 2002 11:34 am, Dave Jones wrote:
> > On Mon, Jul 01, 2002 at 02:25:16PM -0400, Bill Davidsen wrote:
> >  > I suggested that 2.5 be opened when 2.4 came out, so I like the idea of
> >  > 2.7 starting when 2.6 is released. I think developers will maintain the
> >  > 2.6 work out of pride and desire to have a platform for the "next big
> >  > thing." And their code can always be placed on hold for 2.7 until they
> >  > clarify their thinking on 2.6, if that's really needed.
> >
> > Unfortunately, there's the possibility of people thinking
> > "I'll fix it properly in 2.7, and backport", during which time,
> > 2.6 doesn't get fixed any faster.  People diving into 2.7 development
> > and leaving 2.6 to those that actually care about stabilising it was
> > Linus' concern if I understood correctly at the summit.
> 
> And leaving stabilization to the people who care about stabilization would be 
> a bad thing why?  2.4's first ten releases are a marvelous counter-example to 
> the "stonewall new development to speed up bugfixing" theory of software 
> development.  The musical rotating feature freeze/thaw/slush/slurpee halfway 
> through development cycles haven't been that effective either.
> 
> Linus ain't so good at maintenance, and he has said as much on this list.  
> Linus's kernel sets the direction for Linux evolution, but he couldn't get 
> the 2.4.0 VM stabilized and Alan Cox did.  (Better than mainline, anyway.)  
> If Linus had handed over the stable series to Alan right after 2.4.1, taken a 
> month long vacation, and then opened a new branch that was a bit selective at 
> first about what it took and from who, does anybody think 2.4 would have 
> taken any longer to properly stabilize than it wound up doing?  (Did Jens's 
> bio patches really need to wait on the VM stabilization work?  Did Jens help 
> stabilize the 2.4 VM?)
> 
> We live in a world of multiple Linux kernel trees already, each with a 
> different maintainer who is good at different things.  Linus is a brilliant 
> architect who is great at plucking the best ideas from the cream layer of the 
> churning mass of Sturgeon's Law flung at him on a daily basis.  When 
> presented with four ways to do something, he'll spot the hidden fifth better 
> way like nobody else can.  But saying no in such a way as to promote 
> stability is a different skill, and last time Linus went into big time 
> "saying no" mode he wound up dropping VM stabilization patches from the then 
> VM maintainer.  And the feature freezes haven't historically been remarkably 
> effective at producing a stable kernel soon after either.
> 
> A "stabilization fork" off of the development series could be done, as an 
> experiment, during the next "feature slush".  A maintainer who specializes in 
> stabilizing code (You, Alan, and Marcelo are all doing a decent job at this 
> now: it's not a common skill but not as rare as being a brilliant architect 
> like Linus) can fork a "fixes only" tree that may or may not become 2.6, and 
> see how it goes.
> 
> It it works, great, if it doesn't work, fine.  You already maintain a fork 
> off of Linus's tree, and Alan maintains one off of Marcelo's tree.  Red Hat 
> and SuSE maintain their own forks as well.  The existence of such a fork, 
> with a compentent maintainer and its own user base, is not inherently 
> disruptive to the rest of the world.  Feeding patches from one tree into 
> another and dropping the rest until they're merged is what you and Alan do 
> normally anyway, so the down side of it NOT working (giving up after a few 
> months and going "shucks, people just won't listen to anyone but Linus") 
> isn't exactly catastrophic.  As long as the maintainer is competent at 
> merging to clean up the fork afterwards, and if they're not they can't 
> effectively maintain their own tree in the first place anyway.
> 
> An explicit stabilization-only fork could even be a tool to help Linus's fork 
> stabilize (if that is or becomes the goal), by tracking down bugs and 
> performance tuning in a less turbulent environment while trying hard to 
> introduce as few new problems as possible, and that being the ONLY goal of 
> the fork.  Lots of bugs have been tracked down in -dj or -ac and the fix then 
> ported to the appropriate mainline later.
> 
> If the stabilization fork DOES become 2.6, then 2.6 can START with a new 
> maintainer, like Marcelo for 2.4 and Alan for 2.2.  Stable branch maintainers 
> aren't normally expected to make major new architectural decisions anyway, 
> that's what development kernels are for. :)
> 
> And if nothing else, it reduces the likelihood of development being stuck in 
> a nebulous "no new features, well, okay, one more but that's it" mode for 
> most of a year.
> 
> Yes, in theory 2.5 should BECOME a stabilization fork, under Linus, during 
> the feature freeze.  It might even happen this time.  But how would hedging 
> the bet hurt?
> 

Sorry to leave all the above in but it seems all context.

Speaking for the moment as an observer.  It seems that our
two phase process isn't quite satisfactory.   Linus is great
at managing the forward development but dislikes and stinks at
stabilisation and maintenance.  A fair number of people can
handle maintenance.  What it seems we need is an
intermediate person to handle stabilisation.

I see stabilising as requiring its own set of abilities and
credentials and as being very strenuous.  Whoever acts as a
Stabiliser should only have to do so for less than a year.

What i would suggest is that Linus keep 2.5 until he feels
it is feature complete and ready to be stabilised.  At that
point he seeks someone like AC or DJ to accept the torch and
negotiates a hand-off to the official Stabiliser.

Then Linus can take a vacation, visit his children or play
around with the new-feature patches or some idea of his own
while providing some support to the Stabiliser.  At some
point the Stabiliser will declare 2.6 and Linus can fork
2.7.  A bit later the Stabiliser can hand-off to a
Maintainer and take a break himself.

.From that point onward the Maintainer will deal with
bugfixes and back-ported device support as Marcello is now.



-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: [OKS] Kernel release management

[Russell King]

On Wed, Jul 03, 2002 at 10:24:20AM -0400, Rob Landley wrote:
> And leaving stabilization to the people who care about stabilization
> would be a bad thing why?

Think about who will do the stabilisation.  Do you really think Alan or
Marcelo will pick up 2.6 when it comes out?  Or do you see someone else
picking up 2.6?

One of the fundamental questions that needs to be asked along side the
"fork 2.7 with 2.6" problem is _who_ exactly is going to look after 2.6.
Dave Jones?  If Dave, who's going to do Daves job of making sure fixes
get propagated between stable and development trees?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [OKS] Kernel release management

[Dave Jones]

On Thu, Jul 04, 2002 at 01:21:20PM +0100, Russell King wrote:

 > Think about who will do the stabilisation.  Do you really think Alan or
 > Marcelo will pick up 2.6 when it comes out?  Or do you see someone else
 > picking up 2.6?

Marcelo didn't seem against the idea, and as he's done a pretty good
job so far in 2.4, he seems to be the ideal guy for the job (time
permitting). At the time we get to 2.6.0, 2.4 should have slowed down
sufficiently that he'll be looking for something else to do.

 > One of the fundamental questions that needs to be asked along side the
 > "fork 2.7 with 2.6" problem is _who_ exactly is going to look after 2.6.
 > Dave Jones?  If Dave, who's going to do Daves job of making sure fixes
 > get propagated between stable and development trees?

When we get to 2.6, I'll do 2.6-dj's until the important bits are all
pushed to $maintainer, and keep the leftovers until 2.7-dj.

        Dave 

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [OKS] Kernel release management

[Bill Davidsen]

On Wed, 3 Jul 2002, Dave Jones wrote:

> Unfortunatly, there's the possibility of people thinking
> "I'll fix it properly in 2.7, and backport", during which time,
> 2.6 doesn't get fixed any faster.  People diving into 2.7 development
> and leaving 2.6 to those that actually care about stabilising it was
> Linus' concern if I understood correctly at the summit.

Dave, it's not that I can't see your point, but looking at the way stuff
is being backported to 2.4, and 2.2, and even 2.0 as an example, and how
many new features went into early 2.2 and 2.4 which really should have
been functional before they went in, we have a long track record of
maintainers doing the backports and problems from not having a test series
to use for new features.

I don't see the case you mentioned of fix it in 2.7 and backport as
necessarily a bad idea. You can make progress faster when people aren't
afraid to try stuff, and can itterate until the feature works or the
problem is fixed, then backport understanding the problem.

I don't regard easing features back into the stable release after they are
shaken down as a bad thing, either. A development kernel may not even
compile (biy does 2.5 prove that), a stable series should mean the old
features don't break and the new ones are tested, and it does run a lot
slower than the development series.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [OKS] Kernel release management

[Andi Kleen]

Russell King <rmk@arm.linux.org.uk> writes:


> If stuff in 2.5 wasn't soo broken (looking at IDE here) then more people
> would be using it, and less people would be wanting the 2.5 features back
> ported to 2.4.  IMHO, at the moment 2.5 has a major problem.  It is not
> getting the testing it deserves because things like IDE and such like
> aren't reasonably stable enough.

I have to second RMK's complaint. Testing 2.5 (in this case with x86-64)
is a major problem unless you're lucky enough to find a SCSI adapter 
and a SCSI disk. IDE just deadlocks and hangs too often. This prevents
testing everything else and stops development in 2.5 for many things.
I don't think the 2.5 release cycle can afford to lose the testers who
only have IDE machines.

-Andi