[FusionDev] Bugzilla usage guide

[Kristian Lyngstøl]

As we are creating a QA group on Bugzilla to help verify, close and
properly tag bugs, I threw together a little document on how to deal
with Bugzilla, which is highly relevant for developers too I hope.

Feel free to pick it apart and improve it, this is a first draft, so I
assume it can be heavily improved.

Also, we need to actually populate the QA team (I've got a few
candidates in mind).

Here it is:
-------------------------- GUIDE START -----------------------------

Bugs and how we deal with them

1. Introduction
2. Developers
3. Quality Assurance
4. Targets, severities, priorities and versions


1. Introduction
===============
This is not a user-howto, but for developers and QA personell. The goal is to
maximize the efficiency of the bug tracker.

First, I advice everyone to glance at bugzilla's bug lifespan chart [1]. All
developers and quality assurance personell should have a bugzilla account, and
it should be in the correct group or groups.

Make sure that when you change a component, the assignee is updated correctly.
Bugzilla offers an option to do this for you.

If in doubt, don't just leave a bug, ask around. It never hurts.

2. Developers
=============

Whenever a bug is assigned to a developer, it should not be left as "NEW"
for too long. The developer assigned to it should either accept, close or
reassign the bug. In the cases where bugs are nearly impossible to deal with,
assigning them to the mailinglist [2] can be appropriate, even if you are the
default asignee for that component.

Resolving a bug as "LATER" can and should be used on bugs that are valid, but
will not be possible to solve for quite some time. These should NOT be closed
as INVALID. Setting a milestone and leaving them ASSIGNED is also OK, this is
up to the developer.

Bugs which involve multiple plugins should either be assigned to the
plugin where
the problem is most obvious, then reassigned as it is fixed, or assigned to the
"plugins" component. With such bugs, it would make sense to add either the dev
list or the individual maintainers of the relevant plugins to the CC list.

3. Quality Assurance
====================

The goal of the QA group is to confirm and categorize bugs.

Categorize means putting bugs in the right product and component, and should be
fairly easy. The QA team is obligated to nag on developers who are slow to act
on bugs, to make sure our bug database doesn't go stale. While deciding the fate
of the bug is eventually the developer's decision, making sure a decision is
reached at all, a resolution is found and that it is acceptable, is what
quality assurance means.

Confirming bugs means going over bugs marked "resolved", reading over why it
was marked resolved and making sure it is in fact resolved, and that the fix
is valid, and good.

This might mean contacting the developer who resolved it, or testing the fix.
For a fix involving patches, this should be fairly straight forward. If the QA
member could reproduce the issue prior to the patch, and can no longer reproduce
it, it is confirmed.

If the QA member couldn't reproduce it prior to the patch, user confirmation
will be needed, either in the bug list, or the QA can contact the user who had
the issue. If the issue seems resolved and no confirmation is received within 1
month, the issue can be closed (not confirmed).

In clear cut cases of trivial patches, the developer might close the issue.
More complex patches should be verified. Examples of trivial patches can be
adding error checks, white space and style fixes, comment updates, small code
simplifications, and similar. For larger patches where there is no simple way
to verify the patch, closing it immediately can also make sense, as leaving it
in the "resolved" queue wouldn't do any good.

4. Targets, severities, priorities and versions
===============================================
Targets are milestones, and should be used to organize and plan releases. Having
a milestone on brand new bugs is not necesarry, but if a bug has existed for a
while, one should be added to make sure the bug is dealt with.

Severeties should be set to "normal" for almost all bugs. Severeity is affected
by the number of users affected, and what it means to them. If a tiny fraction
of users have an issue leaving a plugin useless, that does NOT warrant a "block"
or "critical" severity.

Blockers are only when it is impossible to test and use compiz for the majority
of users. These should hardly even be seen in the database, because when such
bugs occur, everyone, including developers, should notice them and be forced to
fix them immedialtely. Blockers renders a component completly useless, and the
only way to use Compiz Fusion when a blocker exist, is to not use the component.

Critical bugs are similar. They render the component useless for the majority of
users. An example can be cube/rotate where you are able to use the desktop,
maybe even switch viewports, but the animation is completely garbaged
and leaves trails after grabbing the cube (an example).

As for the rest, common sense should be applied. Developers and QA personell
should be the ones to decide if the severity should be upgraded or downgraded.

Priority can be used by bussy developers, or to sort unassigned (dev-list) bugs
so others can see them. The usefullness of this can be discussed, but for
feature requests this can make a whole lot of sense.

Versions should describe themselfs. The user should supply this, and it comments
should describe why it is changed. (i.e: "I noticed this on current git head as
of 20070814, so it's not just a 0.5.2 issue").

[1] http://www.bugzilla.org/docs/3.0/html/lifecycle.html
[2] http://lists.compiz-fusion.org/mailman/listinfo/dev

-------------------------- GUIDE END -----------------------------

Looks sane?

-- 
Regards,
Kristian