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