On 2/19/2018 6:24 PM, Ferenc Wágner wrote:
"Fabio M. Di Nitto" fdinitto@redhat.com writes:
there is a PR open to merge stable1-proposed that will keep running CI on each cherry-pick backport for now, and we feel the time is ready to cut 1.1, we will just merge that PR at once.
So, this sounds like the point of stable1-proposed is to have CI, but I can't see why stable1 couldn't be set up the same way. What do I miss?
"Fabio M. Di Nitto" notifications@github.com also writes:
On 2/19/2018 10:43 AM, wferi wrote:
I don't really understand the master/stable1/stable1-proposed distinction at the moment, because I can't see anything on master which isn't 1.1 material, so we could pretty much release 1.1 straight from master.
https://lists.kronosnet.org/pipermail/devel/2018-January/000049.html
you are right, at the moment master and stable1-* haven´t diverged yet but they will in future .
It's getting an interesting question nearing the 1.1 release. Basically, why complicate history by pretending 1.1 is being developed in parallel with something else? Surely, there'll be a time when some breaking change (not suitable for 1.x) will have already been merged into master and still the need arises to cut a 1.x+1 release. Then we could branch off stable1 from master right before the breaking change and start doing parallel development when we're forced to. Till then, I'd find it perfectly fine to tag new minor releases on the master branch. Is that an oversimplification?
This deserves a semi-long explanation as it touches many interconnected points in my head (and please note: MY HEAD ;))
let´s start from CI. right now CI is still limited to build and make check (or variations of check/distcheck/etc) + build rpms.
CI phase1 goal is to have all HA related packages (libqb/knet/corosync/pacemaker) build and make check depending on which dependency is changing here or there. You can see already that most of corosync has been already added to CI and it rebuilds as knet changes. phase1 covers unit testing and integration testing. Catch as early as possible any breakage between and within each component.
CI phase2 goal is to have functional testing integrated in CI. That is effectively run a series of CSTS HA tests tailored to catch operational issues in the stack. This has not been implemented yet and it will take some time to get there.
How does this fit with branching in knet?
all master branches of all projects will build and test together. From a CI implementation it´s very easy to trigger master with master.
when looking at stable branches around, the test matrix combination is slightly more complex. For example, corosync stable can be released at any given async time from knet, hence it needs to be tested on current stable (aka stable1) and next knet stable (stable1-proposed). As a side note, in jenkins it´s just a lot easier to manage that via git branches than tags within a branch btw (at least based on my poor knowledge of jenkins).
Now, that said, the combination of stable1 and stable1-proposed branches fits 2 more purposes (on top of making it easier to test other projects).
stable1 branch is always in a "can be released" state. It is built on top of the last stable release and nothing else. Let say we need to do an emergency release (CVE, or super major bug fix), we can literally just take that fix in stable1 branch and release immediately without having to worry about other changes landing in stable1.
stable1-proposed serves the purpose of staging area for changes that will go into stable1 at some point in time, but it gives more space for testing vs other projects.
As for tagging from master and branching (as you mention above), this is more a matter of personal preference. I don´t like GA releases out of master branches. I prefer to have a dedicated timeline for stable releases/branches.
You are absolutely right that at this point time there is no difference in any branch but there will be soon and having the branches created early (from 1.0) did allow me to setup the whole CI infrastructure ahead of diverging the code. Note here that changing CI is super time consuming and requires lots of testing too. So prepare early vs scramble later is a much better strategy :-)
hope this gives you a better overview :-)
Fabio