Linux 3.10-rc6 Kernel Brings In More Fixes

[phoronix]

Phoronix: Linux 3.10-rc6 Kernel Brings In More Fixes

Linus Torvalds has released the Linux 3.10-rc6 kernel on Saturday afternoon. While there's still some time ahead before the official Linux 3.10 kernel release, the rate of change appears to be slowing...

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

[schmidtbag]

I'd still like to know exactly how Linus' RC procedure works, because it seems so arbitrary. Is it sorted by priority? For example, RC1 would be fixing critical errors and security flaws, RC2 would be performance and power issues, RC3 would be high-risk new features, and all the way down to RC7 which would be stuff like "changed text to say 'greetings world' rather than 'hello world'". To me, that's the most logical way of setting it up because the more important a change is, the longer it will be tested for reliability. Each RC could have a maximum amount of changes too, so RC1 can only have 10, RC2 can have 15, RC3 can have 30, and so on. That way, if Linus gets more than he can handle, he can prioritize what he wants and push back the others for another release.

[GreatEmerald]

I'm pretty sure the RC policy is simply "if you have bug fixes, they go in, if not, go away".

[bridgman]

The other issue is that it isn't really practical for Linus to cherry-pick what he wants, since the process depends so heavily on subsystem maintainers. It's probably fair to say that Linus provides loud and colourful feedback because feedback to the maintainers is the primary mechanism he has for controlling what goes into each new release.

[smitty3268]

I'd still like to know exactly how Linus' RC procedure works, because it seems so arbitrary. Is it sorted by priority? For example, RC1 would be fixing critical errors and security flaws, RC2 would be performance and power issues, RC3 would be high-risk new features, and all the way down to RC7 which would be stuff like "changed text to say 'greetings world' rather than 'hello world'". To me, that's the most logical way of setting it up because the more important a change is, the longer it will be tested for reliability. Each RC could have a maximum amount of changes too, so RC1 can only have 10, RC2 can have 15, RC3 can have 30, and so on. That way, if Linus gets more than he can handle, he can prioritize what he wants and push back the others for another release.

It's not that difficult to understand. It's "send me any changes you want to go in, but with each RC it had better be more in the bugfix variety and less new features".

Thus with RC2 it's not uncommon to see features that missed the original pull. By RC6 or 7, it's almost entirely bugfixes.

And it doesn't have anything to do with "how much Linus can handle". It's all about providing a stable release kernel that's been tested and doesn't have many bugs present. You don't get that by making major changes right before it's released.

[AJenbo]

Strings are normally frozen before bug fixes because of documentation and translation. Bug fixes go in late because they are fixes for issues that popup during RC testing. If a severe bug is discovered it can prolong the RC process until the bug is fixed and a period of time for testing has gone by.