I don't know of any bug tracker that doesn't have states, even if it's
just an open/closed boolean. It's a basic feature.
Trac used to have hardcoded states called open, assigned, closed, and
reopened. Since 0.10, the ticket workflow is completely configurable;
new states and transitions can be added to trac.ini.
Enviado desde mi iPod
El 21/05/2009, a las 09:32, john.mcl...@sybase.com escribió:
Bugzilla has the concept of states of a bug. I don't know if trac
does or
not.
A bug is created,
Assigned to a particular developer.
Fixed by the developer.
Verified.
Closed.
There are also states for "need more information", and "invalid".
Of course, that assumes that there is a QA department of some kind to
verify and close.
jm7
David Barnard
<da...@didactylos
.net> To
Sent by: "Paul D. Buck"
boinc_dev-bounces <p.d.b...@comcast.net>
@ssl.berkeley.edu cc
BOINC Dev Mailing List
<boinc_dev@ssl.berkeley.edu>
05/20/2009 06:36
Subject
PM Re: [boinc_dev] BOINC All
versions
download page
On Wed, May 20, 2009 at 10:35 PM, Paul D. Buck <p.d.b...@comcast.net>
wrote:
The problem is that there is no defined process for indicating when
that
magical event occurs.
Does it occur when I think that there is a problem? When you think
there
is
a problem? When JM VII agrees with either of us that there is a
problem?
I don't see this as problematic. An issue goes in Trac if it can be
reproduced, or if it clearly affects a number of people (even if the
trigger is unknown). In other words, Trac is not a suitable venue for
troubleshooting. But anything that got fixed but was never put in Trac
- should have been. The Trac ticket should be created before the fix.
This definition is hard to formalise, but it's not hard to close the
odd bogus ticket.
Unfortunately, the developers pay about as much attention to the Trac
system as they do to the other support channels and forums. This
leaves people with problems posting to mailing lists that aren't an
ideal venue for issue tracking. Inevitably, things slip through the
cracks. Like 200-odd outstanding tickets, for example.
I agree with you absolutely about closing tickets. Tickets should not
be closed until the fix is tested and verified, not the instant an
untested patch is committed. This process desperately needs
formalising.
David Barnard
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
