Remember that TCP is robust enough that it seems to work anyhow - even at the cost of reduced network throughput in this case.
That to me sounds like this is not really a bug, but a performance enhancement; a bug would be something like corrupted/missing/extra data at the application level. Tuning the TCP algorithms beyond the basics is really more of an art.
Presumably it is considered to be a bug because it does not accomplish what the code is meant to accomplish - namely, the code does not properly characterize a congested state and thus does not operate as if it were congested.
Given your definition, and viewed from a high enough level, every feature or enhancement is a bug fix. I think nitpicking the wording (while an interesting philosophical discussion) detracts from the point of the article: an unnamed Google engineer waded into the Linux kernel code and made the web slightly better for many people.
You've hit on a fine point I often make about how the term "security bug" is used.
I would call this a bug fix since someone has found what is probably an unintended behavior in the cubic algorithm. The cubic algorithm itself though would be a feature improving on the original tcp algorithm (nagle, if I remember right)
No a feature or enhancement mostly introduces something new, like a new algorithm for cubic congestion control, which this patch of course doesn't to, it just fixes the old one. ;)
> that an endpoint that is not moving any traffic cannot use the lack of errors as information in its feedback loop.
I think the bug is that it was counting something when it should have not been, which would have violated both the design and intent even at the time it was written.
But I agree that code is only a bug if it does not do what was originally intended, if the original design was bad, and the code correctly implemented that bad design, there is no bug.
Programming is 100% design, there really is no separate "implementation" phase.
If the design has a flaw, whatever the reason: it is a bug.
A big part of development is "discovering the requirements."
It is typically the hardest part for real world projects,
and when that fails, it is perhaps not a bug in the code,
but it still a development error that needs to be fixed.
If a developer got a piece of paper that said "blue" but
the real world requirement was "green", and it was not
possible for the developer to find out together with
any stakeholder, then there is a development process error,
that needs to be fixed.
In any event, it needs to be fixed, so pointing to someone
else wont really help.
> But I agree that code is only a bug if it does not do what was originally intended, if the original design was bad, and the code correctly implemented that bad design, there is no bug.
The frame of reference for determining if something is a bug or not is the requirement specification, not design. If the design incorrectly or inadequately addresses the requirement, that is a bug as well. There isn't much point in rejoicing over the code that correctly implements an incorrect design!
I think the frame of reference is the programmer intent. If he/she intended to check for equality but wrote:
if (x = 42) {
Then that is most certainly a bug.
If a bit of text was supposed to be blue but came out green, maybe because the person writing the requirements doc got it wrong, it is hardly a bug in the code. The code is doing what the programmer intended, even if that is not what the user wanted. That's why the world has moved on from "bug trackers" to "issue trackers".
> There isn't much point in rejoicing over the code that correctly implements an incorrect design!
And there isn't much point blaming a coder for correctly implementing an incorrect design, especially if the design document is all they have to go on.
> I think the frame of reference is the programmer intent.
Sure. However, that is secondary. The sort of mistakes that you mention can be caught during code review or unit testing, completely independently of what the actual user requirement is. This post, evidently, does not involve such a case.
> The code is doing what the programmer intended, even if that is not what the user wanted.
Your perspective appears to be inside-outward. It may be helpful during a performance appraisal, but does the business no good!
I don't think "bug" is a very well-defined term. It seemingly encompasses most software imperfections. I guess people will generally characterize things based on their overall (negative) impact.
That to me sounds like this is not really a bug, but a performance enhancement; a bug would be something like corrupted/missing/extra data at the application level. Tuning the TCP algorithms beyond the basics is really more of an art.