Suggestion About Kernel Releases

Suggestion About Kernel Releases

[Tarkan Erimer]

Hi,

After long discussions about kernel release methodology, an idea has 
came to ( Any comments welcomed :-) ) my mind :

-  2 weeks of merge window for each "rc" releases should remain the same .
- When decided the 2.6.xx-rcx is ready to become 2.6.xx, it should be 
2.6.xx-test1 instead of 2.6.xx
- Chris Wright (or whoever will handle these "testX" maintaining) can 
maintain these "testX" releases as like 2.6.x.y maintaining.
- After releasing the "testX" releases, the new kernel release process 
should start.
- When Chris decided it is stable enough, it should release as 2.6.xx 
(stable).
- Of course, 2.6.x.y releases follows then as usually.

Please share your opinions. Thanks :-)

Tarkan

Re: Suggestion About Kernel Releases

[Arjan van de Ven]

On Wed, 21 May 2008 16:08:37 +0300
Tarkan Erimer <tarkan@netone.net.tr> wrote:

> Hi,
> 
> After long discussions about kernel release methodology, an idea has 
> came to ( Any comments welcomed :-) ) my mind :
> 

what would you want to accomplish with your idea?

Re: Suggestion About Kernel Releases

[Pekka Enberg]

On Wed, 21 May 2008 16:08:37 +0300, Tarkan Erimer <tarkan@netone.net.tr> wrote:
>> After long discussions about kernel release methodology, an idea has
>> came to ( Any comments welcomed :-) ) my mind :

On Wed, May 21, 2008 at 4:38 PM, Arjan van de Ven <arjan@infradead.org> wrote:
> what would you want to accomplish with your idea?

And how is it different from what we do now, modulo the -test1 postfix
to the name?

Re: Suggestion About Kernel Releases

[Tarkan Erimer]

Arjan van de Ven wrote:
> what would you want to accomplish with your idea?
>   

To make kernel releases more stable/tested via "testX" series, as 
recently discussed by David Miller's "Slow DOWN, please!!!" thread. 
These "testX" releases will give more opportunity and time to test more 
these new releases. Also, with the aim of the "testX" series, the new 
kernel release schedules/merge windows will be not slow down. Even, 
Linus can releases new kernels more quickly. Because, testing purpose 
should be handled by someone else like Chris did for 2.6.x.y.

Re: Suggestion About Kernel Releases

[Tarkan Erimer]

Pekka Enberg wrote:
> On Wed, 21 May 2008 16:08:37 +0300, Tarkan Erimer <tarkan@netone.net.tr> wrote:
>   
>>> After long discussions about kernel release methodology, an idea has
>>> came to ( Any comments welcomed :-) ) my mind :
>>>       
>
> On Wed, May 21, 2008 at 4:38 PM, Arjan van de Ven <arjan@infradead.org> wrote:
>   
>> what would you want to accomplish with your idea?
>>     
>
> And how is it different from what we do now, modulo the -test1 postfix
> to the name?
>   

Please see my reply to Arjan's post.

Re: Suggestion About Kernel Releases

[Arjan van de Ven]

On Wed, 21 May 2008 16:59:56 +0300
Tarkan Erimer <tarkan@netone.net.tr> wrote:

> Arjan van de Ven wrote:
> > what would you want to accomplish with your idea?
> >   
> 
> To make kernel releases more stable/tested via "testX" series, as 
> recently discussed by David Miller's "Slow DOWN, please!!!" thread. 
> These "testX" releases will give more opportunity and time to test
> more these new releases. Also, with the aim of the "testX" series,
> the new kernel release schedules/merge windows will be not slow down.
> Even, Linus can releases new kernels more quickly. Because, testing
> purpose should be handled by someone else like Chris did for 2.6.x.y.

sorry but you're wrong ;(
calling something -test won't change anything. It just means it'll get
tested less, not more.


Also the "Slow DOWN please" had NOTHING to do with releases, but only
with what happens during the actual merge window.

Re: Suggestion About Kernel Releases

[Mike Snitzer]

On Wed, May 21, 2008 at 10:00 AM, Tarkan Erimer <tarkan@netone.net.tr> wrote:
> Pekka Enberg wrote:
>
> > On Wed, 21 May 2008 16:08:37 +0300, Tarkan Erimer <tarkan@netone.net.tr>
> wrote:
> >
> >
> > >
> > > > After long discussions about kernel release methodology, an idea has
> > > > came to ( Any comments welcomed :-) ) my mind :
> > > >
> > > >
> > >
> >
> > On Wed, May 21, 2008 at 4:38 PM, Arjan van de Ven <arjan@infradead.org>
> wrote:
> >
> >
> > > what would you want to accomplish with your idea?
> > >
> > >
> >
> > And how is it different from what we do now, modulo the -test1 postfix
> > to the name?
> >
> >
>
>  Please see my reply to Arjan's post.

