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

[Tony Lambregts]

Ann and Jason Edmeades wrote:
> 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.

<blush> ah shucks </blush>

[snip]
> 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).

I have looked at this and it is not possible to do this without 
drastically altering (forking) bugzilla. We can however get a list of 
bugs that have not had any activity for any length of time you want.

http://bugs.winehq.org/buglist.cgi?&bug_status=NEW&bug_status=ASSIGNED&bug_s...

I have looked into having a resolution "abandoned" and that should be
possible to do without forking bugzilla "Too Much".
> 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

Search for Keyword "Download" I have been very thorough and "To The Best 
Of My Knowledge" anthing that has a download (demo, freeware shareware 
etc) is marked as such.
> 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.

This would require major changes to Bugzilla, and I do not, at the 
moment, want to start forking.
> 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.

Pretty Please....!

--

Tony Lambregts

[Ann and Jason Edmeades]

> > 1. I would like to get implemented an AUTOMATIC timeout on the bug
> > reports.
> > I have looked at this and it is not possible to do this without 
> > drastically altering (forking) bugzilla. 
> > I have looked into having a resolution "abandoned" and that should be
> > possible to do without forking bugzilla "Too Much".

Shame... Ok, so if we have a bug which has been inactive for what period of
time following a request for more information (or to retest with a later
driver) can we actually close it? 

If I said 2 months, would anyone complain?

I'd like to completely clarify that :
- If _easily_ recreatable then a comment can be put in to keep it active by
the person looking at it, but otherwise anything which is inactive for 2
months when the action was with the raiser can be closed.

If so, which closing code (does it matter?!)? With no changes to bugzilla I
would suggest an INVALID closing code with appropriate words added.

Once agreed, we can have some fun clearing out some old rubbish. Looking
through the old bugs and trying to reproduce a few, there are some easily
recreatable basic bugs but those where there is nothing to go on really cant
be progressed!
> 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.

Interesting that noone was interested in that. As an alternative question,
which wine developer would be interested in being notified if a problem
crops up in an area they are known to work in - This would be no commitment
or anything, just informational. I would almost say this would be a manual
process if someone investigates a bug and pins it down to a specific area

Jason

Ann and Jason Edmeades wrote:
> > > 1. I would like to get implemented an AUTOMATIC timeout on the bug
>
> reports.
> > I have looked at this and it is not possible to do this without 
> > drastically altering (forking) bugzilla. 
> > I have looked into having a resolution "abandoned" and that should be
> > possible to do without forking bugzilla "Too Much".
>
> Shame... Ok, so if we have a bug which has been inactive for what period of
> time following a request for more information (or to retest with a later
> driver) can we actually close it?
>
> If I said 2 months, would anyone complain?

No one has so far...
> I'd like to completely clarify that :
> - If _easily_ recreatable then a comment can be put in to keep it active by
> the person looking at it, but otherwise anything which is inactive for 2
> months when the action was with the raiser can be closed.
>
> If so, which closing code (does it matter?!)? With no changes to bugzilla I
> would suggest an INVALID closing code with appropriate words added.
>
> Once agreed, we can have some fun clearing out some old rubbish. Looking
> through the old bugs and trying to reproduce a few, there are some easily
> recreatable basic bugs but those where there is nothing to go on really cant
> be progressed!

Well if the attached patch is OK for Jeremy then you will not need to use 
"INVALID" and you use "ABANDONED" instead. ;^)

Jeremy: You need to rerun checksetup.pl for this change to work.

Change log: Add resolution "ABANDONED to bugs database

Files Changed: checksetup.pl


Index: checksetup.pl
===================================================================
RCS file: /home/wine/bugzilla/checksetup.pl,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 checksetup.pl
--- checksetup.pl	1 Dec 2004 23:15:11 -0000	1.1.1.1
+++ checksetup.pl	8 Mar 2005 04:26:59 -0000
@@ -731,7 +731,7 @@
         # Fields we actually want (matches the current collectstats.pl)                             
         my @out_fields = qw(DATE NEW ASSIGNED REOPENED UNCONFIRMED RESOLVED
                             VERIFIED CLOSED FIXED INVALID WONTFIX LATER REMIND
-                            DUPLICATE WORKSFORME MOVED);
+                            DUPLICATE WORKSFORME MOVED ABANDONED);
 
         while (<IN>) {
             if (/^# fields?: (.*)\s$/) {
@@ -1483,7 +1483,7 @@
     reporter mediumint not null,
     version varchar(64) not null,
     component_id smallint not null,
-    resolution enum("", "FIXED", "INVALID", "WONTFIX", "LATER", "REMIND", "DUPLICATE", "WORKSFORME", "MOVED") not null,
+    resolution enum("", "FIXED", "INVALID", "WONTFIX", "LATER", "REMIND", "DUPLICATE", "WORKSFORME", "MOVED", "ABANDONED") not null,
     target_milestone varchar(20) not null default "---",
     qa_contact mediumint not null,
     status_whiteboard mediumtext not null,
@@ -2536,7 +2536,7 @@
 # into.
 
 my @resolutions = ("", "FIXED", "INVALID", "WONTFIX", "LATER", "REMIND",
-                  "DUPLICATE", "WORKSFORME", "MOVED");
+                  "DUPLICATE", "WORKSFORME", "MOVED", "ABANDONED");
 CheckEnumField('bugs', 'resolution', @resolutions);
 
 if (($_ = GetFieldDef('components', 'initialowner')) and ($_->[1] eq 'tinytext')) {

[Lionel Ulmer]

On Thu, Mar 03, 2005 at 10:30:55PM -0000, Ann and Jason Edmeades wrote:
> 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.

Well, that somehow supposes that the bug is already well characterized in a
proper category (DirectX, MSI, COM, ...).

I.e. there is no easy way for me to say 'I want to look at all DDraw-related
bugs that are in the database'.

      Lionel (who has a lot of Bugzilla mails in his inbox but never finds
              the motivation to really look at them :-) )

-- 
		 Lionel Ulmer - http://www.bbrox.org/

[Tony Lambregts]

Lionel Ulmer wrote:
> On Thu, Mar 03, 2005 at 10:30:55PM -0000, Ann and Jason Edmeades wrote:
> > 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.
>
> Well, that somehow supposes that the bug is already well characterized in a
> proper category (DirectX, MSI, COM, ...).
>
> I.e. there is no easy way for me to say 'I want to look at all DDraw-related
> bugs that are in the database'.

Is the current component structure inadequate?

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:	DirectDraw, DirectSound, Direct3D, DirectPlay
wine-documentation:	Wine documentation
wine-dos:	DOS support, INT n calls
wine-files:	Filesystem interaction
wine-gdi:	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-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-tools:	Subsidiary tools (except wrc)
wine-user:	Events, messages, window handling
wine-winelib:	Winelib issues
wine-x11driver:	Bugs about problems with Wine X11 driver.

If it is not. What do we need to do to change it?

--

Tony Lambregts

[Mike Hearn]

On Fri, 04 Mar 2005 07:57:15 -0700, Tony Lambregts wrote:
> Is the current component structure inadequate?

I think it's OK, but this is just a side effect of not having any formal
module owners, but rather only informal ones.