Results 1 to 6 of 6

Thread: Linux 3.10-rc6 Kernel Brings In More Fixes

  1. #1
    Join Date
    Jan 2007
    Posts
    15,413

    Default Linux 3.10-rc6 Kernel Brings In More Fixes

    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

  2. #2
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,445

    Default

    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.

  3. #3
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,636

    Default

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

  4. #4
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,543

    Default

    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.

  5. #5
    Join Date
    Oct 2008
    Posts
    3,216

    Default

    Quote Originally Posted by schmidtbag View Post
    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.

  6. #6
    Join Date
    Sep 2011
    Posts
    707

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •