Bugzilla administration policies

[James Hawkins]

Hi,

I really appreciate the effort everyone has put into cleaning out the
old bugs in our bugzilla recently; however, I do have an issue with
the way we're closing some of the bug reports.  The ultimate outcome
of wine is to enable a user to run windows apps just as they would in
windows, so if a user has to run the app with a native dll or follow
special instructions to make it work, then there is a bug in wine that
needs to be fixed.  Quite a few bugs have been closed recently
referring the user to the instructions in the AppDB or to a list of
dll overrides that makes the app work.  Recommending a dll override
can be useful to the end user as a temporary workaround, but the bug
hasn't been fixed.  Cleaning out the bugzilla is well appreciated, but
we must keep up due diligence in order to keep wine's bugzilla as a
reliable status of wine's bugs.  I offer this as the beginning of a
discussion of bugzilla administration policies.  Any thoughts,
comments, and ideas are welcome.

--
James Hawkins

[Dan Kegel]

On 10/9/05, James Hawkins  wrote:
> Quite a few bugs have been closed recently
> referring the user to the instructions in the AppDB or to a list of
> dll overrides that makes the app work.  Recommending a dll override
> can be useful to the end user as a temporary workaround, but the bug
> hasn't been fixed.

Good point.  Got a few examples bug numbers that were resolved like that?

[Richard Cohen]

Dan Kegel wrote:
> Good point.  Got a few examples bug numbers that were resolved like that?

See http://bugs.winehq.org/show_bug.cgi?id=2858

I recently resolved a lot of whiskery old bugs, essentially "IE6 
installer fails",
with directions to the AppDB, because it fixes the user's problem, and 
IE6 will install the DLLs it needs.

But http://bugs.winehq.org/show_bug.cgi?id=587
"Create replacement of browser component (Internet Explorer/IE)" remains 
open.

Richard.

[Dan Kegel]

On 10/10/05, Richard Cohen  wrote:
> See http://bugs.winehq.org/show_bug.cgi?id=2858
>
> I recently resolved a lot of whiskery old bugs, essentially "IE6
> installer fails",
> with directions to the AppDB, because it fixes the user's problem, and
> IE6 will install the DLLs it needs.

Marking the other bugs as duplicates of 2858 was probably fine,
but I think we ought to leave 2858 open, or if we do not plan to
fix it, mark it "WILLNOTFIX" rather than "FIXED".  The instructions in the
appdb are arguably a workaround rather than a fix.
> But http://bugs.winehq.org/show_bug.cgi?id=587
> "Create replacement of browser component (Internet Explorer/IE)" remains
> open.

That's fine; I think "IE not installing" is a separate issue.

[Richard Cohen]

Dan Kegel wrote:
> Marking the other bugs as duplicates of 2858 was probably fine,
> but I think we ought to leave 2858 open, or if we do not plan to
> fix it, mark it "WILLNOTFIX" rather than "FIXED".  The instructions in the
> appdb are arguably a workaround rather than a fix.

I'm happy to do either, but I think it's probably better to keep it open.

Richard.

[James Hawkins]

On 10/10/05, Richard Cohen  wrote:
> Dan Kegel wrote:
> > Good point.  Got a few examples bug numbers that were resolved like that?
>
> See http://bugs.winehq.org/show_bug.cgi?id=2858
>
> I recently resolved a lot of whiskery old bugs, essentially "IE6
> installer fails",
> with directions to the AppDB, because it fixes the user's problem, and
> IE6 will install the DLLs it needs.
>
> But http://bugs.winehq.org/show_bug.cgi?id=587
> "Create replacement of browser component (Internet Explorer/IE)" remains
> open.

Here is a list of bugs you recently resolved:

2066: IE6 fails to download the mirror list
2945: IE6 installer hangs after a while
3120: Using certain native dlls, IE6 crashes
1293: IE6 setup cannot download setup files
2308: IE6 setup requests all windows be closed..cannot continue
2711: IE6 cannot start because of an unimplemented shdocvw function
2268: Problem with ntdll file api when installing microsoft products