I think you're missing Arjan and Pekka's point: your proposal doesn't
_really_ offer any change to the current procedure.  It might make you
feel more warm and fuzzy but in practice:
1) Linus would still release a kernel (be it to -testX or "final")
when he and others feel it is time
2) The stable team will track fixes and release stable kernels as needed

The only thing that is different in your approach is the "final"
release would theoretically be more well tested.  Unfortunately that
is not a valid assumption because the wider Linux audience likely
won't embrace the latest kernel until it is "final" anyway.  This
delayed uptake can/will result in early stable fixes.

Again, no real change... we know that the "final" release that Linus
makes _could_ have some minor oversight that will be fixed fairly
quickly by the stable team.

Mike

Re: Suggestion About Kernel Releases

[Oliver Pinter]

On 5/21/08, Tarkan Erimer <tarkan@netone.net.tr> wrote:
> Hi,
>
> After long discussions about kernel release methodology, an idea has
> came to ( Any comments welcomed :-) ) my mind :
>
> -  2 weeks of merge window for each "rc" releases should remain the same .
> - When decided the 2.6.xx-rcx is ready to become 2.6.xx, it should be
> 2.6.xx-test1 instead of 2.6.xx
> - Chris Wright (or whoever will handle these "testX" maintaining) can
> maintain these "testX" releases as like 2.6.x.y maintaining.
> - After releasing the "testX" releases, the new kernel release process
> should start.
> - When Chris decided it is stable enough, it should release as 2.6.xx
> (stable).
> - Of course, 2.6.x.y releases follows then as usually.
>
> Please share your opinions. Thanks :-)
>
> Tarkan
> --
> 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/
>

now:
linux-2.6.x -> linux-2.6.(x+1)-rcY -> linux-2.6.(x+1)
         \->2.6.x.y
       \->2.6.(x+1).y
                  \->2.6.x.(y+1)-rc1->2.6.x.(.y+1)
           \->2.6.x.(y+1)-rc1->2.6.x.(.y+1)

your idea:
linux-2.6.x -> linux-2.6.(x+1)-rcY -> linux-2.6.(x+1)
         \->2.6.x.y
       \->2.6.(x+1).y
                  \->2.6.x.(y+1)-test1->2.6.x.(.y+1)
             \->2.6.x.(y+1)-test1->2.6.(x+1).(.y+1)

only the namig is was other, rc -> test,

-- 
Thanks,
Oliver

Re: Suggestion About Kernel Releases

[Tarkan Erimer]

Arjan van de Ven wrote:
> sorry but you're wrong ;(
> calling something -test won't change anything. It just means it'll get
> tested less, not more.
>
>   
It's just a suggestion. Of course, I may be wrong ;-)
Why do you think that calling something test means that less testing ?

> Also the "Slow DOWN please" had NOTHING to do with releases, but only
> with what happens during the actual merge window.
>   
Yes, I know. That's what I'm talking about :-)

Re: Suggestion About Kernel Releases

[Arjan van de Ven]

On Wed, 21 May 2008 17:50:00 +0300
Tarkan Erimer <tarkan@netone.net.tr> wrote:

> Arjan van de Ven wrote:
> > sorry but you're wrong ;(
> > calling something -test won't change anything. It just means it'll
> > get tested less, not more.
> >
> >   
> It's just a suggestion. Of course, I may be wrong ;-)
> Why do you think that calling something test means that less testing ?

because fewer people will use it compared to a final release.

> 
> > Also the "Slow DOWN please" had NOTHING to do with releases, but
> > only with what happens during the actual merge window.
> >   
> Yes, I know. That's what I'm talking about :-)

no you're not. You're talking about the tail of a cycle, while the Slow
Down thing was ONLY about the first 2 weeks merge window.

Since this discussion has all the signs of a derailing thread.. I would
strongly suggest we end it here. Not trying to just cut you off, but
this has been discussed a lot, and your posts aren't adding something
new to that.

Re: Suggestion About Kernel Releases

[Tarkan Erimer]

Mike Snitzer wrote:
> I think you're missing Arjan and Pekka's point: your proposal doesn't
> _really_ offer any change to the current procedure.  It might make you
> feel more warm and fuzzy but in practice:
> 1) Linus would still release a kernel (be it to -testX or "final")
> when he and others feel it is time
> 2) The stable team will track fixes and release stable kernels as needed
>
> The only thing that is different in your approach is the "final"
>   
Yes, that's what I'm talking about. The change will be the "testX" 
thing. And as you already stated it will help more stable releases.
> release would theoretically be more well tested.  Unfortunately that
> is not a valid assumption because the wider Linux audience likely
> won't embrace the latest kernel until it is "final" anyway.  This
> delayed uptake can/will result in early stable fixes.
>
>   
Of course as didn't embrace like the "rc" releases. I don't think that 
it will cause early stable fixes. Contrarily, it will produce more 
tested/stable releases. You may think it as a kind of "rc" series.


