Hi,
I started to mark fixed bugs with: (ok 2.8.0-beta2)
instead of (in 2.8.0-beta2)
because sometimes, reporters think that the "in" means the bug happens _in_ a particular version.
Would be better to use (fixed 2.8.0-beta2) but this takes 3 more characters that we often need in the bug description.
Marc
Hi
On Sun, 05 Feb 2006 09:13:16 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I started to mark fixed bugs with: (ok 2.8.0-beta2)
instead of (in 2.8.0-beta2)
because sometimes, reporters think that the "in" means the bug happens _in_ a particular version.
Would be better to use (fixed 2.8.0-beta2) but this takes 3 more characters that we often need in the bug description.
How about using better bug tracker? The one on sourceforge is simple, but limits usage. Misusing (short) description for this is one case. Better defined states of bugs and more fields are useful. Basically what is needed for proper bug handling is: status, resolution and in which version issue is fixed. Workflow could look like:
reporter: New Issue
developer (when he wants to work on issue): Status new => assigned Assigned To => developer
developer (when issue is fixed): Status assigned => resolved Fixed in Version => 1.2.3 Resolution open => fixed
reporter can here possibly reopen issue and it is put in feedback state, so that it requires developer reaction.
release manager (when 1.2.3 is released): Status resolved => closed
Resolved issues should be still listed until version fixing that issue is actually released so that users can see them. I like this approach much more than the one we currently use on sf.net.
If you want to see such tracker, you can look at mantis [1] or bugzilla [2]. There are definitely more of them, but those two I know, I run mantis for my projects [3]. Installing mantis on sourceforge should not be a big problem.
1. http://mantisbt.org/ 2. http://www.bugzilla.org/ 3. http://bugs.cihar.com/
Michal Čihař a écrit :
Hi
On Sun, 05 Feb 2006 09:13:16 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I started to mark fixed bugs with: (ok 2.8.0-beta2)
instead of (in 2.8.0-beta2)
because sometimes, reporters think that the "in" means the bug happens _in_ a particular version.
Would be better to use (fixed 2.8.0-beta2) but this takes 3 more characters that we often need in the bug description.
How about using better bug tracker? The one on sourceforge is simple, but limits usage. Misusing (short) description for this is one case. Better defined states of bugs and more fields are useful. Basically what is needed for proper bug handling is: status, resolution and in which version issue is fixed. Workflow could look like:
reporter: New Issue
developer (when he wants to work on issue): Status new => assigned Assigned To => developer
developer (when issue is fixed): Status assigned => resolved Fixed in Version => 1.2.3 Resolution open => fixed
reporter can here possibly reopen issue and it is put in feedback state, so that it requires developer reaction.
release manager (when 1.2.3 is released): Status resolved => closed
Resolved issues should be still listed until version fixing that issue is actually released so that users can see them. I like this approach much more than the one we currently use on sf.net.
If you want to see such tracker, you can look at mantis [1] or bugzilla [2]. There are definitely more of them, but those two I know, I run mantis for my projects [3]. Installing mantis on sourceforge should not be a big problem.
I guess the problem would be how to explain users of sf.net that they should not use sf.net "native" bug tracker...
On Sun, 05 Feb 2006 20:07:15 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I guess the problem would be how to explain users of sf.net that they should not use sf.net "native" bug tracker...
You can disable it in administration.
Michal Čihař a écrit :
On Sun, 05 Feb 2006 20:07:15 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I guess the problem would be how to explain users of sf.net that they should not use sf.net "native" bug tracker...
You can disable it in administration.
Ok, but I still think that being on sf.net, we should stick with their utilities, for better integration with sf user names and our other trackers (moving bug reports to support or to feature request).
Marc
On Mon, 06 Feb 2006 08:22:28 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Ok, but I still think that being on sf.net, we should stick with their utilities, for better integration with sf user names and our other trackers (moving bug reports to support or to feature request).
I know. Maybe it would be better to push sf.net to provide more features in their bug tracker...
Michal Čihař a écrit :
On Mon, 06 Feb 2006 08:22:28 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Ok, but I still think that being on sf.net, we should stick with their utilities, for better integration with sf user names and our other trackers (moving bug reports to support or to feature request).
I know. Maybe it would be better to push sf.net to provide more features in their bug tracker...
Good idea. Speaking of this, they are launching subversion for everyone in a few weeks.
Marc
Hi
On Mon, 06 Feb 2006 08:54:47 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Good idea.
Will you (as project admin) file request? I thing having fixed in version field is good start.
Speaking of this, they are launching subversion for everyone in a few weeks.
Yes, I think we should switch then.
Michal Čihař a écrit :
Hi
On Mon, 06 Feb 2006 08:54:47 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Good idea.
Will you (as project admin) file request? I thing having fixed in version field is good start.
I will.
Speaking of this, they are launching subversion for everyone in a few weeks.
Yes, I think we should switch then.
Michal Čihař a écrit :
On Mon, 06 Feb 2006 08:22:28 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Ok, but I still think that being on sf.net, we should stick with their utilities, for better integration with sf user names and our other trackers (moving bug reports to support or to feature request).
I know. Maybe it would be better to push sf.net to provide more features in their bug tracker...
Done: https://sourceforge.net/tracker/index.php?func=detail&aid=1426054&gr...
-
Marc Delisle -
Michal Čihař