Benji Weber wrote:
On 05/04/2008, Richard Creighton <ricreig@gmail.com> wrote:
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
Benjamin, The bug David refers to is one of many. I did not file the particular bug he referred to, however the issue isn't a particular bug, it is a mentality being exhibitited. I read your response and the bugs in my case were rarely, if ever pertaining to 3rd party hardware problems. I don't want to get into a pissing contest, I have better things to do, but as an example, one of many, on their website, they have a nice article about how to set up and boot a RAID system. I refer you to http://en.opensuse.org/How_to_install_SUSE_Linux_on_software_RAID Well, I set up my system just like it said except I used RAID 5 for /home and 1.5TB total space but otherwise, as they suggested and with NO SEPARATE partition for /boot outside of the raid, just as shown. It worked fine. However, one day I wanted to run the YAST REPAIR, and it totally hosed my installed system and I filed bug 304657 among a bunch of others involving repair and raid problems such as 309040 329702 331604 331532 and many many others, not all my own but similar. If you research these and others, many filed originally by others than myself, these were NOT any of the type you mentioned in your response to me regarding David's complaint that too often, bugs lead nowhere despite clear, lucid and concerted efforts by the person(s) filing the report offering suggestions, help, time and effort to assist in debugging. Often, I found the report closed, and only got action after I reopened it. Some, after reopening got worked on and had long chains of interaction. Unfortunately few were resolved, but they were closed. Finally many bugs, including many of mine were closed as 'insufficient resources' or 'resources not allocated to debug this' or in some cases, obtuse 'promises' to look into it in "the next release". What I believe David is saying, and I know I am saying is this is a great way to win friends and influence enemies and encourage SERIOUS alpha and beta testing and ASSISTANCE by the community to Novell and openSUSE, NOT! I have found it much more productive to continue Alpha/Beta testing and attempting to find answers and helping people individually, one on one, rather than wasting my time writing bug reports about what color looks best as a background for green chameleons. There are a few people at both Novell and openSUSE.org that take the time to do the in-depth research and debugging for the serious problems, and I do communicate whatever tidbits of knowledge I come up with, but the buglist system, as implemented currently, does not inspire a lot of confidence for problems more serious than white lettering on a light-grey background in a menu or pop-up. Those problems, as David has alluded, seem to rarely get the attention or resources needed to resolve them. Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org