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

[ message continues ]

On Wed, 21 May 2008 16:08:37 +0300

what would you want to accomplish with your idea?
--

[ message continues ]

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

[ message continues ]

Please see my reply to Arjan's post.


--

[ message continues ]

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

[ message continues ]

Yes, that's what I'm talking about. The change will be the "testX" 
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 
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.



--

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]

On Wed, 21 May 2008 16:59:56 +0300

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

[ message continues ]

It's just a suggestion. Of course, I may be wrong ;-)
Yes, I know. That's what I'm talking about :-)
--

[ message continues ]

On Wed, 21 May 2008 17:50:00 +0300


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

[ message continues ]

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

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

[ message continues ]

Yep,sorry for forgetting Greg ;-) I meant testing maintenance(applying 
bug fixes etc.), of course not testing by yourself.

Tarkan
--

[ message continues ]

On Wed, 21 May 2008 16:59:56 +0300

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

[ message continues ]

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

[ message continues ]