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

Thread: ACPI Updated For The Linux 3.5 Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    14,351

    Default ACPI Updated For The Linux 3.5 Kernel

    Phoronix: ACPI Updated For The Linux 3.5 Kernel

    The ACPI feature pull request for the Linux 3.5 kernel merge window was submitted on Saturday...

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

  2. #2
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    90

    Default

    Looks like Linus will reject and move it to 3.6.

  3. #3
    Join Date
    Nov 2011
    Posts
    351

    Default

    I think having one man reviewing every code submission for a kernel is a stupid policy. why don't they have a kernel review team like in freebsd? unless linus insists that he is the author of the kernel.

  4. #4
    Join Date
    Mar 2011
    Location
    Canada
    Posts
    95

    Default

    Quote Originally Posted by garegin View Post
    I think having one man reviewing every code submission for a kernel is a stupid policy. why don't they have a kernel review team like in freebsd? unless linus insists that he is the author of the kernel.
    You should do a bit of research before trying to criticize something and throw in your two cents.

    Do you really think Linus is reviewing millions of lines of code by himself? He just has the final say when it comes to merging branches that have already gone through the hierarchy of the review/development process.

    Each kernel component has a lieutenant maintaining it, and then responsibility is delegated down from there. They're the ones who send in pull requests to Linus.

    He has a very high-level view of the development, and his decisions are mostly based on whether a branch has become stable enough to be merged in the current window, or if it will have to wait another cycle (or more).
    Last edited by strcat; 06-03-2012 at 12:02 PM.

  5. #5
    Join Date
    Nov 2011
    Posts
    351

    Default

    still, he still has to "review the reviews". i don't understand the wisdom behind that.

  6. #6
    Join Date
    Oct 2008
    Posts
    3,036

    Default

    Quote Originally Posted by garegin View Post
    still, he still has to "review the reviews". i don't understand the wisdom behind that.
    He doesn't have to, he's free to to just apply everything that gets sent to him.

    The point is he is free to reject code if he feels it's in the best interests of the kernel as a whole, even when his lieutenants say the code is ready to go for their subsystem.

    In other words, he's the release manager.
    Last edited by smitty3268; 06-03-2012 at 02:29 PM.

  7. #7
    Join Date
    May 2010
    Posts
    135

    Default

    Quote Originally Posted by garegin View Post
    still, he still has to "review the reviews". i don't understand the wisdom behind that.
    Somewhere along the line, there has to be a final answer given as to whether something is in or out. Punting that to a committee doesn't solve the apparent problem; the people on the committee will still probably be unfamiliar with the details and may do no better than a single person who makes the final decision.

  8. #8
    Join Date
    Oct 2011
    Location
    Toruń, Poland
    Posts
    160

    Default

    Quote Originally Posted by siride View Post
    Somewhere along the line, there has to be a final answer given as to whether something is in or out. Punting that to a committee doesn't solve the apparent problem; the people on the committee will still probably be unfamiliar with the details and may do no better than a single person who makes the final decision.
    I see one more reason why the process is delegated to a single person. Humans are built such that they need a single leader to perform most efficiently. Multiple leaders introduce the risk of disagreements which slow down any process. There must be one person who has the final say on a given matter. Of course this is risky too, as despothies have showed in the history. That's what advisors are for. But again - there must be single driver for the best efficiency. I could write some more about it. Maybe even a full-blow essay. Unfortunately I am not a good writer, so I will let it be in my mind.

  9. #9
    Join Date
    Jan 2011
    Posts
    185

    Default

    Quote Originally Posted by Hirager View Post
    I see one more reason why the process is delegated to a single person. Humans are built such that they need a single leader to perform most efficiently. Multiple leaders introduce the risk of disagreements which slow down any process. There must be one person who has the final say on a given matter. Of course this is risky too, as despothies have showed in the history. That's what advisors are for. But again - there must be single driver for the best efficiency. I could write some more about it. Maybe even a full-blow essay. Unfortunately I am not a good writer, so I will let it be in my mind.
    But multiple people are less likely to make rash mistakes. You get more information and experience informing the decision. A stalement about a design decision wouldn't be the end of the world, if someone needed a feature right now, they could fork the kernel.

    In this case I think it's just a historical accident that you have one guy making the final cut because that's what he's done before, and he's done a decent job at it.

  10. #10
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    399

    Default

    Quote Originally Posted by garegin View Post
    I think having one man reviewing every code submission for a kernel is a stupid policy. why don't they have a kernel review team like in freebsd?
    Why?

    (10 char)

Posting Permissions

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