Just so we are all on the same page about what issue is discussed here and how an "integration branch" can solve this.
A project wants to use a version of the BOINC code that is known to be stable (because usually you choose a released version of a software to use) The BOINC server part has no versioning thus projects can only checkout the branch named "master" at the moment. The code in this branch is not guaranteed to work for the project, it is not even guaranteed that the code in this branch compiles successfully. So currently you could characterize "master" as a development branch. All development is happening on this branch and it is supposed to be buggy and broken from time to time. That is not what a project wants to use for a public facing project. Because using a development branch means the project needs to do tests before deploying the code on the public project or risk a lot of cleanup work if problems are encountered afterwards. This is usually not what project administrators are paid for, it might even be that the project admin does not have the skills to troubleshoot problems in the BOINC code. Remember projects want to have the possibility to get source code that has already been tested (to some degree) and at least is guaranteed to compile. Having an "integration branch" would solve this issue. Because the workflow changes a bit when new features and bugfixes are developed and a branch is named the "integration branch". New features are developed in so called "feature branches" that are forked from the "integration branch". When a feature is mature enough and tested to do what it should do it is then merged into the "integration branch". This way it is guaranteed that the "integration branch" has some properties that are wanted by projects (see above). In this scheme the "feature branches" are characterized as "development branches" and the branch called "master" is the "integration branch". I found a nice graphical overview how this "Integration branch" system works too: https://backlogtool.com/git-guide/en/stepup/stepup1_5.html In this approach the burden to test features and bugfixes is moved from the project to the developer (where it rightfully belongs). Each developer can also make sure that he/she is not meddling with development going on at the same time by other developers (because they are using different feature branches). This approach also helps developers to make sure that they don't introduce unnecessary bugs or typos into a branch that is used by projects because they would be spotted in the feature branch. This "integration branch" approach can later be augmented by automated tests that regularly run on the "integration branch" to make sure it is as stable as we want to have it. You can simply increase stability of the "integration branch" by simply adding useful unit tests that test individual features as well as an overall integration test that tests all features (to some extend). I hope this clears up how the "integration branch" approach can help to fix the issue Oliver and I presented. Regards Christian On 20.07.2017 12:06, David Anderson wrote: > 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 > [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.
