Topics

2.1.0 release: suggestion for new branching plan


Nathan Heldt-Sheller
 

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 J  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.

 

Are there any objections to this plan?  Comments or suggestions to make it better?  I’d like to agree on this formally at next week’s OSWG weekly CC (Weds 9am PST, see OCF Kavi website if you’d like to attend), so that we can EOL the 1.4-rel branch and get everyone back on master asap.

Thanks,
Nathan

 


George Nash
 

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.

 

George

 

From: iotivity-dev@... [mailto:iotivity-dev@...] On Behalf Of Nathan Heldt-Sheller
Sent: Wednesday, September 5, 2018 6:04 PM
To: iotivity-dev@...
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 J  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.

 

Are there any objections to this plan?  Comments or suggestions to make it better?  I’d like to agree on this formally at next week’s OSWG weekly CC (Weds 9am PST, see OCF Kavi website if you’d like to attend), so that we can EOL the 1.4-rel branch and get everyone back on master asap.

Thanks,
Nathan

 


Mats Wichmann
 

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.


Nathan Heldt-Sheller
 

Hi again folks,

 

I’ve gotten some positive feedback on this change so I think we’ll go ahead with this process pending final discussion at this week’s OSWG meeting (again, 9am PST Weds).

 

To you question George, I’ll see if I can get a volunteer to help me document the process (including gerrit steps) at the OSWG meeting… anyone out there willing to put a little time into this (maybe half a day helping me detail a few steps in the process) on the behalf of all of IoTivity Dev?

 

Separate but related: my thought is that – as a simple starting point policy – any patch (or set of patches) that entails new CTT test cases would by a mandatory separate branch, which could be validated against CTT before merging into master or a release branch.  This seems like a good policy to prevent master from getting into a state where it fails CTT: the new CTT test cases would be passing on a development branch before the code was merged to master.  Any feedback on this idea before I try to make it part of IoTivity’s official coding guidelines?

 

Thanks,
Nathan

 

From: Nash, George
Sent: Thursday, September 6, 2018 8:54 AM
To: Heldt-Sheller, Nathan <nathan.heldt-sheller@...>; iotivity-dev@...
Subject: RE: 2.1.0 release: suggestion for new branching plan

 

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.

 

George

 

From: iotivity-dev@... [mailto:iotivity-dev@...] On Behalf Of Nathan Heldt-Sheller
Sent: Wednesday, September 5, 2018 6:04 PM
To: iotivity-dev@...
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 J  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.

 

Are there any objections to this plan?  Comments or suggestions to make it better?  I’d like to agree on this formally at next week’s OSWG weekly CC (Weds 9am PST, see OCF Kavi website if you’d like to attend), so that we can EOL the 1.4-rel branch and get everyone back on master asap.

Thanks,
Nathan

 


Gregg Reynolds
 



On Wed, Sep 5, 2018, 8:04 PM Nathan Heldt-Sheller <nathan.heldt-sheller@...> wrote:

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 J  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

Before you do this please take some time to study this: 

Using master for development seems questionable to me.


Gregg Reynolds
 



On Mon, Sep 10, 2018, 5:51 PM Gregg Reynolds <dev@...> wrote:


On Wed, Sep 5, 2018, 8:04 PM Nathan Heldt-Sheller <nathan.heldt-sheller@...> wrote:

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 J  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

Before you do this please take some time to study this: 

Using master for development seems questionable to me.

More pointedly, it is not enough to simply support branches. Branch off of what?


Mats Wichmann
 

On 09/10/2018 04:51 PM, Gregg Reynolds wrote:

Before you do this please take some time to study this:
https://nvie.com/posts/a-successful-git-branching-model/

Using master for development seems questionable to me.
I'm well acquainted with that famous diagram, but it's only one of many
possible models. We pretty much use master as what he lists as
"develop" and don't have the thing he calls "master". Whether that's the
right model or not. Nothing wrong with looking at whether that is still
right for iotivity's current place on the maturity curce, if anyone is
motivated to do that.


Gregg Reynolds
 



On Mon, Sep 10, 2018, 7:03 PM Mats Wichmann <mats@...> wrote:
On 09/10/2018 04:51 PM, Gregg Reynolds wrote:

> Before you do this please take some time to study this:
> https://nvie.com/posts/a-successful-git-branching-model/
>
> Using master for development seems questionable to me.

I'm well acquainted with that famous diagram, but it's only one of many
possible models.  We pretty much use master as what he lists as
"develop" and don't have the thing he calls "master". Whether that's the
right model or not.

Right. But that's not really the problem. Which is: branch from what? Anything? Result = chaos.


Nothing wrong with looking at whether that is still
right for iotivity's current place on the maturity curce, if anyone is
motivated to do that.