Linux 3.7-rc7 Kernel Is "Slightly Scarier"

[phoronix]

Phoronix: Linux 3.7-rc7 Kernel Is "Slightly Scarier"

Linus Torvalds released the Linux 3.7-rc7 kernel on Sunday night and considers this new release candidate to be "slightly scarier" than the previous 3.7-rc6 release...

http://www.phoronix.com/vr.php?view=MTIzNTg

[schmidtbag]

I think there needs to be a new plan for kernel updates. RCs shouldn't be about how many submissions there are and how big they are but rather focused on designated purposes. So for example, RC1 could be reserved for just drivers. RC2 could focus on KMS tasks. RC3 could be security updates. RC4 could be bug fixes. RC5 could be hardware capabilities (such as ACPI or CPU instruction sets). RC6 could be things to either add or remove from the kernel. And RC7 could be miscellaneous changes.

With something like this, kernel updates can be more organized and while some RCs may be more tiresome than others, nothing states they MUST be within a specific timeframe. I'm sure there could be times when there might not be an RC3 or the RC1 could be 90% of the final kernel.

[GreatEmerald]

I think there needs to be a new plan for kernel updates. RCs shouldn't be about how many submissions there are and how big they are but rather focused on designated purposes. So for example, RC1 could be reserved for just drivers. RC2 could focus on KMS tasks. RC3 could be security updates. RC4 could be bug fixes. RC5 could be hardware capabilities (such as ACPI or CPU instruction sets). RC6 could be things to either add or remove from the kernel. And RC7 could be miscellaneous changes.

With something like this, kernel updates can be more organized and while some RCs may be more tiresome than others, nothing states they MUST be within a specific timeframe. I'm sure there could be times when there might not be an RC3 or the RC1 could be 90% of the final kernel.

I don't think that would work. RCs are for bug fixes, right? So people who submit their patches do so to improve stability and fix bugs, and usually they want their patches to get integrated as soon as possible (otherwise they would wait for the next kernel). If there were "themed RCs", and there was a critical issue found in, say, a filesystem, it would not be accepted until the next release or so, which is just silly.

[smitty3268]

I think there needs to be a new plan for kernel updates. RCs shouldn't be about how many submissions there are and how big they are but rather focused on designated purposes. So for example, RC1 could be reserved for just drivers. RC2 could focus on KMS tasks. RC3 could be security updates. RC4 could be bug fixes. RC5 could be hardware capabilities (such as ACPI or CPU instruction sets). RC6 could be things to either add or remove from the kernel. And RC7 could be miscellaneous changes.

With something like this, kernel updates can be more organized and while some RCs may be more tiresome than others, nothing states they MUST be within a specific timeframe. I'm sure there could be times when there might not be an RC3 or the RC1 could be 90% of the final kernel.

That's stupid. So, if RC4 is reserved for bug fixes, what happens when RC5 comes out and someone finds a bug? It doesn't ever get fixed until the next kernel, just because of an arbitrary rule that you can't fix bugs in RC6 or RC7? People would revolt.

[schmidtbag]

That's stupid. So, if RC4 is reserved for bug fixes, what happens when RC5 comes out and someone finds a bug? It doesn't ever get fixed until the next kernel, just because of an arbitrary rule that you can't fix bugs in RC6 or RC7? People would revolt.

how do you and great emerald not understand the point of my post? Linus dismisses submissions just because an RC is getting too big, so they often have to wait for the next kernel or sometimes the next release. And no, kernel updates aren't just about big fixes. Besides, what i said was an example. Perhaps general bug fixes (such as removing an error from booting or code optimizations) could be applied for every RC, but each RC should revolve around a specific purpose instead of some arbitrary limit on amount if changes. That way developers can work around a schedule. While the current system hasn't proven to fail, it is mostly just operated by 1 person and it doesn't mean it's the best. In other words, if a definite intention were put into each RC (even if it has nothing to do with my example) then Linus wouldn't have a reason to complain.

[smitty3268]

how do you and great emerald not understand the point of my post? Linus dismisses submissions just because an RC is getting too big, so they often have to wait for the next kernel or sometimes the next release. And no, kernel updates aren't just about big fixes. Besides, what i said was an example. Perhaps general bug fixes (such as removing an error from booting or code optimizations) could be applied for every RC, but each RC should revolve around a specific purpose instead of some arbitrary limit on amount if changes. That way developers can work around a schedule. While the current system hasn't proven to fail, it is mostly just operated by 1 person and it doesn't mean it's the best. In other words, if a definite intention were put into each RC (even if it has nothing to do with my example) then Linus wouldn't have a reason to complain.

There's already a definite intention on every RC. They are all supposed to be for bug fixes only. Features are only supposed to be added to RC1.

The fact that Linus sometimes lets people sneak in feature changes for the first couple of RCs doesn't change that. Although maybe he should just go ahead and ban them all until the next kernel rolls around.