All of the above bugs are marked as duplicates of 2858 (IE6 SP1 fails
to install).  While most of the above bugs fall under the category of
not being able to install IE6, they are individual bugs that need to
be addressed, but because 2858 was resolved as FIXED, all of these are
now "fixed" when they are more than likely still not fixed.  Marking
2858 itself as fixed is an error in that there is no way to install
IE6 without using native dlls or special instructions.  All of these
bugs need to be reopened (including 2858) and marked as blockers of
the meta-bug "IE6 fails to install".  It's fine to point the users to
workarounds in the bugzilla or the wiki, but we can't mark the bugs as
fixed just because we have a workaround.

--
James Hawkins

[Richard Cohen]

James Hawkins wrote:
All of these
> bugs need to be reopened (including 2858) and marked as blockers of
> the meta-bug "IE6 fails to install".

Reopening them is pointless, because most of them are so old that 
ie6setup does not fail in that way anymore. So they would be resolved as 
fixed until we're left with just one - "IE6 fails to install with the 
current release".

Metabugs are generally a bad idea because they are very hard to 
maintain. What is the point of "Get games working perfectly", and how 
can it ever be resolved?

Richard.

[James Hawkins]

On 10/10/05, Richard Cohen  wrote:
> James Hawkins wrote:
> All of these
> > bugs need to be reopened (including 2858) and marked as blockers of
> > the meta-bug "IE6 fails to install".
>
> Reopening them is pointless, because most of them are so old that
> ie6setup does not fail in that way anymore. So they would be resolved as
> fixed until we're left with just one - "IE6 fails to install with the
> current release".

The point is you don't know if they're fixed or not.  We resolve these
bugs as we would any other bug.  We ask for feedback and if they don't
respond after a certain amount of time we resolve it abandoned.  They
aren't duplicates and we don't know whether they are fixed or not, so
those two resolutions are invalid.  Bug 1293 is a good example of a
bug that is still not fixed.  IE6 setup consistently fails to download
the setup files.  Keeping the bug open provides incentive and
information for someone to fix it.
> Metabugs are generally a bad idea because they are very hard to
> maintain. What is the point of "Get games working perfectly", and how
> can it ever be resolved?

Of course metabugs for really ambiguous topics like "Get games working
perfectly" is a bad idea.  The bug means nothing and could include
hundreds of bug reports.  "IE6 fails to install" is a specific problem
with wine that has at least 7 specific bugs causing the failure.  When
IE6 installs correctly without workarounds, then the bug has been
resolved.  Abuse of metabugs in the past shouldn't stop us from using
them now.

--
James Hawkins

[Molle Bestefich]

Richard Cohen wrote:
> Metabugs are generally a bad idea because they are very hard to
> maintain. What is the point of "Get games working perfectly", and how
> can it ever be resolved?

Who said it needs to be resolved, ever, or in any kind of near future?

I see metabugs more as a categorization feature.
If you want an overview of all games that fail in Wine, go check out
that particular entry.

I'd like to see metabugs for each DLL or larger area, for instance
"Window painting in Wine".  I can see a number of bugs that would fit
that metabug, and I think it might make it easier for some people to
see when a particular area of Wine is mature enough for release (in an
easy to administrate manner).  There's probably other bonuses from
keeping the bugzilla well categorized.

I would also like to see a "blockers for 1.0" metabug, which I would
*very* much like to contain the "window painting in wine" metabug
:-)..

Then again, I may be way off, I'm totally newbie.

[Francois Gouget]

On Mon, 10 Oct 2005, Molle Bestefich wrote:
> Richard Cohen wrote:
> > Metabugs are generally a bad idea because they are very hard to
> > maintain. What is the point of "Get games working perfectly", and how
> > can it ever be resolved?
>
> Who said it needs to be resolved, ever, or in any kind of near future?
>
> I see metabugs more as a categorization feature.
> If you want an overview of all games that fail in Wine, go check out
> that particular entry.

