Actually it is never that hard to formalize, it just takes a willingness to recognize that the word process is not a four letter one.
And the formal name for the way things get decided if they are a bug or not is called a Change Control Board. It can be small, but it should never be so small that there is only one member. Then you state how you get from here to there. So, someone like me, Richard, etc. posts initial data on the Alpha list or on the BOINC boards. Reviewed and agreed upon it is then formalized into a ticket and prioritized. Worked, and tested and signed off... See, a whole process in a couple sentences. Though i would probably spend more time on expounding because this is the core of what software development is supposed to be about. Of course a lot of this is from all those fancy college courses on development and the money the US Air Force spent training me when I worked Civil Service ... ONe last point, the reason as illustrated quite recently here as to why the board should always be more than one member, would be the issue like were I was pointing to the negative consequences of running "enforce" as often as it is, JM VII disagreed. Were he the gateway a serious bug would be excluded simply because he does not want to look at the evidence as to the negative side effects of this problem. Even though I had a really good case where 5 tasks were trashed because of this very issue. Of course, David, you are also right, no point in having a process if you are not going to pay attention to feedback ... and no point in having a CCB if they are going to vote in lock step to exclude problems ... Can't look at that bug because your logs are too short, or don't have the right settings ... You report too many bugs so I am going to ignore you ... Don't want to look at the reports because they are too complete with too much supporting data ... I wonder if I am the only one that sees the hypocrisy and contradictions in just those three statements ... all of which, in various forms have been used to justify not looking at submissions ... but I digress ... On May 20, 2009, at 3:36 PM, David Barnard wrote: > 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.
