25 Feb
2018
25 Feb
'18
4:40 p.m.
"Fabio M. Di Nitto" <fdinitto(a)redhat.com> writes:
On 2/19/2018 6:24 PM, Ferenc Wágner wrote:
Thanks, Fabio, on second read this all makes perfect sense and I find it
a well-engineered solution. The seemingly superfluous existence of all
these branches is adequately explained by the needs of the CI setup.
What I still don't get is why stable1-proposed couldn't follow master
during the 1.1 cycle. Concretely, why did you cherry-pick individual
commits from master into stable1-proposed instead of just fast-
forwarding stable1-proposed to master after each PR merge (since they
all were 1.1 material)? I think that would have created a simpler
representation of the development process. I agree that this method is
not generally applicable, but why not exploit it if possible?
Another method would be to merge all 1.1 material into stable1-proposed
only, and occasionally merge stable1-proposed into master to avoid
excess divergence in presence of 2.0 work. This is a little more
complicated but also more general workflow, and still avoids cherry-
picking.
Yeah, I don't like cherry-picking, I find it hard to follow. Even git
can't follow it (for example git branch --contains <hash> does not find
cherry-picked "clones" of the <hash> commit). This "damage"
could still
be fixed to some extent by merging stable1-proposed into master now.
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?
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).
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. 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.
I admittedly don't understand this concern fully. Wouldn't the merging
workflow resolve it?
--
Regards and a happy 1.1,
Feri :)