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.

Reply via email to