Maybe this could be better done with the use of keywords. for instance 
we could have a 'game' keyword. Then one would find all these bugs by 
querying for bugs with the 'game' keyword.
> I'd like to see metabugs for each DLL or larger area, for instance 
> "Window painting in Wine".

I'm not sure about 'Window painting in Wine', but we could have one 
keyword per dll. Then once a bug is disgnosed down to a specific dll, 
the relevant keyword would be added. This would let developpers with 
specific knowledge of a given dll look for bugs in their domain. This 
would also make the keyword list more intuitive and simpler to maintain.

One issue with using keywords is that currently it seems one needs 
special privileges to set them. But this is more a policy issue than a 
technical one and it can probably be resolved quite easily.

[James Hawkins]

On 10/10/05, Francois Gouget  wrote:
> > I'd like to see metabugs for each DLL or larger area, for instance
> > "Window painting in Wine".
>
> I'm not sure about 'Window painting in Wine', but we could have one
> keyword per dll. Then once a bug is disgnosed down to a specific dll,
> the relevant keyword would be added. This would let developpers with
> specific knowledge of a given dll look for bugs in their domain. This
> would also make the keyword list more intuitive and simpler to maintain.

I agree we should have a either a keyword per dll or a component per
dll.  If I decide to work on shell32 bugs, querying bugzilla for
shell32 should return all shell32 bugs.  Just searching comments or
summary doesn't always catch them, because the reporter might not know
that shell32 is the cause of the problem.  We're pretty close to this
system already with components like wine-ole, wine-richedit,
wine-shdocvw etc, so taking the extra step would be very benificial.

--
James Hawkins

[Tony Lambregts]

Francois Gouget wrote:
> On Mon, 10 Oct 2005, Molle Bestefich wrote:
> > Richard Cohen wrote:
> > > Metabugs are generally a bad idea because they are very hard to
> > > maintain. What is the point of "Get games working perfectly", and how
> > > can it ever be resolved?
> >
> > Who said it needs to be resolved, ever, or in any kind of near future?
> >
> > I see metabugs more as a categorization feature.
> > If you want an overview of all games that fail in Wine, go check out
> > that particular entry.

I can see adding a game keyword.
> Maybe this could be better done with the use of keywords. for instance 
> we could have a 'game' keyword. Then one would find all these bugs by 
> querying for bugs with the 'game' keyword.
> > I'd like to see metabugs for each DLL or larger area, for instance 
> > "Window painting in Wine".
>
> I'm not sure about 'Window painting in Wine', but we could have one 
> keyword per dll. Then once a bug is disgnosed down to a specific dll, 
> the relevant keyword would be added. This would let developpers with 
> specific knowledge of a given dll look for bugs in their domain. This 
> would also make the keyword list more intuitive and simpler to maintain.

Isn't it this what component is for. Currently I know that if it is an MSI bug I 
set the component to wine-msi and that way Mike McCormack can find them easily. 
The big difference between keywords and components is each bug can only have one 
component but many keywords.

Bugzilla also has the ability to have component owners but we do not use them so 
far. Right now the owner of all components is [e-mail] so this 
difference is moot at this time.
> One issue with using keywords is that currently it seems one needs 
> special privileges to set them. But this is more a policy issue than a 
> technical one and it can probably be resolved quite easily.

You do not need special rights to set existing keywords in a bug. However adding 
new keywords is a special function (which not everyone has) and so is adding new 
components.

Anyone who wants a new keyword or component added to bugzilla can contact me and 
if it is obvious there is a need for it I will add it otherwise I will open a 
discussion here.

Tony Lambregts

[Francois Gouget]

