Announcement

Collapse
No announcement yet.

Bcachefs Squeezes Last Minute Feature Work Into Linux 6.8

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

  • #21
    Originally posted by varikonniemi View Post

    It's a side-effect of the Linux dev team wanting to minimize the intrusiveness of the bcachefs merge.
    I see, that makes sense, thanks.

    Comment


    • #22
      This guy has been working tirelessly for years on something that he is passionate about and that will benefit many people.

      I don't get why people are trying to point out flaws in his personality. None of us are perfect.

      Next time you are reporting on "his flaws", please state what you have done to make linux/opensource better for everyone...

      Comment


      • #23
        Originally posted by Raka555 View Post
        This guy has been working tirelessly for years on something that he is passionate about and that will benefit many people.

        I don't get why people are trying to point out flaws in his personality. None of us are perfect.

        Next time you are reporting on "his flaws", please state what you have done to make linux/opensource better for everyone...
        i rEpOrTeD An iSsUe!

        Comment


        • #24
          Originally posted by fitzie View Post

          this is just not the issue at all. linus isn't saying that kent skipped linux-next (which it turns out he did), he is saying that there is non-bug fixes being added to the bcachefs submission that were created after the merge window opened. the rule is pretty simple, all development targeting a kernel release should switch to bug fixes as soon as the merge window opens, and ideally days before the window opens so it has time to bake in linux-next.
          If that's true the kernel team failed badly at naming, because that's widely known as a feature freeze. When someone has patches ready _inside the merge window_ then they're in time per definition. They shouldn't be called late and they should be called a dick for cutting it close either.

          Comment


          • #25
            Originally posted by fallingcats View Post

            If that's true the kernel team failed badly at naming, because that's widely known as a feature freeze. When someone has patches ready _inside the merge window_ then they're in time per definition. They shouldn't be called late and they should be called a dick for cutting it close either.
            yes, you can read linus explaining this here: https://lore.kernel.org/lkml/CAHk-=w...ail.gmail.com/

            Yes, the merge window is two weeks, but that's very much to allow me
            time to look things over, not "two weeks to hurriedly put together a
            branch that you send Linus on Friday of the second week". The whole
            "do an all-nighter to get the paper in the day before the dealine" is
            something that should have gone out the window after highschool. Not
            for kernel development.

            The rule is that things that get sent to me should be ready *before*
            the merge window opens, not be made ready during the merge window.
            With some slack for "life happens", of course, but I really get the
            feeling that a few people treat the end of the merge window as a
            deadline, missing the whole "it was supposed to be ready before the
            merge window".‚Äč

            Comment

            Working...
            X