Announcement

Collapse
No announcement yet.

Linus: What's Wrong With The Whole DRM Crowd?

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

  • #21
    Originally posted by siride View Post
    For those who think Linus is just being mean, he's got a good point about keeping the Git history clean. Rebasing public branches really is a big no-no, and it can easily be avoided. Not avoiding it results in seriously fucked up commits and a lot of trouble downstream. It doesn't seem like Linus is complaining about the code quality so much as the development process, and that seems pretty darn fair to me.
    Agreed. I understand with Linus's beef and I fully agree with him. With the tools provided there is no need for the sloppy practices like this. They have all the proper tools they are just failing to utilize them properly thus defeating one of the main purposes of revision control. It looks like giving a mechanic a full set of tools only to see him bring out a hammer to set a set a screw.

    Comment


    • #22
      Originally posted by avilella View Post
      I am a bit lost with all the git jargon that is used in this example email, and others. I wonder what is the easiest to understand tutorial out there for git that would allow me to understand why "rebasing" can be a good or bad practise.
      http://git-scm.com/

      Just search around in the documents or the wiki. There are tutorials as well as full-blown, in depth explanations of how things work. TBH, the man page for git rebase will probably suffice to explain why you don't rebase public branches. It even has ascii-art diagrams.

      Comment


      • #23
        I also agree that he has good points to be strict on the kernel development conventions.
        Still, I don't see why it is necessary to be impolite to make a point.

        In my opinion this is just embarrassing, even if he just might be over-worked
        as the final authority in the kernel development process...

        Comment


        • #24
          Originally posted by entropy View Post
          I also agree that he has good points to be strict on the kernel development conventions.
          Still, I don't see why it is necessary to be impolite to make a point.

          In my opinion this is just embarrassing, even if he just might be over-worked
          as the final authority in the kernel development process...
          Because that's how Linus is. More importantly, everybody knows it. So getting flamed by Linus probably isn't that big of a deal. Dave's email back to Linus hardly showed that he felt affronted by Linus's commentary.

          Comment


          • #25
            Originally posted by entropy View Post
            I also agree that he has good points to be strict on the kernel development conventions. Still, I don't see why it is necessary to be impolite to make a point.

            In my opinion this is just embarrassing, even if he just might be over-worked as the final authority in the kernel development process...
            Oh please. Nobody ever said coding linux is a bed of roses. 1) You really need to have some skills, being a programmer expert is only enough for the minor changes. 2) If you do bad things, e.g. rebase something for no reason, commit poor code you, without question, _will_ be told that. The way you are told that depends on who, and in what mood, happens to response to such 'action' and how big your error was.

            You have to understand that it's a total different world in the kernel world.

            Comment


            • #26
              Originally posted by entropy View Post
              I also agree that he has good points to be strict on the kernel development conventions.
              Still, I don't see why it is necessary to be impolite to make a point.
              It's not the first time they have pulled shenanigans like this, frustration gets the better of everyone eventually.

              Comment


              • #27
                Originally posted by ArchLinux View Post
                As for BFS scheduler, it gives you the speed but with a noticable cost. Kolivas never even intended to push it to mainline.
                There is no cost in BFS. And CK didn't intent to push to mainline simply because mainline does not accept two schedulers; this was made clear years ago.

                Comment


                • #28
                  Originally posted by avilella View Post
                  I am a bit lost with all the git jargon that is used in this example email, and others. I wonder what is the easiest to understand tutorial out there for git that would allow me to understand why "rebasing" can be a good or bad practise.
                  The simplest explanation is that rebasing a tree changes the history of that tree. Which is bad when that history has already been made public, and other trees have been pulling changes from that history. It's not disastrous in the sense of data corruption, but it does make it a lot harder to track the history of a change.

                  Comment


                  • #29
                    Originally posted by avilella View Post
                    I am a bit lost with all the git jargon that is used in this example email, and others. I wonder what is the easiest to understand tutorial out there for git that would allow me to understand why "rebasing" can be a good or bad practise.
                    Examples of how to use rebase, but not much explanation about why rebasing publicly committed code is bad:

                    http://help.github.com/rebase/

                    Comment


                    • #30
                      Originally posted by deanjo View Post
                      It's not the first time they have pulled shenanigans like this, frustration gets the better of everyone eventually.
                      Especially when this kind of issues seem to repeat themselves. There should be examples of previous outbursts similar to this one on this very site.

                      Anyway both parties have their reasons, I guess.

                      Comment

                      Working...
                      X