Fixed means fixed in a production release [LWN.net]

Fixed means fixed in a production release

Posted Feb 2, 2012 15:57 UTC (Thu) by epa (subscriber, #39769)
Parent article: FreeBSD and release engineering

Remember - if it's not fixed in the production release, it's NOT FIXED.

This is something that afflicts other free software projects too. It is disconcerting to file a bug report and have it closed because a fix has been checked in to version control, never mind that there is no released version with the fix. If the concept of a 'stable' or 'supported' release is to mean anything, it must mean that bugs are fixed there.

Perhaps unpaid free software developers do not have the time or resources to maintain a stable release and port bug fixes to it, but that is a separate issue. It would be better to simply acknowledge that and tell everyone to use the latest version all the time.

(Log in to post comments)

Fixed means fixed in a production release

Posted Feb 3, 2012 0:18 UTC (Fri) by cwillu (subscriber, #67268) [Link]

A bug tracker is a tool for developers to keep track of known behaviour, not a voting system, not a trouble-ticket system, and not an order-taking system.

To be completely frank, it's not meant as a place for a user to have his voice heard. (That's why "filing bugs" is listed under "things you can do to help the project", rather than under "how to get support").

[http://www.reddit.com/r/browsers/comments/no4c7/bug_90268...

Fixed means fixed in a production release

Posted Feb 3, 2012 10:20 UTC (Fri) by epa (subscriber, #39769) [Link]

A bug tracker is a tool for developers to keep track of known behaviour,

That's fine, but the released version is also code and also has bugs just as much as the HEAD. If bugs in the current stable version do not belong in the developers' bug tracker, there needs to be a separate tracker for them.

Really all I'm saying is that as well as the 'closed' status in the bug tracker there needs to be one for 'fixed in HEAD but not fixed in production releases'. Then developers who are not inclined to go round patching older versions can filter out that status; users and others who want to collaborate on fixing the current stable version can work on these bugs.

Fixed means fixed in a production release

Posted Feb 4, 2012 22:17 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

A bug tracker is a tool for developers to keep track of known behaviour,

You must be talking about some particular bug trackers because many bug trackers are in fact for lots of other things.

Some bug trackers provide the important service of telling users what not to waste their time reporting because it's already been reported. Some provide the service of telling users what bugs they can eliminate by switching to another release or just waiting.

None of that is relevant here, of course, where the disappointment springs not from the way the bug tracker is used but from the statement of process made in response to the bug report: this isn't going to get fixed for you. I just wanted to dispute an overgeneralization about bug trackers.

Fixed means fixed in a production release

Posted Feb 5, 2012 10:45 UTC (Sun) by epa (subscriber, #39769) [Link]

Again, it's not really that the statement of process is a bad thing. An explicit policy that bugs are not fixed in the current release would be reasonable - but then, please drop the pretence of having a 'supported' stable release. What seems to happen is that a fix is checked in and the bug is closed, more out of habit or a desire to stop it appearing on the list of open bugs than as a conscious choice. This makes it more difficult to maintain the stable release in parallel with the latest development version, and makes it less likely that the bug will be fixed in stable, even if it is a professed goal of the project and its developers to support the stable release with fixes.

Fixed means fixed in a production release

Posted Feb 6, 2012 6:40 UTC (Mon) by k8to (subscriber, #15413) [Link]

I work specifically on maintaining release versions of a commercial software package. Unfortunately this problem afflicts me too, because are process is not as I would have it in my dreams.

I get a defect piled onto me. I dig around in the symptoms and hopefully figure out what's wrong. I add tests to show whether it works or not, and then show my proposed changes fix the problem.

Then I commit those changes and mark it fixed.

It may not ship for 2 months.

This is a point of frustration for me, but we can't release the same day -- we should do *some* general testing before we issue a publically available release. And the general testers have to work on future work as well as production point releases, as well as special one-offs. It's just not easy all around. But from my view as a developer, if I've proved I've fixed it, it's fixed. I'd much *rather* have a customer get at test build that both confirms the fix satisfies the real need and gives them a stopgap solution. But I don't get to make the call, and the customer is often not willing to run such 'experimental' changes, even if they are the changes they themselves need.

It's just a kind of icky thing about software. Tighter cycles would help, up to a point.

Fixed means fixed in a production release

Posted Feb 9, 2012 14:29 UTC (Thu) by renox (subscriber, #23785) [Link]

[Then I commit those changes and mark it fixed.
It may not ship for 2 months.]

Lucky you, I work in a field where there may be *years* between a fix and a new SW version containing release.
And users won't upgrade, so it makes debugging very frustrating: OK, I've spent one week of analysis to find out that the issue was corrected two years ago, please upgrade?