On Mon, 10 Oct 2005, Tony Lambregts wrote:
[...]
> > I'm not sure about 'Window painting in Wine', but we could have one keyword 
> > per dll. Then once a bug is disgnosed down to a specific dll, the relevant 
> > keyword would be added. This would let developpers with specific knowledge 
> > of a given dll look for bugs in their domain. This would also make the 
> > keyword list more intuitive and simpler to maintain.
>
> Isn't it this what component is for. Currently I know that if it is an MSI 
> bug I set the component to wine-msi and that way Mike McCormack can find them 
> easily.

Yes, you're right of course. I had forgotten about 'components'.
> The big difference between keywords and components is each bug can 
> only have one component but many keywords.

Yes, but each bug probably corresponds to only one component so 
that should be ok.

Then there's the granularity issue, i.e. currently there is not a one to 
one mapping between dlls and components. IIRC the rationale was that 
having one component per dll was too fine grained and that users would 
not know what component to put. But I would argue that most of the time 
users have no idea what component to put anyway. They're prone to take 
their cue from the first trace in the log and select the component based 
on that even though the bug is in fact a stack overflow for instance, 
and thus completely unrelated. So IMHO we have to rely on our Bugzilla 
maintainers to assign meaningful components to bugs anyway and then they 
would know exactly which one to use.

But then having exactly one component per dll means a RichEdit 
specialist would have to query for riched32 or richedit20, a network 
specialist for wsock32, ws2_32 or winsock, etc. So maybe having one 
component per dll is too fine grained after all. But then in the latter 
example does the 'wine-net' component include wininet or not? It's the 
kind of ambiguity that having one component per dll would avoid. Also it 
would make remembering the component names easier (is it network, 
wine-net, wine-network?), though I admit that with a list to pick from 
this point is probably moot.

So these are my thoughts and they probably don't help very much<g>.
> > One issue with using keywords is that currently it seems one needs special 
> > privileges to set them. But this is more a policy issue than a technical 
> > one and it can probably be resolved quite easily.
>
> You do not need special rights to set existing keywords in a bug. However 
> adding new keywords is a special function (which not everyone has) and so is 
> adding new components.

Ok, I was wrong then. That sounds perfect.

[Tony Lambregts]

Francois Gouget wrote:
> On Mon, 10 Oct 2005, Tony Lambregts wrote:
> [...]
> > > I'm not sure about 'Window painting in Wine', but we could have one 
> > > keyword per dll. Then once a bug is disgnosed down to a specific 
> > > dll, the relevant keyword would be added. This would let developpers 
> > > with specific knowledge of a given dll look for bugs in their 
> > > domain. This would also make the keyword list more intuitive and 
> > > simpler to maintain.
> >
> > Isn't it this what component is for. Currently I know that if it is 
> > an MSI bug I set the component to wine-msi and that way Mike 
> > McCormack can find them easily.
>
> Yes, you're right of course. I had forgotten about 'components'.
> > The big difference between keywords and components is each bug can 
> > only have one component but many keywords.
>
> Yes, but each bug probably corresponds to only one component so that 
> should be ok.
>
> Then there's the granularity issue, i.e. currently there is not a one 
> to one mapping between dlls and components. IIRC the rationale was 
> that having one component per dll was too fine grained and that users 
> would not know what component to put. But I would argue that most of 
> the time users have no idea what component to put anyway. They're 
> prone to take their cue from the first trace in the log and select the 
> component based on that even though the bug is in fact a stack 
> overflow for instance, and thus completely unrelated. So IMHO we have 
> to rely on our Bugzilla maintainers to assign meaningful components to 
> bugs anyway and then they would know exactly which one to use.
>
> But then having exactly one component per dll means a RichEdit 
> specialist would have to query for riched32 or richedit20, a network 
> specialist for wsock32, ws2_32 or winsock, etc. So maybe having one 
> component per dll is too fine grained after all. But then in the 
> latter example does the 'wine-net' component include wininet or not? 
> It's the kind of ambiguity that having one component per dll would 
> avoid. Also it would make remembering the component names easier (is 
> it network, wine-net, wine-network?), though I admit that with a list 
> to pick from this point is probably moot.
>
> So these are my thoughts and they probably don't help very much<g>.

