Use of assignments in Bugzilla

[Carlos O'Donell]

On Fri, Feb 17, 2012 at 9:16 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> In the course of triaging and fixing open glibc bugs - something that
> could certainly do with more people working on it - it's become clear that
> the vast bulk of bugs in glibc Bugzilla are "assigned" to someone who is
> neither working on them nor has any intention of working on them any time
> soon.
>
> I've generally removed those misleading assignments when reviewing a bug -
> that is, reassigned to unassigned@sourceware.org (much the same as GCC
> bugs default to being assigned to unassigned@gcc.gnu.org, since Bugzilla
> seems to want *something* in the assigned-to field).  I propose that we
> adopt an understanding of the assigned-to information as follows:
>
> * A bug being assigned to someone indicates that have an intention to work
> on a fix in the reasonably near future.

Agreed.

> * If a bug is also ASSIGNED (rather than NEW), that indicates the person
> is actively working on a fix.

Agreed.

> * If you simply think someone will be interested in a bug, CC rather than
> assigning them unless they have specifically asked to be assigned.

Agreed.

> * Components should no longer have bugs default-assigned to particular
> individuals (that is, unassigned@sourceware.org should be the default
> assignment); rather, people should choose when to assign bugs to
> themselves when they have some specific intention with regard to a
> specific bug.  (Note I don't have the Bugzilla powers to make such a
> configuration change.)

Agreed.

> * The default-assignments should be removed from existing open bugs.
> Rather than just removing them all blindly, it's better actually to look
> at a bug enough to decide you think it is a real issue still present in
> the current code, but that you're not going to fix it right now, and to
> decide if it's in the correct component, if possible, and to remove the
> assignment at the same time as making any comment you wish to make on the
> bug.  (That is, removing default assignments is better done as part of
> triage than separately touching each bug for both purposes.)

Agreed. There should be no blanket default-assignment fixup. We need
to work through the bugs and make sure they are still valid and ping
the assigned developer.

I'll fix the default assignment issue as I add new glibc product components.

Cheers,
Carlos.