On Tue, Jul 10, 2018 at 7:58 AM, Rowsell, Brent <Brent.Rowsell@windriver.com> wrote:
With all the restructuring/churn that is currently going on branching at this time does not seem like the right thing to do.
The primary reason for branching now is to use that to work on the release process and flesh out some of our policy, such as release branch backports, etc. It also provides a common point-in-time to reference the code for longer-term testing. There is a good bit of process for us to work out here[0] and I think we're going to learn a lot by the time we want to cut a release to show the world in Berlin.
We should finish some of those activities first before branching.
I agree that branching now may limit the ability to backport (cleanly) commits from master into the branch but I don't think this is a concern for the purposes of getting some experience with a brand-new release process.
Even for a quarterly release why do we need to have a monthly branch. Shouldn’t we just work on master and branch at some point before the release.
I don't expect the intermediate monthly branches to be around for a long time and if they turn out to not be useful we can always re-evaluate and stop doing it later. dt [0] In addition we actually need to write down our definition of a 'release'. We know it is source-only, I suspect it may not have any generated artifacts besides branches in git repos, at some point though it will include published documentation. I am making an assumption here that all of the "flock" repos are considered a single unit. Some of the sub-projects do appear to have versions and at some point we may want to start to treat those as distinct projects using a release model similar to OpenStack's cycle-with-intermediary [1] model (our default is closer to the cycle-with-milestone [2] model). [1] https://releases.openstack.org/reference/release_models.html#cycle-with-inte... [2] https://releases.openstack.org/reference/release_models.html#cycle-with-mile... -- Dean Troyer dtroyer@gmail.com