That was.... surprisingly tame, coming from Torvald.
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 …
Monday 25th June 2018 05:12 GMT Pete 2
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!
Monday 25th June 2018 05:57 GMT 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)
Monday 25th June 2018 07:45 GMT 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.
Monday 25th June 2018 10:07 GMT vtcodger
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.
Monday 25th June 2018 12:34 GMT Dazed and Confused
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.
Monday 25th June 2018 11:42 GMT Doctor Syntax
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.
Monday 25th June 2018 12:05 GMT oiseau
Re: A thin line
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 considerthe project leader considers to be the baseline functionality.
After all, he invented (thanks LT!) the damned thing.
There you go.
Monday 25th June 2018 11:48 GMT Doctor Syntax
Re: Is it still...
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.