Paul: I agree that there is a problem. I disagree with your analysis on what the fix was.
The problem is that BOINC pre-empts too easily. In some cases (not all cases though) the task switch to a high priority task could wait until the next normal task switch. You want to just make the test less frequent without fixing the underlying cause of the problem. I want the underlying problem fixed. A person entering an issue in TRAC should stick to the reproducible facts and should normally shy away from analysis. jm7 boinc_dev-boun...@ssl.berkeley.edu wrote on 05/20/2009 09:20:48 PM: > "Paul D. Buck" <p.d.b...@comcast.net> > Sent by: boinc_dev-boun...@ssl.berkeley.edu > > 05/20/2009 09:20 PM > > To > > David Barnard <da...@didactylos.net> > > cc > > BOINC Dev Mailing List <boinc_dev@ssl.berkeley.edu> > > Subject > > Re: [boinc_dev] BOINC All versions download page > > 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. > _______________________________________________ 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.
