Announcement

Collapse
No announcement yet.

The Linux 2.6.35-rc3 Kernel Update Is Small

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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?

          Comment


          • #6
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      Ok, I don't have much time to build other kernels, so I'm just asking:

                      am I the only one to experience whole system hangs, as long as I'm not pressing keys (creating hw interrupts?) during the initscripts?
                      The text cursor itself stops blinking while writing the initscripts' output. It's really strange.
                      Holding a key, permits starting the hraphical environment stack (KDM, Xorg, blah), which seems to let me use the system normally.
                      Didn't try switching to another VT, to see if the hang remains there.

                      Custom built 2.6.34 works correctly.
                      Custom built 2.6.35-rc[123] hangs.
                      KMS on a Radeon Mobility 3470.

                      Didn't try disabling KMS. I will.

                      Anyone sharing the same experience?

                      Comment


                      • #12
                        Good for Linus; good for Linux.

                        RC revisions are *supposed* to be limited to bug fixes - just like everything else after alpha.

                        Comment


                        • #13
                          Sure, but the reason for this discussion was that the current Linux kernel development cycle does not *have* an alpha milestone.

                          Even the milestone at the end of the merge window is called an "RC".

                          Comment


                          • #14
                            What about h.264 video acceleration for Radeon cards via VA-API? Is it expected for 2.6.35 or 2.6.36? coz Intel's h.264 hw acceleration is being developed for this version, innit?

                            Comment


                            • #15
                              That does not belong in the kernel, it is being written for the Gallium3d framework, and this does not work on UVD2-capable hardware yet.

                              Comment

                              Working...
                              X