> Again, no real change... we know that the "final" release that Linus
> makes _could_ have some minor oversight that will be fixed fairly
> quickly by the stable team.
>
> Mike
>   
It is. As I described above : the "testX" series will change the things 
as producing more tested /stable releases. BTW, it should be much better 
to release less, trouble free kernels instead of releasing fast but 
fixing soon. Also, it will take the load of deep kernel testing. Linus 
should only do the applying the patches for the next kernel release via 
"rc" releases. Then when Linus decided all the patches, for the next 
kernel, applied he will pass it to the "testX" series maintainer as 
Chris did for 2.6.x.y.

Re: Suggestion About Kernel Releases

[Pekka Enberg]

On Wed, May 21, 2008 at 6:15 PM, Tarkan Erimer <tarkan@netone.net.tr> wrote:
> It is. As I described above : the "testX" series will change the things as
> producing more tested /stable releases. BTW, it should be much better to
> release less, trouble free kernels instead of releasing fast but fixing
> soon.

You keep saying that but it simply is not true. The more people we
have _waiting_ for a "stable" kernel to graduate from the "testing"
series, the less people we have actually _testing_ the kernel.

So it's probable that your suggestion actually makes the current
situation worse, not better.

Re: Suggestion About Kernel Releases

[Chris Wright]

* Tarkan Erimer (tarkan@netone.net.tr) wrote:
> To make kernel releases more stable/tested via "testX" series, as recently 
> discussed by David Miller's "Slow DOWN, please!!!" thread.

Arjan already pointed out that this was about the merge window, not the
tail.

> These "testX" 
> releases will give more opportunity and time to test more these new 
> releases. Also, with the aim of the "testX" series, the new kernel release 
> schedules/merge windows will be not slow down. Even, Linus can releases new 
> kernels more quickly. Because, testing purpose should be handled by someone 
> else like Chris did for 2.6.x.y.

(BTW, Greg does 2.6.x.y as well).  What you are missing is that it is not
Greg and I who are doing the bulk of testing for 2.6.x.y.  It's the entire
community, and adding additional stage to the tail or the release cycle
will not increase testing coverage.  History shows it'll just postpone it.

thanks,
-chris

Re: Suggestion About Kernel Releases

[Rik van Riel]

On Wed, 21 May 2008 16:59:56 +0300
Tarkan Erimer <tarkan@netone.net.tr> wrote:

> Even, Linus can releases new kernels more quickly. Because, testing
> purpose should be handled by someone else like Chris did for 2.6.x.y.

If Linus were to go straight from merge window to merge window,
with stabilization happening in parallel, then there would be
no stable basis at the start of each merge window and bugs can
just pile up.

Speeding things up could lead to the same kind of code quality
issues we used to have in the 1.3, 2.1, 2.3 and 2.5 kernel series.

Slowing down regularly is good, not bad.

-- 
All rights reversed.

Re: Suggestion About Kernel Releases

[Tarkan Erimer]

Chris Wright wrote:
> (BTW, Greg does 2.6.x.y as well).  What you are missing is that it is not
> Greg and I who are doing the bulk of testing for 2.6.x.y.  It's the entire
> community, and adding additional stage to the tail or the release cycle
> will not increase testing coverage.  History shows it'll just postpone it.
>
>   
Yep,sorry for forgetting Greg ;-) I meant testing maintenance(applying 
bug fixes etc.), of course not testing by yourself.

Tarkan

Re: Suggestion About Kernel Releases

[Enrico Weigelt]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> You keep saying that but it simply is not true. The more people we
> have _waiting_ for a "stable" kernel to graduate from the "testing"
> series, the less people we have actually _testing_ the kernel.

ACK.

I, personally use the newest releases on mostly unimportant 
systems, where a kernel bug is ugly but not that bad.
For production systems I use the stableized/well-tested distro
kernels, eg. unmasked on Gentoo). If you're using such an distro,
you already have an more tested kernel, less chance of bugs
(than with vanilla).

My suggestion istead is bringing these individual efforts from 
distros to some central point, let's call this "mature kernel".
This (IMHO) wouldn't affect the current development/release 
process, mission-critical systems can simply use that mature 
tree, and perhaps some pressure is taken from vanilla.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------