FAQ/Bug Policy

From AbiWiki

(Redirected from FaqBugPolicy)
Jump to: navigation, search


FAQ: AbiWord Bug Policy, Bugzilla

Some words about AbiWord use of Bugzilla.

You're Not Finished When You File the Bug

When you create a new bug report on Bugzilla, you should be prepared to respond to developer questions in a timely fashion. You should also be willing to help test potential solutions to the problem, and retest if the problem has been fixed in new releases of .

One very common mistake that can result in bug neglect and database uncleanliness is that users update a bug, commenting that it still exists in a more recent version, but forget to update the version field, which developers use to help localize, screen, triage, and otherwise affect bug entries.

It is important that in addition to the comments made, the bug fields (seen in the form at the top of the bugs page) be updated when applicable. For example, an old bug with a version field of many releases ago may turn up on a developers obsolete bugs or probably fixed bugs list even if a comment within the bug entry states that it still exists in the most recent release. Another example, a bug is filed with the OS field of Windows XP, and another user comments that the bug also exists in Linux. In this case, QA personnel who can only localize bugs on Linux will ignore the bug because they think they cannot do anything about it. Had the Linux user updated the OS field to All (because in bugzilla if a bug exists in Windows and Linux, All is a safe assumption), it would have shown up on the QAs bugs to localize on Linux list, probably accelerating the bug towards a fix.

Note that many users are of the mistaken impression that they must not touch a Bug report after initially creating it. That is wrong. The best person to verify that the problem reported in Bugzilla has been fixed is *the reporter*. Dont be shy people, help maintain the Bug database!

You Can Help Even If Its Not Your Bug

_If you are not the original reporter of the bug, but are interested in helping to get it fixed, you can add your email address in the field "Add CC" (under "Reporter"), to get an email cc of updates to the bug report. Thus, if a developer has a question, you might help answer it._

There are many more users of than there are developers, so the developers have to force the users to take on some of the Bug database maintenance. We do this in part by being terse, and by agressively playing the ball back in the Bug reporters court:

Why Your Bug was Closed

... and what to do about it.

Terseness Is Not Rudeness

This terseness may be perceived as rude, but please remember that our time is limited and best spent on stuff that users cannot help with (programming) and is wasted on stuff that users can help with (testing to see if problems have been fixed).

If you feel peeved about this procedure, and think it's obscene that we ask *you* to help us with your problem, please remember that we all give our time freely to development and have to make it stretch to all those who need help. If you desperately want special treatment and are willing to pay for it, post your request for help to the user mailing list (prefix subject with [REWARD]) and, if the offered price is right, someone will be there to hold your hand.

AbiWord Bugzilla Status Progression

Slightly paraphrasing an April 1, 2003 post by Mark Gilbert on the abiword-user list, here is the normal progression of AbiWord bug reports:

Condition Bugzilla Status
Initial bug report UNCONFIRMED
Confirmed by someone else NEW
Developer accepts bug ASSIGNED
Solved and pending verification RESOLVED
Solution verified VERIFIED
Bug rejected (see note) CLOSED

Note: The status "CLOSED" is reserved for use by core developers to describe a bug that, for whatever reason, does not belong in Bugzilla. This means things like testing bugzilla and describing your cats odor, which really have nothing at all to do with AbiWord.

Aside: This is not the progression followed by all open source projects.

Personal tools