As far as I can tell, none of the issues you mention have anything to do with 
whether
we call master a "development branch" or an "integration branch".

You seem to think that people who don't buy into your world view are resistant to change.
Not the case.

If we had more energy going to understanding code, fixing bugs, writing 
documents, etc.,
from the people who are able to do so, rather than dogmatic posturing, we'd all be better off.

On 7/20/2017 2:11 AM, Oliver Bock wrote:
On 20/07/17 10:09 , David Anderson wrote:
Sorry, but this isn't a sustainable model.
Well, it's sustained us this far.
Well, in that case we have a different understanding of "sustainable".
Yes, BOINC survived, barely, but did it strive? Is it easy (let alone
fun) to use for downstream projects? Did it attract a healthy number of
volunteer developers after the alleged transition into a community
driven open source software (OOS) project? Sure, source code management
(SCM) isn't all there's to it but it's a significant part of it. Maybe
you underestimate its effect? I'm also nearing a ten-year involvement in
BOINC and way too often it's been a pain to use it as a downstream
project because of the way its SCM is done. It's codebase is brittle and
just can't be trusted, unnecessarily. 15 years ago the tools and best
practices were different. But these things are moving. Why not
participate in the progress that's been made since then, making
everyone's professional life easier and BOINC more attractive? Yes, that
means change, but it doesn't hurt. If you don't adapt and progress it
can only get worse, in particular from the point of view of newly
interested scientists and contributors.

What I'm trying to say is: responding to constructive criticism with
"that's how we've done it for 10+ years, no need to change" isn't very
helpful if you want to see things improve. My proposal is (once again)
just meant to improve things - to make BOINC better. For instance, I for
one just can't take over a responsible (!) role as release manager for,
say, Android unless there's a codebase and a workflow I can trust. If
ideas, proposals or contributions aren't discussed at all or rejected
without meaningful reasoning people will stop trying. I'm sure that's
not in your interest.

Best,
Oliver


_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://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