Bcachefs Fixes Pull Once Again Frustrates Linus Torvalds - Two Choices Offered

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • PuckPoltergeist
    Senior Member
    • Jan 2009
    • 477

    Originally posted by Uiop View Post

    You mean: it's fine to drop Bcachefs out of the kernel just because its so hard to tolerate Kent's behavior?
    If it's a pain in the ass to work with the maintainer, if this maintainer doesn't follow common rules and doesn't work together with other developers, yes. Wouldn't be the first time, Linus decides to stop working with some people. In "good old" IDE times, Alan Cox stepped in as proxy maintainer. Dropping the subsystem wasn't an option.

    What has he done? He had some objections and argued in an opinionated way.
    Sneaked in code that was NAKed by other developers/maintainers for example

    By the same criteria, I suggest that Linus should kick himself out of the kernel development.
    This was already answered in this thread.

    Comment

    • PuckPoltergeist
      Senior Member
      • Jan 2009
      • 477

      Originally posted by mdedetrich View Post

      Aside from OpenRISC, all of those other architectures are either mainframes or insanely old (the motorola 68000 is from 1979).
      POWER/PowerPC is not mainframe


      Comment

      • mdedetrich
        Senior Member
        • Nov 2019
        • 2537

        Originally posted by PuckPoltergeist View Post

        If it's a pain in the ass to work with the maintainer, if this maintainer doesn't follow common rules and doesn't work together with other developers, yes. Wouldn't be the first time, Linus decides to stop working with some people. In "good old" IDE times, Alan Cox stepped in as proxy maintainer. Dropping the subsystem wasn't an option.
        What we now know (clarified by Linus himself) is that those rules weren't in fact rules but guidelines. What actually pissed off Linus was the build breaking, but in one case it was actually someone else (Christian) that broke the build and the other case was big-endien which has already been explained

        Originally posted by PuckPoltergeist View Post
        Sneaked in code that was NAKed by other developers/maintainers for example
        This ended up not being actually the case, it was a miscommunication that occured due to how disfunctioning mailing list style development is.
        Last edited by mdedetrich; 07 October 2024, 04:37 AM.

        Comment

        • intelfx
          Senior Member
          • Jun 2018
          • 1132

          Originally posted by Uiop View Post

          You mean: it's fine to drop Bcachefs out of the kernel just because its so hard to tolerate Kent's behavior?
          What has he done? He had some objections and argued in an opinionated way.
          By the same criteria, I suggest that Linus should kick himself out of the kernel development.
          Lol, exactly

          Comment

          • mdedetrich
            Senior Member
            • Nov 2019
            • 2537

            Originally posted by PuckPoltergeist View Post
            POWER/PowerPC is not mainframe

            I was directly quoting the list i.e. 68000, IBM System/360, z/Architecture and OpenRISC. I know that Power/PowerPC are not mainframes, but in any case they are also really old. PowerPC is still being manafactured but in really esoteric environments, apparently some fighter jets use it ¯\_(ツ)_/¯

            The point is that getting a hold of a big-endian machine as a standard human developer (which Kent is, he no longer works at a company) is insanely cumbersome and really its the place of Linux foundation to solve this issue.
            Last edited by mdedetrich; 07 October 2024, 04:40 AM.

            Comment

            • intelfx
              Senior Member
              • Jun 2018
              • 1132

              Originally posted by Uiop View Post
              Here is a question, one thing I don't understand.

              The well-known big-endian architectures are: 68000, IBM System/360, z/Architecture and OpenRISC.

              But, some other architectures are bi-endian, or some other strange mix of endianess, like: PowerPC (per-page choice), ARM AArch64 (instruction encoding, little endian by default otherwise).

              Wikipedia says: "Some architectures (including ARM versions 3 and above, PowerPC, Alpha, SPARC V9, MIPS, Intel i860, PA-RISC, SuperH SH-4 and IA-64) feature a setting which allows for switchable endianness in data fetches and stores, instruction fetches, or both."

              So, why is it not possible to buy an ARM CPU, and use it in the big-endian mode to do the big-endian tests? Or, a PowerPC?

              Or, is it just that such a big-endian test system is not yet available for the Linux kernel? I guess that is the real issue here.

              If the kernel doesn't have automated builds and tests in big-endianess mode, it's their own fault.
              I don't think Linux can even drive aarch64 as a big-endian arch. It's somewhat better for ppc64, but only somewhat — there seems to be very little (and very unofficial) support for ppc64 in recent distributions, it's mostly ppc64le everywhere. Some distros have unofficial ports though, so it _could_ be set up, but you can hardly blame Kent for not making it his personal priority.

              That said, I'd expect to at least do build-testing (which can be done using cross-toolchains), I guess this one is indeed objectively Kent's mistake.
              Last edited by intelfx; 07 October 2024, 04:50 AM.

              Comment

              • mrg666
                Senior Member
                • Mar 2023
                • 1070

                Linus's post should have been sent to Kent's email address only. It seems that Linus is preparing the stage to remove bcachefs next. Kent's reply is just as bad. What a drama! Yuck!

                Comment

                • PuckPoltergeist
                  Senior Member
                  • Jan 2009
                  • 477

                  Originally posted by mdedetrich View Post

                  What we now know (clarified by Linus himself) is that those rules weren't in fact rules but guidelines. What actually pissed off Linus was the build breaking, but in one case it was actually someone else (Christian) that broke the build and the other case was big-endien which has already been explained
                  Don't find something like this in this thread

                  This ended up not being actually the case, it was a miscommunication that occured due to how disfunctioning mailing list style development is.
                  Yeah, a developer who is already maintainer of a subsystem and should know the workflow is missing several NAKs from other developers and push code through different channels is just miscommunication

                  Comment

                  • PuckPoltergeist
                    Senior Member
                    • Jan 2009
                    • 477

                    Originally posted by intelfx View Post
                    That said, I'd expect to at least do build-testing (which can be done using cross-toolchains), I guess this one is indeed objectively Kent's mistake.
                    If it was going through the existing stages, it would had been tested. 68k is covered, so no extra cross-toolchains are necessary

                    Comment

                    • mdedetrich
                      Senior Member
                      • Nov 2019
                      • 2537

                      Originally posted by PuckPoltergeist View Post
                      Don't find something like this in this thread


                      And hey, that's literally just a "this was how we dealt with one particular situation". Not everybody needs to have the same rules, because the exact details will be different. I like doing releases on Sundays, because that way the people who do a fairly normal Mon-Fri week come in to a fresh release (whether rc or not). And people tend to like sending in their "work of the week" to me on Fridays, so I get a lot of pull requests on Friday, and most of the time that works just fine.
                      Like its extremely clear what Linus is saying, that these were not rules but rather rough back of the envelope guidelines that were created to solve a specific problem in the networking subsystem. Ontop of that he also admitted that these guidelines may not have been really responsible for improving the situation​.

                      Thats why he is open/flexible for other alternatives while still suggesting to put the patches through by Frday in the meantime.

                      Originally posted by PuckPoltergeist View Post

                      Yeah, a developer who is already maintainer of a subsystem and should know the workflow is missing several NAKs from other developers and push code through different channels is just miscommunication
                      People involved missed critical emails on the lkml, I don't have the patience to go through this again seeing as at the current moment you have issues reading lkml, either at all or in an objective manner.

                      Originally posted by PuckPoltergeist View Post

                      If it was going through the existing stages, it would had been tested. 68k is covered, so no extra cross-toolchains are necessary
                      Its not a nightly build that runs on fs-next, thats the core issue. Again this was stated on lkml quite clearly.​
                      Last edited by mdedetrich; 07 October 2024, 05:56 AM.

                      Comment

                      Working...
                      X