back to article Linus Torvalds tells kernel devs to fix their regressive fixing

Linus Torvalds has given the Linux kernel development community a bit of a touch-up, after finding some contributions to Linux 4.18 complicated the kernel development process. In his post announcing release candidate 2 of Linux kernel 4.18, Torvalds mentioned “some noticeable filesystem updates, particularly to cifs.” “I'm …

  1. Neoc

    That was.... surprisingly tame, coming from Torvald.

    1. MacroRodent

      Re surprisingly tame

      Usually he is reasonable, the colourful outbursts just get more press coverage.

    2. Pascal Monett Silver badge
      Coat

      It would seem that this time the problem did not warrant a full-blown volcanic eruption.

      Pity, I always enjoy the colors (from a safe distance).

    3. Anonymous Coward
      Anonymous Coward

      Next: Linus Torvalds says get rid of systemd

      Next: Linus Torvalds tells RedHat to get rid of systemd or else

  2. Pete 2 Silver badge

    A thin line

    > But if it's something that has never worked, even if it ‘fixes’ some behavior, then it's new development,

    I can understand the thinking behind this, but the question of whether something is a "fix" or "new" depends on what you consider to be the baseline functionality.

    Torvalds' view seems to be that the definition of what Linux should do is held in the body of code that (used to work). That the code defines the functionality.

    A more professional approach is that the design documents define the functionality and a deviation of the code, from the documentation, is a bug.

    Now I realise that a lot of hacker-style amateur coders will already be rolling around on the floor, laughing at the idea of documentation. And even more so at the suggestion that it should be telling them what their software should do - rather than being a description of what it actually does. However, that is the reason we have standards. To define what software should do, in order for it to work with compliant systems that other people have developed.

    One could therefore argue against Torvalds' opinion and say that lack of standards compliance - and design documents set those standards - is as much a bug as broken functionality that used to work. Although that does rather assume that Linux has some design documents in the first place!

    1. Anonymous Coward
      Anonymous Coward

      Re: A thin line

      and a deviation of the code, from the documentation, is a bug

      AFAICT (based on the article) Linus does not disagree with that definition.

      He merely points out that once you get this close to release, then letting sleeping dogs lie (don't bother with bugs that have been in place for several versions) is his preferred strategy.

      It is a discussion I see a lot at the place I'm currently employed. Every release has a tendency to balloon out as every regression tester tries to wedge in his/her favorite bug. Which in turns translates into more testing at a stage where we really would like to push out the new release since it a) is better than the cr-p we released last time and b) isn't introducing any new known bugs.

      If the product owner wants to prioritize fixing old bugs (something we devs cheer for) then that should ideally be done at the beginning of the _next_ release cycle.

      YMMV. I spend a lot of time cleaning up past mistakes and weak code from my predecessors. No doubt put in there as a result of poor management. When the previous coders left (in disgust?), unfortunately nobody thought of replacing said management. But no worries, we will have another internal seminar in a few months to strengthen our team spirit. Surely the problem rests with us plebs, not the top brass.

      (anon because I am tempted to show this article to some of my colleagues and they might wander into the comment section by accident)

      1. Vanir

        Re: A thin line

        AC: "Surely the problem rests with us plebs, not the top brass."

        But you previously stated: "No doubt put in there as a result of poor management. ... unfortunately nobody thought of replacing said management." I infer from this that you think that the management are a problem too. The 'top brass' being a part of management is also by deduction a problem; unless the top brass is the nobody you speak of.

        It has to be noted that many managers also write code that goes into the release product and that many managers also dictate what code goes into the released software.

        I've not seen any managers leave in disgust over a poor quality base even when they admit this fact.

        1. Blane Bramble

          Re: A thin line

          But you previously stated: "No doubt put in there as a result of poor management. ... unfortunately nobody thought of replacing said management."

          I take it they don't do sarcasm where you're from.

    2. vtcodger Silver badge

      Re: A thin line

      "A more professional approach is that the design documents define the functionality and a deviation of the code, from the documentation, is a bug"

      Sigh ... Somewhere, perhaps, there is an unparallel universe, where software is carefully designed before it is coded, and programmers translate carefully written specifications from people-speak to machine-speak. And I'm sure if it exists, it runs a lot better than this universe.

      But in this universe, specifications -- other than interface specs sometimes -- are uncommon and when they exist at all are more often than not, useless or worse.

      1. Dazed and Confused
        Facepalm

        Re: A thin line

        > Sigh ... Somewhere, perhaps, there is an unparallel universe, where software is carefully designed before it is coded, and programmers translate carefully written specifications from people-speak to machine-speak. And I'm sure if it exists, it runs a lot better than this universe.

        OK, so it's been 20ish years since I was programming professionally, rather than just hacking the odd bit together to solve an immediate problem.

        This is how we worked back then.

        I was working for one of the major IT vendors. There was an "external reference specification" written and only once that was agreed on were we allowed to start coding. If you found something which couldn't work out in code it took an act of god to get the spec changed and you'd get a kick up the pants for not having got the spec right. You didn't just add code on a whim.

        I know that company no longer works that way. I know they have a lot more quality issues. In fact non of what we did as "good practice" seems still to be done.

    3. Doctor Syntax Silver badge

      Re: A thin line

      Design documentation comes from the system architect. In collaboratively developed S/W the system architect's role, such as exists, falls on the maintainer. But in the maintainer's role is mostly reactive rather than proactive. He can determine architecture by admitting, leaving out or even removing stuff (in Linus' case he's already said he doesn't write much if anything any more).

      Contributions of S/W are determined not by some over-arching view of what should be in there but by some developer (or, more likely in the case of Linux, their employer) concluding that something is needed or needs fixing*. Part of the traditional system architect's role it do determine what the requirements are for the system. The collaborative approach supersedes that part by having contributions arise directly from the perceived requirement.

      Documentation is, however, a point that ought to be thought of more. One approach would be to require a documentation patch. For new functionality that could go into the primary documentation, for bug fixes it could mark an item in a reported bug list as being fixed or report the bug and mark it fixed at the same time. That would solve Linus' immediate problem except that it's a bit late to start that now.

      * Occasionally a contribution can arise from someone providing a bounty.

    4. oiseau
      WTF?

      Re: A thin line

      Hello:

      Hmm ...

      If you add something that was not there before, it is quite clearly not a fix, it is an addition.

      That said, the question of whether something is a "fix" or "new" depends on what you consider the project leader considers to be the baseline functionality.

      After all, he invented (thanks LT!) the damned thing.

      There you go.

    5. Pascal Monett Silver badge

      @Pete 2 Re: "A more professional approach"

      Pete 2, I very much doubt you have any qulification to teach Torvalds what a "professional approach" is in kernel design.

      I think he's been at it long enough to have a gist of the general idea.

  3. Anonymous Coward
    Anonymous Coward

    Is it still...

    ...not finished?

    1. Waseem Alkurdi

      Re: Is it still...

      Nor it will be.

      1. jake Silver badge

        Re: Is it still...

        It'll be finished approximately three months (give or take) after the hardware is finished.

    2. Doctor Syntax Silver badge

      Re: Is it still...

      "...not finished?"

      It's not being finished, it's being maintained. In S/W development maintenance is a never-ending process of chasing new requirements. In an O/S - and take your pick of vendor or open source project - those new requirements are largely innovations or updates in the H/W on which it sits.

      Arguably it was finished by definition at 1.0.

  4. Anonymous Coward
    Anonymous Coward

    #

    NSA is hacking Linus trying to add new features :P . too bad he saw the "fix"

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like