Well listing the dlls involved with each commponent in the description
at least would be an idea . This is the list of components we currently
have:

test                 Test Component
wine-binary          Low level environment, thunking, calling
conventions, addressing
wine-console         Console mode, TTY driver
wine-debug           Builtin debugger, trace messages, debugging interface
wine-directx         Obsolete (Use individualized components)
wine-directx-d3d     New DirectX code >= dx8
wine-directx-ddraw   Old DirectX code < dx8
wine-directx-dinput  DirectX DInput
wine-directx-dmusic  DirectX Music
wine-directx-dplay   DirectX DPlay
wine-directx-dshow   Direct X DShow
wine-directx-dsound  DirectX sound
wine-documentation   Wine documentation
wine-dos             DOS support, INT n calls
wine-files           Filesystem interaction
wine-gdi-(printing)  Drawing, graphics, fonts, drivers
wine-gui             Controls, dialogs, shell
wine-help            Basic support or configuration request
wine-ipc             Communication between Wine processes or app
tasks/processes/threads
wine-kernel          Memory management, tasks, processes and threads,
synchronization, exception handling, VxD drivers
wine-loader          The NE, PE and MZ program loaders
wine-misc            Unknown, uncategorized, or app-specific problem
wine-msi             Microsoft Installer
wine-multimedia      MCI; Audio (wave, mciwave, msacm, midi) and video
(vfw, mciavi); mixer, timers, and joystick
wine-net             Networking, winsock
wine-ole             OLE, Active X
wine-patches         Report consisting solely of a patch
wine-ports           OS specific issues, portability, hardware emulation
wine-programs        Winelib programs shipped with Wine
wine-resources       Wrc, resource handling, faulty system resources
wine-richedit        bugs with richedit control
wine-shdocvw         Shell Doc Object and Control Library (internet
browser interface for basic file and networking operations)
wine-tools           Subsidiary tools (except wrc)
wine-user            Events, messages, window handling
wine-winelib         Winelib issues
wine-x11driver       Bugs about problems with Wine X11 driver.

and these are the directories we have under dlls

activeds
advapi32
advpack
amstream
atl
avicap32
avifil32
cabinet
capi2032
cards,
cfgmgr32
comcat
comctl32
commdlg
crtdll
crypt32
cryptdll
ctl3d
d3d8
d3d9
d3dim
d3drm
d3dx8
d3dxof
dbghelp
dciman32
ddraw
devenum
dinput
dinput8
dmband,
dmcompos
dmime
dmloader
dmscript
dmstyle
dmsynth
dmusic
dmusic32
dplay
dplayx
dpnet
dpnhpast
dsound
dswave
dxdiagn
dxerr8
dxerr9
dxguid
gdi
glu32
glut32
iccvid
icmp
ifsmgr.vxd
imagehlp
imm32
iphlpapi
itss
kernel
lzexpand
mapi32
mciavi32
mcicda
mciseq
midimap
mlang
mpr
msacm
mscms
msdmo
mshtml
msi
msimg32
msisys
msnet32
msrle32
msvcrt
msvcrt20
msvcrt40
msvcrtd
msvidc32
msvideo
mswsock
msxml3
netapi32
newdev
ntdll
objsel
odbc32
odbccp32
ole32
oleacc
oleaut32
olecli
oledlg
olepro32
olesvr
opengl32
powrprof
psapi
qcap
quartz
rasapi32
riched20
richedit
rpcrt4
rsabase
rsaenh
secur32
sensapi,
serialui
setupapi
shdocvw
shell32
shfolder
shlwapi
snmpapi
sti
strmiids
tapi32
ttydrv
twain
unicows
url
urlmon
user
usp10
uuid
uxtheme
vdmdbg
version
win32s
winaspi,
winecrt0
wined3d
winedos
wineps
wininet
winmm
winnls
winsock
winspool
wintab32
wintrust
wldap32
wow32
wsock32
wtsapi32
x11drv

I can try to list the correct dll under each category but I am going to
need som help somewhere along the line. Some are obvious to me but
others make my head hum...

If it is worth while I am certainly willing to do it.

--

Tony Lambregts.

[James Hawkins]

On 10/12/05, Tony Lambregts  wrote:
> I can try to list the correct dll under each category but I am going to
> need som help somewhere along the line. Some are obvious to me but
> others make my head hum...
>
> If it is worth while I am certainly willing to do it.

I think what Francois and I were proposing is one component (or
keyword) per dll for finer-grained control.  I don't think it would be
very useful to list the dlls under the categories we have already,
because the categories are too broad, though I do appreciate the
effort you are putting into it.

--
James Hawkins

[Molle Bestefich]

Francois Gouget wrote:
> Molle Bestefich wrote:
> > Richard Cohen wrote:
> > > Metabugs are generally a bad idea because they are very hard to
> > > maintain. What is the point of "Get games working perfectly", and how
> > > can it ever be resolved?
> >
> > Who said it needs to be resolved, ever, or in any kind of near future?
> >
> > I see metabugs more as a categorization feature.
> > If you want an overview of all games that fail in Wine, go check out
> > that particular entry.
>
> Maybe this could be better done with the use of keywords. for instance
> we could have a 'game' keyword. Then one would find all these bugs by
> querying for bugs with the 'game' keyword.

Honestly, I think metabugs are better than keywords.

It's mainly a user interface thing.  Freetext keywords seem like this
really weird feature, which is not clearly represented in the UI, and
where the consequences of entering a particular keyword is not
especially clear.  I think that noone likes to use it (feel free to
correct me).

Metabugs are much more clear.  There's a descriptive text and
discussion page for the metabug, where people can discuss which bugs
really belong there, or whether this and that bug is related, or which
bugs are most critical and needs to be prioritized.

Keywords are also prone to spelling mistakes.  Enter "shell23" instead
of "shell32", noone will find the bug.  Metabugs are more "set in
stone", you just have to find the right bug id.  Not a big problem per
se, but might prevent people from wanting to use it.

[Francois Gouget]

On Tue, 11 Oct 2005, Molle Bestefich wrote:
[...]
> It's mainly a user interface thing.  Freetext keywords seem like this
> really weird feature, which is not clearly represented in the UI, and
> where the consequences of entering a particular keyword is not
> especially clear.  I think that noone likes to use it (feel free to
> correct me).

I don't share your aversion for keywords. As for them not being clearly 
represented in the GUI, at least when a bug has a keyword, the keyword 
is clearly visible in the 'Keywords:' field, whereas when it is 
associated to a meta-bug all you see is a cryptic dependency on bug 967 
or some such.

Also the Bugzilla keywords are not freetext. More on this below.
> Metabugs are much more clear.  There's a descriptive text and
> discussion page for the metabug, where people can discuss which bugs
> really belong there, or whether this and that bug is related, or which
> bugs are most critical and needs to be prioritized.

There is a page which describes each keyword. To get to it simply click 
on the 'Keywords:' label in any bug:

http://bugs.winehq.org/describekeywords.cgi

Note: On this page you can see how many bugs are related to each 
keyword. Simply click on the bug count and you get all the bugs for that 
keyword.
> Keywords are also prone to spelling mistakes.  Enter "shell23" instead
> of "shell32", noone will find the bug.

No. As I said above the Bugzilla keywords are not freetext. Type 
'shell23' and all you will get is the following error message:
(on a violently red background to be sure you notice it<g>)

shell23 is not a known keyword. The legal keyword names are listed
    here.

Metabugs on the other hand are prone to typos. Say I type '976' instead 
of '967', Bugzilla won't issue an error message. And if I don't follow 
the link to make sure I typed right I will not notice the mistake. As 
you mentioned such a simple typo will prevent people from finding the 
bug.

And since components might be a better match than keywords for some 
tasks, I will just mention that like keywords they are not freetext, 
they are clearly displayed in the GUI, and have a page describing them 
(http://bugs.winehq.org/describecomponents.cgi?product=Wine).

[Molle Bestefich]

Francois Gouget wrote:
[...]
Thanks for the clarifications ;)!
> There is a page which describes each keyword. To get to it simply click
> on the 'Keywords:' label in any bug:
> http://bugs.winehq.org/describekeywords.cgi

Well, there I go.  That page was well hidden from public view.
I see now that it's linked from the <keywords> anchor on a bug.

That's a bit weird, since half of those anchors just link to static
informational pages with dumb content.  Would've been nice if those
had a 'help' icon, to discern them from those that are actually
useful.

Or perhaps the 'keywords' and 'components' pages should be added to
the Bugzilla menu over to the left.

My amazement over how unintuitive Bugzilla is will never cease :-).

[Detlef Riekenberg]

Am Dienstag, den 11.10.2005, 12:48 +0200 schrieb Francois Gouget:
> And since components might be a better match than keywords for some 
> tasks, I will just mention that like keywords they are not freetext, 
> they are clearly displayed in the GUI, and have a page describing them 
> (http://bugs.winehq.org/describecomponents.cgi?product=Wine).

I suggested to add "wine-printing" in #3302
( http://bugs.winehq.org/show_bug.cgi?id=3302 )

I think, printing is very important for wine,
how many users know, that printing is a part of "wine-gdi" and
the subject is less specific than other keywords
 ("wine-richedit" as example).

What do you all think about this topic?

[Tony Lambregts]

Detlef Riekenberg wrote:
> Am Dienstag, den 11.10.2005, 12:48 +0200 schrieb Francois Gouget:
> > And since components might be a better match than keywords for some 
> > tasks, I will just mention that like keywords they are not freetext, 
> > they are clearly displayed in the GUI, and have a page describing them 
> > (http://bugs.winehq.org/describecomponents.cgi?product=Wine).
>
> I suggested to add "wine-printing" in #3302
> ( http://bugs.winehq.org/show_bug.cgi?id=3302 )
>
> I think, printing is very important for wine,
> how many users know, that printing is a part of "wine-gdi" and
> the subject is less specific than other keywords
>  ("wine-richedit" as example).
>
> What do you all think about this topic?

I changed wine-gdi to read wine-gdi-(printing)

This makes it more obvious to everyone. I could change it to something else if 
anyone has a better idea.

--

Tony Lambregts

On Mon, 10 Oct 2005 08:45:30 +0200, James Hawkins   
wrote:
> Hi,
>
> I really appreciate the effort everyone has put into cleaning out the
> old bugs in our bugzilla recently; however, I do have an issue with
> the way we're closing some of the bug reports.  The ultimate outcome
> of wine is to enable a user to run windows apps just as they would in
> windows, so if a user has to run the app with a native dll or follow
> special instructions to make it work, then there is a bug in wine that
> needs to be fixed.  Quite a few bugs have been closed recently
> referring the user to the instructions in the AppDB or to a list of
> dll overrides that makes the app work.  Recommending a dll override
> can be useful to the end user as a temporary workaround, but the bug
> hasn't been fixed.  Cleaning out the bugzilla is well appreciated, but
> we must keep up due diligence in order to keep wine's bugzilla as a
> reliable status of wine's bugs.  I offer this as the beginning of a
> discussion of bugzilla administration policies.  Any thoughts,
> comments, and ideas are welcome.
>
> --
> James Hawkins

That was basically the point I was trying to make in the autocleaning  
script thread but I got told if I didnot like it I should volenteer as  
bugzilla maintainer.

I dont really give a hoot if wine bugzilla gets scapped, I was just trying  
to make the suggestion that the wish to reduce truely dead bugs should not  
be done in a way that reduces the value of the bug database and wastes the  
efforts of those have taken the time to fill a bug report.

I'm going to clear up my garage later but I'm not going to be throwing out  
the spanners to make the workshop look tidier.

Maybe you expressed it a bit better. ;)