On 05/04/2008, Richard Creighton
Jan, I think you miss the point....David is rightly saying that the reason there are no old bugs is because they keep closing them for the wrong reasons. ... support SuSE and do all of the Alpha/Beta testing, I now rarely bother to do bug reports because my experience has been that when you present something to them that is too hard or out of the ordinary or even just inconvenient, it gets shunted aside.
I have to disagree. Having used various projects' bug trackers I have the best experience with the openSUSE bugzilla. Bugs are generally triaged very quickly (<24hrs mostly in my experience) and either resolved as duplicates or assigned to the appropriate people. The assignees are also usually very responsive at acknowledging and requesting additional information. Bugs that will be fixed first are generally a) the most critical, and b) the easiest to reproduce or identify. The former depends on the severity of the problem and the number of users it affects. The latter depends how good the bug report is. Review http://en.opensuse.org/Bugs#Reporting_a_Bug for information about how to best report a bug in some specific products. There is little point in complaints such as this one about a specific bug being closed when you do not believe it was resolved. Instead take the appropriate action. Bear in mind that the developers closing bugs are all individual people. It is not a Novell conspiracy to close n bugs per day, in fact the Novell bugzilla is used by many people, not just Novell employees. The phrase "the guys over there" does not make sense. The Bugzilla instance is a service which can be used freely by anyone. I also object to the suggestion of bugs being closed for "cockemamy reasons". Ultimately whether a bug can or should be fixed is up to the developer of the software the bug is present in, and or project management. Would you rather a developer spends weeks fixing a bug that may or may not be valid, where the reporter provides insufficient information, all the while forsaking hundreds of other valid bugs? Some suggestions of how to better deal with bugs being closed: If a bug is resolved as NORESPONSE or WORKSFORME this usually means you have not provided enough information for the assignee to reproduce. , or identify the cause of the bug. Often it will have been NEEDINFO before this. If you can provide the information re-open the bug with the required information. If you cannot provide sufficient information then you can always ask on the mailing list whether anyone else experiences the same issue, and for help diagnosing the problem. If a bug is resolved as FIXED when it is not fixed then re-open and attach the appropriate evidence (logs, screenshots...), ensuring that you have tested with the version of software that it is supposedly fixed in. If a bug is resolved as LATER then it could mean that it can't be fixed in the immediate future because of policy such as a string/feature freeze. It could mean that the assignee does not have time to fix it for the coming version, but the bug is acknowledged. Bear in mind that not everything can be fixed, there are limited manhours available. If a bug is left in a NEW state for an extended length of time, you can try asking one of the maintainers about it, or asking on the mailing list. This is fairly unusual for important bugs. If a bug is marked as WONTFIX then this means the bug is acknowledged as being a bug, but won't be fixed. This might happen if the bug/enhancement is too difficult to fix, or if a requested feature conflicts with a project policy/aim. The person who marks it as wontfix should also include a reason for marking it WONTFIX. If you disagree with the reasoning, and can find enough people who agree with you then it might be possible to have the decision reconsidered. Especially if the reason is difficulty/expense and someone will volunteer to fix it. If a bug is resolved as INVALID it is not considered a bug. Could be it is simply a junk report, there are surprisingly regular reports that are almost spam e.g. no details at all are provided. Or it is expected behaviour, or it is not a bug in the software at all. In this case it was a) probably a hardware problem, and b) problem was triggered by third party proprietary closed source driver, which the developers have no control over. Also remember that unless the bug is in a suse specific product, or caused by a suse specific patch you can report the bug upstream. Hope this helps -- Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org