On 21.07.2017 06:21, David Anderson wrote: > Stable branches for server and API: yes. > (prerequisite to this is a way of thoroughly testing these components, > which we don't currently have. > How about if people start discussing this?)
I don't see having thorough tests as a prerequisite to having a stable branch. What matters is that we are working toward making a branch stable by finding ways to test the code. Testing the code is a technical issue to be solved. Declaring what branches there should be is a management issue. Both are independent from each other. We can decide what branches to use for what purpose before we implement tests. In fact I think it would be easier to make the decision about the branching model up front and then gradually implement tests on the stable branches. After some time we then declare the stable branch to be stable. It does not need to be stable from the beginning. I already made several attempts to discuss using testing frameworks in BOINC. There was no resonance at the time. What I want BOINC to do is to make an informed decision what framework to use before starting to implement actual tests are even begin to implement a custom test framework. What I also want to prevent from the start is that I'm the only user of this test framework. If BOINC is going to get a test framework their must be a decision to make sure that every new feature needs to have accompanying tests (that are derived from a reference or are the reference themselves). When fixing bugs it should also be made mandatory to check if an automated test would have caught this bug and then provide such a test alongside the bugfix. These simple rules, when enforced, make sure that at least over time the code coverage of tests will increase. > > Separate branch for TBD: no. > TBD has its own completely separate repo. > It requires some features in BOINC (such as keywords) > which are of general utility beyond TDB. The features that TBD needs in BOINC should go into a feature branch and once they are tested they are merged into master. This is to ensure that if a project decides to update their server code while this new feature is developed they don't get a not-production ready feature built into the scheduler when they checkout the master branch. This is, as I see it, the case right now and this is what sparked my initial message. There are other developers working on BOINC at the same time and we somehow need to coordinate our work and how to integrate it into BOINC. With git and github we have powerful tools available that help us in this regard and that help us automate a lot of the stuff that needs doing we just need to embrace them and use them. Regards Christian _______________________________________________ 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.
