[arch-dev-public] [idea] Kernel Release Policy
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
On Sun, Oct 5, 2008 at 6:09 PM, Jud <jud@judfilm.net> wrote:
Hi Devs,
<big snip> 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.
Whoa, could have said that at the start :p The complication is that kernels need to go through testing, and we can't test a 2.6.26.y while there's a 2.6.27 in [testing]. So we can either ignore our current rule for kernel to go through [testing] making an exception for .y releases - or we can leave the same as it is now. I'm inclined to leave things the same rather than make an exception. Many .y releases are pretty minor, or we have them merged already. James
On Sun, Oct 5, 2008 at 6:09 PM, Jud <jud@judfilm.net> wrote:
Hi Devs,
<big snip> 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.
Whoa, could have said that at the start :p
The complication is that kernels need to go through testing, and we can't test a 2.6.26.y while there's a 2.6.27 in [testing]. So we can either ignore our current rule for kernel to go through [testing] making an exception for .y releases - or we can leave the same as it is now.
I'm inclined to leave things the same rather than make an exception. Many .y releases are pretty minor, or we have them merged already.
James Hi normally the new .x kernel stays 2 or 3 weeks in testing before we move in. Also all modules need to compile before move in can be done. The perfect kernel was never released, all have issues the question is how many are affected and how much are they affected. A bug in sata/ide/scsi has the possibility to be a showstopper, also a bug in network or filesystems. If a speaker on someones soundcard isn't working right isn't a showstopper,
Am Montag 06 Oktober 2008 schrieb James Rayner: this happens with every kernel/alsa release. As James stated we cannot move in an older kernel to core without signoff. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
2008/10/6 James Rayner <iphitus@iphitus.org>:
On Sun, Oct 5, 2008 at 6:09 PM, Jud <jud@judfilm.net> wrote:
Hi Devs,
<big snip> 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.
Whoa, could have said that at the start :p
The complication is that kernels need to go through testing, and we can't test a 2.6.26.y while there's a 2.6.27 in [testing]. So we can either ignore our current rule for kernel to go through [testing] making an exception for .y releases - or we can leave the same as it is now.
I'm inclined to leave things the same rather than make an exception. Many .y releases are pretty minor, or we have them merged already.
I think the "proper" more general solution here is to have a 'stable' or 'rollback' repository for this kind of thing. This gets discussed way too often and so far, no devs have wanted to take on this task and no community contributions have been successful. In the meantime, I think the traditional Arch response (use ABS) is the correct one; the kernel is not a more special package than any other in the distro. It just happens to be one of the one that if it breaks nothing else works. Dusty
participants (4)
-
Dusty Phillips
-
James Rayner
-
Jud
-
Tobias Powalowski