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.
