Hi Oliver, I'm taking about an intermediate level between 'cruncher' and 'developer'. I'm accredited as a 'Help desk expert' on the BOINC message boards, but I don't have the skills needed to be a full-blown developer in the versions of the various languages used within BOINC. Instead, I can (I hope) contribute by helping analyse symptoms, to make life easier for the real developers. Two examples: Even the best resourced projects - like Einstein! - can benefit from external diagnosis. A few months ago, I was pleased to be able to help Christian with a long-standing (multi-year, it turned out) BOINC preference propagation problem. Christian found the actual code at fault and committed the solution, but I like to think that this helped: https://einsteinathome.org/content/invalid-global-preferences-problem?page=1#comment-150509
That example didn't depend on version control, but this next one did. A few years ago, David added some extra (and very useful) exit status and error codes in 72368a6b205b521691af23ca65815b2ec4ac3008 (SVN 25601) Unfortunately, the web code wasn't updated to reflect the new codes until f3c8ab83e91a430611bbb25ce714f5fd43b8c915 (SVN 25858) - over two months later, as is easier to deduce from the SVN than SHA references. Not every project updated (or updates) their BOINC servers synchronously, and http://boinc.berkeley.edu/dev/forum_thread.php?id=7704&postid=45186#45186 shows how I was able to demonstrate that - even after the project said they had updated their server code - a missed include file was still responsible for misleading task outcome information on their website. That diagnosis would not be possible today. On Wednesday, 29 March 2017, 14:55, Oliver Bock <[email protected]> wrote: On 29/03/2017 13:22 , Richard Haselgrove wrote: > I'm talking about the information visible to volunteers outside the core > project staff. I know, but what exactly do you mean by "public-facing page" and "diagnosis"? Of what? The version of the web code or the daemons used by a project? > Small science projects don't have the resources (or the > inclination) to follow every twist and turn. I don't see how that's related to our discussion. > Unless you support and > enable volunteer contributions too, you lose a potentially valuable > resource for community computing in general. Again, I don't see how using SHA1s precludes any volunteer contributions. I mean, we're talking about code contributions here, not cycles, right? That means we're talking about developers, even if only casual ones. They have to deal with git and GitHub anyway to provide their contributions ans SHA1s shouldn't pose any hurdle to that target audience. Cheers, Oliver _______________________________________________ boinc_dev mailing list [email protected] https://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 [email protected] https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
