defining and revamping our bugzilla categories

[Jan Zerebecki]

On Fri, Oct 12, 2007 at 11:09:53AM -0500, James Hawkins wrote:
> On 10/12/07, Francois Gouget <fgouget at free.fr> wrote:
> > On Thu, 11 Oct 2007, Steven Edwards wrote:

> > One more issue to raise: is the reason why we have 'wine-' as the prefix
> > to avoid conflicts between different products? That is, if we have a
> > 'printing' category in the 'Wine' product, is it going to interfer with
> > the 'printing' category of a 'Wine-doc' product?
> You'd think bugzilla would be more dynamic.  For example, if you
> choose WineHQ.org as the product, then you only get components
> available to that product.  Unfortunately, I don't think it works that
> way.

In bugzilla components are per product (i.e. you can have a
printing component in Wine and Wine-doc and they are two
different ones).

> > [...]
> > > > gdi
> > > > printing
> > [...]
> > > Yes I second this motion. The components should be named as simply as
> > > possible. Users are going to be the ones filing the reports and
> > > whoever is doing triage is going to have to move it around if its in
> > > the wrong area. Abstract names like DirectX, Sound, Graphics,
> > > Installers and Printing are a much better idea than dllnames.
> > [...]
> >
> > Sounds good to me too.
> > But just for the sake of it, I will mention that we have keywords too.
> >
> > So we can have broad categories like 'printing' and 'display', and
> > dll-specific keywords like 'gdi32' and 'comctl32'.
> >
> > Or we can do the opposite and have broad keywords for 'printing' and
> > 'display', and then dll-specific categories.
> >
> > Or we could stay with the current scheme because both of the above may
> > be abuses of the keyword system.
> >
> > Up to you.
> >
> 
> Yea that works too.  I would actually prefer having them as keywords
> and keeping components per dll.  It's been working great for the
> installer keyword, where the components are usually, but not limited
> to, msi, setupapi, advpack.

We also have custom fields. (Currently Difficulty is our only
one.) So we could e.g. have a field where we would put something
like dlls/wined3d/foo.c:bar() to say exactly where the problem is
located if that is known.


Jan