Re: Bugzilla outstanding issues

[Maciej Stachowiak <mjs eazel com>]

Martin Baulig <martin home-of-linux org> writes:

> 4.) Keywords
> 
>     It's easy to add new keywords, but more difficult to remove them
>     later, so which keywords do we want to have ?

I suggest leaving out the keyword field entirely unless we are certain
there are keywords that are so important enough to have to oughtweigh
the cost of having an extra field. I don't think any of the ones below
fall in that category.

>     I'd suggest the following list:
> 
>         trash   - Bug report was closed because it was crap/useless etc.,
>                   set this keyword to distinguish it from other closed
>                   bug reports so we can exclude them in queries
> 
>         debbugs - Bug was imported from the old bug-tracker, my script will
>                   set this - useful to let developers exclude such bugs if
>                   they don't want to deal with them (most of them are crap
>                   anyways)
> 
>         helpwanted - Developer is looking for someone to help him with this
>                      bug report, for instance because he don't have time or
>                      he's unable to fix it himself
> 
>         discussion - Bug involves changing/adding a feature which needs some
>                      discussion or developer is asking for discussion about
>                      this bug; this can be quite useful to let other developers
>                      quickly search for such "bugs", can also be used for
>                      todo lists, feature suggestions etc.
> 
>         frequently-reported - This keyword should only be set by the maintainer
>             and is useful when we get a very large number of duplicates. In this
>             case the maintainer files a bug report with the most info he can get
>             about the problem, including a soulution how to fix the problem,
>             marks it as "frequently-reported" and marks all other bugs as
>             duplicates of this one.
> 
>             This is intended mostly for users: they can easily browse the list
>             of frequently reported bugs to quickly find the solution of their
>             problem if it is already known (I mean, if such a bug is already
>             fixed, but some user still has the problem, he can use this keyword
>             to search for a solution of his problem). 


> 5.) Products / Components / Versions
> 
>     I think this should be up to the maintainers of a package - ie. each
>     maintainer of a package should create a product and individual components
>     for his package and also decide which version numbers he wants to have.
> 
>     However, we may need a `general' component for each product to make debbugs
>     importing work if the user did not specify a component.
> 

Is there any way we can enable setting milestones per-product?

 - Maciej