Mailinglist Archive: opensuse (2348 mails)

< Previous Next >
Re: [opensuse] Novell Bugzilla - At it Again - Bugs Apparently Dismissed Without Sufficient Investigation
  • From: Richard Creighton <ricreig@xxxxxxxxx>
  • Date: Sat, 05 Apr 2008 13:06:03 -0400
  • Message-id: <47F7B17B.6070705@xxxxxxxxx>
Benji Weber wrote:
On 05/04/2008, Richard Creighton <ricreig@xxxxxxxxx> 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
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 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

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 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.

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups