Discussion on Bug tracking database

[Ann and Jason Edmeades]

Hello,

I thought I'd try to start a discussion to try to encourage changes in the
bug tracking, but it would both require agreement and someone (else) who
could physically make the changes.

Is it me or is our bug tracking database not really working the way it
should?

Firstly I'd like to thank Tony - he seems to do a lot of maintaining of the
bug database and deserves a lot of credit. Until I started looking through
them and monitoring the bug mailing list, I didn't realize how much he did.

Bug database problems..

1. Some problems reports start off as useless. Its not a bug report, its
more a call for assistance. 

2. Some bug reports are severely out of date. A large number of them have as
a last update a request to test on a more recent cvs (which is a fair thing
to do if the bugs are left idle for eg. 1 year!

3. We have a large number who due to our inactivity mean the person who
raised it no longer cares, so any questions are a waste of time and come
back unanswered

4. We have some where the email address of the raise has changed so even if
they care they may not notice any changes to the bug report

5. Its hard to tell the bugs you can reproduce with downloadable freeware
from those that require expensive software

Suggestions....

1. I would like to get implemented an AUTOMATIC timeout on the bug reports.
If they are inactive for eg. 4 months then an automatic update is added to
them asking to try latest cvs and confirm the problem still exists. If the
problem is not updated within a month, the bug report gets automatically
closed with a specific code (eg. CLOSED/inactivity).

2. I would like a clear way to identify if the problem can be reproduced
with **free** downloadable software, eg a demo, freeware, shareware etc.
This should be searchable for people wanting a quick bug fix

3. I would like there to be a transition from an initial state before being
accepted, which basically allows rejection of a bug report if there is not
enough information in it. Unfortunately someone would have to actively do
this, so this would be a very had one to achieve.

4. I would also like a bug fixing period of time, when all wine developers
are encouraged to work on bugs for eg. one day a month. 

Interestingly, even though most people seem to end up working in a
particular area they may not handle bugs in that area (probably because they
don't check for them!). How many of the wine developers would consider
allocating time once a month (even if its just an hour!) to look at a bug
report, perhaps try it or go back asking for appropriate traces etc. 



I know some of this can be achieved by 'proper' use of the bug states,
keywords etc, but we don't...!

Anyway, I thought I would start a discussion, so you know my thoughts - what
are other peoples.

Jason