On 09/06/2018 09:53 AM, George Nash wrote: > Nathan, > > I think this is a great idea. My only comment is that we need to have a > clear and easy way to request creation of a branch to work on. > > What is the minimum that developers need to get a branch created in gerrit? > > Do they just email a request with a list of the work they are expecting to do > and a branch name? Or do we want a little more? > > In general I feel we should be really liberal with the creation of branches. > Since creating branches are cheap in git. If a developer is working on a task > and they think it may require multiple commits or require sizable QA time a > branch can be created.
There are two pieces: 1. getting the branch into gerrit 2. getting the CI system (jenkins) to pay attention In theory the former is very simple, you just push to the new branch: git push origin HEAD:/refs/for/newbranch In practice I think it may require rights to have been previously granted, and possibly the branch may need to be created through the gui first (there is a branches tab under Projects to do this). which may require rights to have been previously granted... The latter I'm not sure about. I thought the CI system needed to know explicity, but looking just now in the ci-management project, there's no mention of 1.4-rel and it's working, so.... > > George > > From: iotivity-dev@lists.iotivity.org > [mailto:iotivity-dev@lists.iotivity.org] On Behalf Of Nathan Heldt-Sheller > Sent: Wednesday, September 5, 2018 6:04 PM > To: iotivity-dev@lists.iotivity.org > Subject: [dev] 2.1.0 release: suggestion for new branching plan > > Hi IoTivity Devs, > > In the past, we've had a relatively unstable master branch, which has caused > us to stick to release branches perhaps longer than we'd like, to avoid > battling a constant stream of regressions. These long-lived branches entail > more work cherry picking release branch changes into master, tracking status > on two separate branches for longer, etc. > > Comarch has recently finished installing a nightly regression test using the > OCF Certification Test Tool, and will be running it against master every > night going forward. We'll get an email within 24 hours if an OCTT > regression is introduced. I'm very happy about this :) This - along with > existing Jenkins tests - should keep new regressions to a minimum. This in > turn means I think we can shorten the lifecycle for our release branches. > > For the next release ("Bangkok Point Release", a.k.a. 2.1.0) I'd like to try > a much shorter release branch plan. We'd move all development to master > until we basically are code complete (and passing OCTT by virtue of the > nightly regression test). At that point we'd create a 2.1-rel branch, create > a 2.1.0-RC0 tag, and run through QA process. The only patches against > 2.1-rel would be to fix bugs found in this final QA cycle (which again > hopefully will be minimal thanks to our nightly test cycles). As soon as the > QA cycle finishes we'd make the 2.1.0 tag, cherry pick the 2.1-rel branch > back to master, and resume working on master. The goal would be to have > active development on the 2.1-rel branch last less than a month (as compared > to multi-month lifespan of previous release branches). > > I think one effect of this is that large changes, such as a re-architecture > or major new feature, should be developed on a separate branch rather than on > master, so that master doesn't contain merged patches that form incomplete > changes. I personally think this is good development practice anyway, but > it's not the way IoTivity master has been treated previously. I don't think this is a change, really. Our guidelines already say to use feature branches to develop major new stuff, and our use of Jenkins to vote on every patch (including buildability AND not failing the unit-tests runs) suggests that we're trying to enforce the "master is always buildable" rule. [there's more to say on that topic, of course; seems failing tests don't necessarily fail the build, tests incomplete, or being avoided, etc. Different topic than branching policy]. Adding CTT runs improves the picture, clearly. getting people off the release branches is a noble goal though. I think there were special reasons for 1.2-rel and 1.3-rel both being particularly long-lived, but it kind of wasn't in my scope. Regression testing with CTT does bring up the question of "against which spec version". The previous released one tells you you didn't break anything, but doesn't cover the period where you're edging up to the next release but are using master and haven't yet branched off the release branch. Now you're coordinating moving feature sets and a moving test suite. Just something to keep in mind. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9928): https://lists.iotivity.org/g/iotivity-dev/message/9928 Mute This Topic: https://lists.iotivity.org/mt/25216172/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
