[arch-dev-public] [idea] Kernel Release Policy

[Jud]

Hi Devs,

Please do not take this a complaint, I am a fan of consistent
improvement and I hope after reading this you'll agree there is some
room for improvement and by working together it can be realised.

After the disaster of early the early upstream kernel 2.6.25 releases
(many annoying minor problems that shouldn't have happend and the quick
concession of updates) and the recent wake-up call of 2.6.27-RCs [1]
I felt compelled to write this, so Arch won't be doomed to let history
repeat. I think Arch should be smarter about the way it handles it's
kernel releases and I present an idea for discussion.

- The current [core] kernel 2.6.x release is always updated until
it really makes sense to update to the next .x version.

- The latest "stable" kernel is always available in [testing/unstable]
for the bleeding-edge crowd.

- This "policy" is announced to inform the user-base via Forum,
Website, Newsletter, Mailing-List so to avoid any confusion.

Optional:
- A criteria is created and met so the next kernel version can be
throughly tested and pushed for a seamless user upgrade.

- Multiple Kernel Maintainers is implemented and eventually all Arch
core developers could release a perfect kernel.


Let me explain what usually happens:
2.6.27.0 will come out, about the same time a 2.6.26.6 will be released
Arch will abandon .26.y and start testing .27.0. Somethings will break,
then get fixed, etc until everyone is happy and ready to release.
Meanwhile 26.y might be at .9 with many important fixes that cannot be
used. I know there is ABS but this is from a multiple computers systems
and the community as a whole point-of-view.

So my major point is: The only thing I want to really change is while
the newer .x kernel is been prepped for released, Arch does not abandon
the current .x kernel.

Benefits:
- Arch remains "stable" while still maintaining it's "bleeding edge"
aura 
- Lot less breakages and complaints
- Smoother workflow and more development/bug-squashing time for Devs

Thanks for your time, and I hope this discussion is taken in the right
way as it serves only to improve Arch and it's users computing
experience.


PS:- 

I already have had some positive feedback and as a result I present some
ideas on the co-existing kernels problem, open for disscussion.

a) The testing kernel package is named slightly different with the
'replaces/force' PKGBUILD magic. Once the testing kernel proves
stable/ready enough for a [core] release (usually about version 2.6.x.5)
rename and push out, this only really affects the testing people who
would easily have the skills to overcome any problems

b) Use another Repo, I know [unstable] was killed off but as dumb as
it sounds, perfect for this task.

c) The current kernel in [core] the .y updates get tested
"behind-the-scenes" and then move straight into [core], with the next .x
kernel in [testing]


[1] http://www.phoronix.com/scan.php?page=news_item&px=Njc0Nw