Bug Status WONTFIX
The Meaning of WONTFIX
explains WONTFIX only in very short terms:
"WONTFIX The problem described is a bug which will never be fixed."
That means that WONTFIX acknowledges that a bug as reported is indeed a valid bug. But it also says that it will not be fixed: Not in the near future (that would be status ACCEPTED), not in some future release (that would be LATER), never.
It means that whoever is responsible for the piece of software against which the bug was reported has examined the situation and evaluated possible approaches to fix the problem. But the conclusion of that process was that the bug will not be fixed.
Of course, this is unsatisfactory for a user who took the trouble to make a bug report. Agreed. But there are also other considerations to take into account.
Reasons for WONTFIX
There is no solution at all.
Even though this happens only rarely, it can happen. Typically, this is the result of a previous conscious decision (in the design or implementation of the software) in which the lesser of two evils had been chosen. The trade-off that had been taken back then is what was reported as a bug, and that bug got closed as WONTFIX.
The problem could be fixed, but the cost for the fix (the amount of work involved) would be enormous. It would be an economic nightmare to do the fix.
This would really be a status TOOEXPENSIVE that Bugzilla does not provide.
In an ideal world, no cost whatsoever would be too expensive. But we all live in a less-than-ideal world, and so economy has to be taken into account. This is not only important for us (SUSE/openSUSE) as the distribution makers (or in general for the company who has to pay for the development hours), it is also important for the users: Since there is only a finite number of developers and thus of development hours, hours spent on fixing such a bug cannot be spent on developing something new or even just on fixing other bugs that may be more important.
Fix Would Add Too Much Complexity
The problem could be fixed, but the fix would make the software much more complex and thus much less maintainable and possibly also much less stable.
This is partly "Too Expensive" above again, partly another aspect that users benefit a lot from: Software stability. You don't want to compromise stability for issues that are not really important.
Must Be Fixed Upstream
The problem is in another piece of software that this software depends on, but that other software is being developed and maintained elsewhere. The fix has to be done upstream (by the authors of that other software).
Yes, we as the distribution makers do make some fixes in software that is developed elsewhere. But that is limited to minor fixes. It clearly does not involve major rewrites of upstream software. Those rewrites would go to waste with the next upstream release.
Sometimes we do even that and send the patch upstream, hoping that it will be accepted and incorporated into the next upstream release. But this requires that the upstream developers are very cooperative, and that they are not already working on another solution our fix would be incompatible to.
Demand an Explanation for Each Case of WONTFIX!
Whichever reasoning might be behind resolving a bug as WONTFIX, it deserves a clear explanation that the bug reporter can understand. This is what we owe to somebody who goes through the trouble of reporting a bug. This is our moral obligation to the bug reporter.
If a bug was WONTFIXed without such an explanation, please ask again for it. The best place to do that is usually within the bug report. You don't need to reopen a bug for that, but you can and you should if no explanation is given within a reasonable time frame (please allow for time zone differences).
WONTFIX vs. LATER
The question has been raised if we at SUSE get paid by the number of bug reports we get rid of and thus close bugs with WONTFIX. The answer is a clear "no". That would obviously not make any sense, too.
But Bugzilla is an important tool for us. So it makes sense for us to resolve issues that can easily be resolved before they clutter our list of active bugs too much.
It's also a question of honesty. While we could accumulate a large number of bugs and pretend that we will fix them at some point, wouldn't you rather have us be honest and clearly say if an issue does not have the slightest chance of getting fixed in a forseeable time frame?
Of course such honesty can sometimes be brutal. If somebody has a "favourite issue" to get fixed, of course it is disappointing to hear that it has been given consideration and decided against.
On the plus side, you might even see it as us defending the one thing we put a lot of our life blood into: Our distribution, no matter if it's the business products or the community project. We have to think economically. If one day the money stops rolling in because we distributed our available development hours unwisely on minor issues, the distribution will be dead. Then nobody will benefit from those minor issues being fixed.
Like it or not, we can only put so much time into every one of our releases. We constantly have to make decisions. Some of them may result in a less-than-perfect product, but a product that remains alive and kicking, a product that gets released on a regular release cycle.
Some users may not like some of the decisions we make. That's life. You just can't be everybody's darling. ;-)