On Fri, Oct 12, 2007 at 11:09:53AM -0500, James Hawkins wrote: > On 10/12/07, Francois Gouget <[EMAIL PROTECTED]> 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
