Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: The Linux 2.6.35-rc3 Kernel Update Is Small

  1. #1
    Join Date
    Jan 2007
    Posts
    13,426

    Default The Linux 2.6.35-rc3 Kernel Update Is Small

    Phoronix: The Linux 2.6.35-rc3 Kernel Update Is Small

    Last week when releasing the Linux 2.6.35-rc2 kernel, Linus was upset with the number of late merges and other commits that were receiving pull requests in the Linux 2.6.35 kernel development cycle when the work should instead be now about bug and regression fixes. As such, Linus was going to be much more stringent about what he would allow within the Linux 2.6.35-rc3 kernel and he has indeed followed his tighter rules...

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

  2. #2
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,091

    Default

    Well, rc2 brought in the voltage power management for the opensource radeon stack and the rc3 has additional power management fixes. This is worth mentioning imho.

  3. #3
    Join Date
    Apr 2010
    Posts
    669

    Default

    And this is as it should be. Calling something a Release Candidate has a fairly standard meaning in software development - i.e that it's identical to the final release, barring any serious bugs found in the candidate.

    If new functionality isn't ready when the merge window closes, that should be it - wait until next time. Don't sneak it into the release during testing.

  4. #4

    Default

    It is about time that he started forcing people to do only bug fixes during a RC. That is how it is supposed to be.

  5. #5
    Join Date
    Jun 2009
    Posts
    2,908

    Default

    Quote Originally Posted by d2kx View Post
    Well, rc2 brought in the voltage power management for the opensource radeon stack and the rc3 has additional power management fixes. This is worth mentioning imho.
    I must have missed this. The voltage adjustment code is in this?

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    Quote Originally Posted by Shining Arcanine View Post
    It is about time that he started forcing people to do only bug fixes during a RC. That is how it is supposed to be.
    That would probably require changing some milestone names and coming up with new rules. A short, "on/off" merge window doesn't work particularly well in real life, but what *actually* happens in the Linux kernel *is* pretty good - sort of a "rounded" merge window where the big nasty stuff goes in the merge window, moderately risky stuff goes in the first RC, very slightly risky stuff goes in the second RC, and just bug fixes from that point on.

    Formalizing that is really hard - I've tried - so the easiest way to handle it is what you see in the kernel dev cycles today, with a narrowly defined merge window plus some informed flexibility on the first couple of "RC"s.

  7. #7

    Default

    Quote Originally Posted by bridgman View Post
    That would probably require changing some milestone names and coming up with new rules. A short, "on/off" merge window doesn't work particularly well in real life, but what *actually* happens in the Linux kernel *is* pretty good - sort of a "rounded" merge window where the big nasty stuff goes in the merge window, moderately risky stuff goes in the first RC, very slightly risky stuff goes in the second RC, and just bug fixes from that point on.

    Formalizing that is really hard - I've tried - so the easiest way to handle it is what you see in the kernel dev cycles today, with a narrowly defined merge window plus some informed flexibility on the first couple of "RC"s.
    Why not define alphas and betas then? The RC tag should only mean that they think that things are production ready.

  8. #8
    Join Date
    Oct 2008
    Posts
    2,911

    Default

    Quote Originally Posted by Shining Arcanine View Post
    Why not define alphas and betas then? The RC tag should only mean that they think that things are production ready.
    That's what the first couple RC kernel releases are, but Linus decided to call them all release candidates because he found fewer people tested when he called them alpha or beta releases. That's all there is to it.

  9. #9
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    Exactly. Might be as simple as RC1 => Alpha, RC2 => Beta, RC3 => RC1 etc...

    The problem with that approach is that Alpha and Beta milestones get abused as well (or, more charitably, there are conflicting views of what those terms mean).

    The current model isn't quite right from a semantic point of view (I don't think many people would consider an RC1 kernel to be production-ready, for example) but it's easy to understand and Linus has the time and the experience to look at post-RC1 changes and pass judgement on whether or not they should be allowed in.

    My personal vote would be to rename the first two milestones in the interest of "correctness" but I suspect that even changing the names would result in relatively more high-risk changes being submitted after the initial merge window because people would percieve a change of intent rather than just tweaking the milestone names to match the desired behaviour.

    Disclaimer - I have not discussed this with Linus or any of the non-graphics kernel developers so their view may be that everyone just needs to learn how to obey the damn merge window

    EDIT - just saw smitty's post, sounds like this has already been discussed.

  10. #10

    Default

    Quote Originally Posted by smitty3268 View Post
    That's what the first couple RC kernel releases are, but Linus decided to call them all release candidates because he found fewer people tested when he called them alpha or beta releases. That's all there is to it.
    He has less people testing RCs because of that policy. For instance, I stopped using his RCs after I realized that they are not really RCs.

Posting Permissions

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