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