NEEDINFO Bugzilla keyword now available - Was: Re: [Headsup]: Bugzilla Upgrade Scheduled for 20070111

Benjamin Close Benjamin.Close at clearchain.com
Tue Jan 22 03:23:56 PST 2008


Jin, Gordon wrote:
> <snip>
> Benjamin, can we have a decision on what it will go for?
>
> Some existing proposals:
> a. add NEEDINFO back as "resolution" field.
> b. use NEEDINFO as flag
> c. use NEEDINFO as keyword
> d. use NEEDINFO as "whiteboard status" field (suggested by Jojo, though
> I don't know what's this)
> e. do nothing. 
>   
Hi Folks,
    Thanks for your patients in this, I was only looking into this 
earlier today and think I've found a solution that works - sort of.
The background behind NEEDINFO disappearing is due to Mozilla removing 
it in v3.0.0 version of bugzilla. Their reasoning is to force 
accountability of every bug. Ie: a bug is always assigned to someone.

Since we run a stock standard bugzilla we found out about the removal 
the hard way. From an admin point of view I'd prefer not to modify 
bugzilla as changes get lost or need to be reimplemented each time bz is 
upgraded.

However, after watching how ppl in freedesktop.org work, it's clear we 
do need something so option (e) is out.
I think implementing NEEDINFO as a keyworks is the best option for now 
and hence I've now added:

NEEDINFO

as a keyword. To get a list of all the bugs without the keyword sadly an 
advanced search (https://bugs.freedesktop.org/query.cgi?format=advanced)
is needed. If you don't want to figure out the advanced search simply add:

&keywords_type=nowords&keywords=NEEDINFO

to any search url and you'll get the relevant bugs removed - you can 
then save that as a custom search.

For the reasoning as to why use a keyword, see below.

> Some existing proposals:
> a. add NEEDINFO back as "resolution" field.
>   
This option isn't viable as resolutions remove the bug from the open 
lists and places it in the resolved list. Hence standard search for open 
bugs wouldn't show up the bug. Bugs in this state would be end up 
becoming lost/stale as the committer often wouldn't change the 
resolution back to new/reopen.

Bugzilla 3.2 adds custom status fields [1] though 3.2 isn't stable yet 
and we've just upgraded to 3.0.3 which is stable.
> b. use NEEDINFO as flag
>   
[2] Indicates a flag for the use of NEEDINFO and discusses the pro's 
cons to using one. Briefly:
    o Pros:
       o Can set need info flag to multiple ppl and keep assignee the 
same  
       o Can search based on STATE & flag
    o Con
       o Flag won't be used correctly as ppl don't know how to use flags
       o Needs custom search
> c. use NEEDINFO as keyword
>   
The eclipse bugzilla opted for a keyword [3]. For needinfo. This has the 
following pros/cons:
    o Pros:
       o Easy to use
       o Can search on keyword
       o Bug remains in open state
    o Cons:
       o Needs custom search to remove 'needinfo' type keyword bugs
       o Keyword can be left when closing the bug (not a major issue)
> d. use NEEDINFO as "whiteboard status" field (suggested by Jojo, though
> I don't know what's this)
>   
The 'whiteboard status' field is on every bug (Look for 'whiteboard' 
just above the keyword field).
This is basically a free text field that allows anything to be added. 
This has the same pros /cons as the keyword field. But an very important 
additional con:
    o People can mispell 'NEEDINFO' and this means that some bugs will 
be lost, marked incorrectly.
> e. do nothing. 
e)  Is not a viable solution.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=101179
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=136107
[3] http://dev.eclipse.org/mhonarc/lists/wtp-dev/msg05217.html



More information about the xorg mailing list