Fedora bug triage - workflow proposal

Matej Cepl mcepl at redhat.com
Tue Jan 15 22:59:49 UTC 2008


On 2008-01-15, 04:46 GMT, Jon Stanley wrote:
> 6)  When the update is pushed to stable, Bodhi optionally 
> closes the bug automatically.  If the update does not 
> auto-close the bug, it transitions to NEEDINFO_REPORTER, with 
> a comment explaining that the update has been pushed to stable, 
> and to update and test in the new release.

Hello,

(just for those who don't know it already) I am a bugmaster (or 
bug triager, if you wish) of the desktop team. I think that this 
proposal is pretty sane, so I have just a little nitpicking 
comments (nitpicking is a substance of bugmaster's work ;-)).

(so the really nitpicking is that there is no NEEDINFO_REPORTER, 
but only regular NEEDINFO targeted towards reporter).

> It was also decided that when a bug is in NEEDINFO for one 
> month, it will be closed.  Maintainers would need to realize 
> that putting a bug in NEEDINFO is putting it on the fast track 
> for closure.

Although I think I am pretty tough on both reporters and 
developers in this regard (and I get flamed all the time for bugs 
I closed because somebody hasn't bothered to answer the request 
for information in half-a-year), I would never subscribe to so 
draconical policy as this.

The sad state of life is that all NEEDINFO bugs need to be
followed manually (there are some tools which can help -- about
which later):

a) Bugzilla is not reliable in changing from NEEDINFO -- some
   problems are cause by bugs in bugzilla (e.g., attachments
   don't count), but sometime it is error of some human.
b) On the other hand, there many bugs which are not in NEEDINFO
   even though they should be. For example quite often the
   message which bugzilla counts as an answer to originally
   request is something like "Sorry, that I cannot answer now, I
   will get to my office computer only after Christmas" (I met
   plenty of them in December). So, a bug triager should see such
   message and just switch the bug back to NEEDINFO without much
   ado.
c) Sometimes emails are just not enough reliable -- somebody
   deletes email by mistake, it gets filtered somewhere, SA is
   too active, etc. One more kick is worthy especially when it is
   low cost (we have to see those bugs anyway).
d) The last argument which I hear quite often is just a
   fundamental fairness -- we have bugs in bugzilla opened as NEW
   even for years and now we are closing reporters' bugs after a
   month? Yes, exactly by more draconical measures we won't to
   make our bugzilla more functional, but we are not there yet
   and we won't be for some time, it is huge amount of work we
   need to do.
e) there are some other arguments but I am too sleep deprived to
   remember them now. ;-)

So, what I propose is that at least somebody has to see all
obsolete NEEDINFOs before they are closed. I would love to see
people actually following all bugmail for particular component or
sets of components and fixing the goo reporters (and developers)
leave in bugzilla, but that's probably too demanding for
non-professional bug triagers.

Concerning tools, I use for my bugs this search
https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed\
&namedcmd=old%20NEEDINFO%202&namedowner=mcepl%40redhat.com

(run this search, then click on "Edit search" in the results,
change the set of packages you follow, run the search again, and
save it to your preferred searches just next to search which
finds all NEW bugs in your components).

It is probably the best what we can get (if somebody has any
ideas how to make this more reliable just go ahead), and it can
be pretty easily screwed up -- when somebody decides that it
needs to touch all bugs in bugzilla (for example, because of
renaming and renumbering products -- happened in December), this
searches gets out of whack and reports obsolete NEEDINFO a month
later -- all 175 of them at once (in my case ;-)). However,
modulo these bugs it is pretty useful.

Another useful thing (at least useful for me) are these
Greasemonkey scripts, available at fedorapeople.org. Get them by
running

git clone http://mcepl.fedorapeople.org/repo/greasemonkey.git

and install them as any other Greasemonkey script (if you were
living under a rock for the past four or so years, and you don't
know what Greasemonkey is go to
http://en.wikipedia.org/wiki/Greasemonkey and enlighten
yourself).

It will create couple of useful (and less useful for you) buttons
in every webpage you visit. Patches are welcome. I will probably
reorganize the scripts to those which are just for my personal
use and those which could be used by others (however, I am afraid
that some customization will be necessary always -- these scripts
are just too desktop-centric; which means also that there will
never be a package of this script).

Comments?

Matěj




More information about the fedora-devel-list mailing list