This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: Using flags in bugzilla


RFC: Using flags in bugzilla
============================

At present the glibc bugzilla has 3 flags.

In this post I look at the current flags, if they make sense for our
day-to-day glibc work, and make some recommendations.

Background
==========

A flag is a 4-valued field, that can potentially be applied multiple times.

In general flags can have the following values.

* granted or "+"
* denied or "-"
* requested or "?"
* undefined or " "

When a flag is set to "?" a user may be specified in the optional
field. When the bug is saved the user is sent a request via email and
the request appears in their "My Requests" list in bugzilla.

Example email of setting "exmained" to "carlos@systemhalted.org"
~~~
Carlos O'Donell <carlos@systemhalted.org> has asked Carlos O'Donell
<carlos@systemhalted.org> for examined:
Bug 13780: Testing flags.
http://sourceware.org/bugzilla/show_bug.cgi?id=13780
~~~

This way the flag can request actions from other developers or users.

Current Flag Recommendations
============================

The current flags configured with the glibc product are as follows:

* backport
* examined
* testsuite

The three flags are currently configured to only apply *once* to an
issue. It is configurable if a flag applies once or can be applied
more than once.

(1) backport.

The flag help says:
~~~
This bug has been fixed in the trunk code and remains open to track
its being backported to a stable branch.
~~~

The flag doesn't indicate to which stable branch the backport applies.

I recommend we remove this flag and continue to use keywords to track
backport requests.

It's easier to search for keyword=glibc_2.15 to find all the backport
requests, than it is to search for backport=+ and then read through
all the issues to determine which branch it applies to.

We might conceivably maintain multiple stable branches in the future
and it's important to know and easily find backport requests in the
bugzilla.

(2) examined

The flag help says:
~~~
This flag indicates that this bug has bene[sic] examined after
2006-2-5 and its state says something useful.
~~~

This flag has something to do with a previous triage of the bug
database in 2006.

I recommend we remove this flag and use "Last Reconfirmed" or "Ever
confirmed" date-based values to tag issues with this class of
information.

Using "Last Reconfirmed" and the greater than/less than search queries
allows you to build very accurate reports about when groups of bugs
were last seen.

(3) testsuite

The flag help says:
~~~
This bug has a test case in the proper form using test-skeleton.c,
ready to go into the libc sources.
~~~

The presence or absence of a test can be easily tracked with a keyword
"testsuite."

The use of a multi-valued flag with a requestable property is overkill.

I recommend we remove the testsuite flag.

Flags vs. Keywords
==================

The down side of using keywords is that untrained users aren't
immediately able to tag an issue themselves. In practice though I have
found that only a dedicated triage team makes use of these kinds of
features, and keywords easier to enter in with a keyboard.

New Flag Recommendations
========================

(a) review

I recommend we create a "review" flag that can be set multiple times
on an issue.

I propose we use this flag to allow someone doing triage to request
the help of reviewer familiar with some aspect of the bug.

The "review" flag is a more formal CC'ing or ping-ing of a developer
to review a particular issue.

Review requests generate emails to the requested user (as described
above in "Background").

They also show up under "My Requests" in bugzilla.

e.g.

Flag: review
Requester 	Requestee 	Bug 	Attachment 	Created
Carlos O'Donell <carlos@systemhalted.org> 	Carlos O'Donell
<carlos@systemhalted.org> 	13780: Testing flags. 	N/A 	2012-02-28
04:31 UTC
(view as bug list)

When a review is positive about the patch or issue the reviewer can
set a "+", or if they don't approve a "-", leaving the issue with a
record.

e.g.
carlos: review +
user2: review +
user3: review -

Given the complexity of some of the things we work on in glibc it
would be useful to track review of some issues more formally.

A reviewer can always remove themselves from review by clearing the
flag and saying so in the issue "I don't have time to review. Sorry."

Comments?

Note: Owing to, what appears to be a bug in bugzilla, there is now a
"review" flag in the tracker, but editing it or removing it causes an
internal error in bugzilla. I have contacted overseers@sourceware.org
about this (it might have to do with the fact that I created the flag,
deleted it, and then re-created it).

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]