cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: [VOTE] git workflow
Date Wed, 06 Aug 2014 05:26:36 GMT
Hello devs and especially committters,

I see some -1s coming by, days after the vote was closed. That is
disturbing as it means we accepted a proposal that will not be
supported by the community. So let me try to find that support in

The argument of Animesh that we are shifting the burden from one
branch to another is real and present danger. I share his concern. It
is not the only feature of this proposal and in it self does not
warrant a -1. It does not worsen the situation at hand or add to our
workload in any way. If there is no advantage to you and no
disadvantage either then why -1 something that others do find useful?
This is 'kind of' a rhetorical question. It is a real concern, however
though not the biggest at this moment.

branching is recommended but as people are rightfully wondering
"should I make a branch for a single line fix". I would, probably but
maybe not always. That doesn't mean you must. In case you are making a
fix on a release then yes you do. It is how the git-flow workflow

Committers can merge and commit where ever they feel the need. That
doesn't exempt them from thinking if it is a good idea. It doesn't now
and it won't in the future. Doing what your boss tells you to do can
be a crime!

Reverting something should only be done when the code that is a
culprit has been identified. Reverting a big change or even a bunch of
changes is a cowards way out. We shouldn't do it now or using gitflow.
It is not really related to git flow or its use. So we shouldn't
penalize developers that didn't cause a problem or ones that did. We
should help them help us make a better system.

The question of why this process isn't implemented on master is valid.
It could. It isn't however. It is a choice the authors of gitflow
made. I think it is not really the time anymore to be nitpicking about
this. Unless we find a very valid reason to alter the accepted
proposal we should all try and implement it as good as possible. I
have been RM for 4.4.0 and one thing I don't want anymore is people
share a 4.4-forward to cherry-pick commits from. It caused me a lot of

The release is what drives the merges back to master according to
git-flow. We can decide that we define a number of prerelease dates at
which we merge as well. We don't have to do it at that date but can
decide to do that the next day or week as well. This would kind of
resemble Alena's #1 (as opposed to the more pure gitflow #2). An
argument for #2 is that I don't think every customer greps the rpms
for some release. I know our operators at Schuberg Philis investigate
the code and check it out from git. They like to compare release and
look at the latest easily. just checking out master would be very
convenient for them. Of course they can check out a branch as well.
But I doubt if they know exactly what to checkout then. I usually see
them just look at the latest for a branch.

All in all, I am very skeptic on whether this will work as planned. It
is us who need to work neatly and only if we do that we can help
ourselves with improving our process. I do feel that the present way
of working, mainly the use forward branches but in general the lack of
using branches to test individual changes, is hindering us in doing
releases. The proposal at hand is very good but can only work if
supported by the people that need to work with it. It doesn't do our
release process for us. We still need to do it and not just program
some code and check it in. That will never work in any process. Your
code is not done until somebody somewhere finds it worth running it in
a production environment. So let's keep discussing and educating each

done ranting, feel free to react or contact me in person

On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <> wrote:
> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <> wrote:
>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <>
>> wrote:
>> > I fail to understand how will this model help us with the maintenance
>> > releases?
>> >
>> >
>> That's what gitflow support branches is for.
>> I find this quite descriptive:
>> > For CloudStack we also keep working on prior releases and ship out
>> > maintenance releases.
>> > I suppose we will be cutting the maintenance releases from the release
>> > branches? So we will have to keep around the release branches for that
>> > purpose.
>> >
>> >
>> I've asked earlier, but what is the policy on old releases? How long do we
>> support them?
> Today (e.g. subject to change) we claim to support as a community the two
> most recent feature releases. (for instance, we just stopped support the
> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and
> 4.4.x) We support those feature releases with bug fix releases that contain
> no additional functionality.
> --David


View raw message