On Jul 31, 2014, at 12:55 AM, Sheng Yang sh...@yasker.org wrote:
I suppose it would work like this:
1. In the original model, every release branch would be deleted after merge
into develop and master branch. There is no release/4.4.1 or release/4.5
branch.
2. Say we don't follow original
On Thu, Jul 31, 2014 at 12:55 AM, Leo Simons lsim...@schubergphilis.com
wrote:
On Jul 31, 2014, at 12:55 AM, Sheng Yang sh...@yasker.org wrote:
I suppose it would work like this:
1. In the original model, every release branch would be deleted after
merge
into develop and master branch.
On Jul 29, 2014, at 8:40 PM, Sheng Yang sh...@yasker.org wrote:
And talking about to achieve good code quality, I think compulsive review
and testing through some kind of automation system is much more helpful.
--Sheng
This new git workflow is not directly about good code quality, as a
On Jul 30, 2014, at 1:14 AM, Sheng Yang sh...@yasker.org wrote:
The issue with current development process?
1. Cherry-pick is needed for RM to choose stable fix commit after code
freeze to enforce quality.
2. Bug fix to current release branch need to be checked in both release
branch and
On Wed, Jul 30, 2014 at 12:37 AM, Sebastien Goasguen run...@gmail.com
wrote:
On Jul 29, 2014, at 8:40 PM, Sheng Yang sh...@yasker.org wrote:
And talking about to achieve good code quality, I think compulsive review
and testing through some kind of automation system is much more helpful.
On Wed, Jul 30, 2014 at 1:21 AM, Leo Simons lsim...@schubergphilis.com
wrote:
On Jul 30, 2014, at 1:14 AM, Sheng Yang sh...@yasker.org wrote:
The issue with current development process?
1. Cherry-pick is needed for RM to choose stable fix commit after code
freeze to enforce quality.
2.
4. Then, conflict would happen when you merge release/4.4. branch to
release/4.5. Since the version number changed to 4.4.1. You need to deal
with version number conflict every time when merge to upper release.
one empty merge with git merge -s ours after the version change and git would
not
On Jul 29, 2014, at 5:45 AM, Sheng Yang sh...@yasker.org wrote:
I am trying to catch up, by reading the thread and checking what's gitflow
etc, but could someone already familiar with the topic give an overview of
the issue?
For example, we can start by asking these questions:
1. What's the
On Jul 29, 2014, at 4:01 AM, Daan Hoogland daan.hoogl...@gmail.com wrote:
On Tue, Jul 29, 2014 at 5:45 AM, Sheng Yang sh...@yasker.org wrote:
I found the discussion mostly took place later
last week.
Yes, but it was started by Rajani at May 30th (and I think it was
mentioned even
On Tue, Jul 29, 2014 at 1:42 PM, Sebastien Goasguen run...@gmail.com wrote:
'pain in the #$%#$%' and revert commits to master that don't follow the new
process.
You bet I am/will be
I expect that it will take a big of time
pun not intended, i suppose
--
Daan
I have one more question in addition to what Sheng asked. Document
http://nvie.com/posts/a-successful-git-branching-model/ mentions that the
*hotfix branch should be created for the blocker/critical bugs in the
current production release. What about bugs happenning in the *release
branch (the one
This might be somewhere that we can extend the basic concept of gitflow. If
there are trivial fixes (I forgot an edge case in an if statement), it
probably isn't necessary to branch the release and merge back, but if you
need to do some significant work (I broke one of the other hypervisors and
On 7/29/14, 11:05 AM, Nate Gordon nate.gor...@appcore.com wrote:
This might be somewhere that we can extend the basic concept of gitflow.
If
there are trivial fixes (I forgot an edge case in an if statement), it
probably isn't necessary to branch the release and merge back, but if you
need to
For what it's worth, I support the move to a git-flow project layout. It
seems to have a more sensible structure than what ACS currently has,
although I'm not going to say that ACS's current structure has not been
sufficient, just that it simply seems to be the time for change. The
git-flow model
I think it would be good if the bug fixes are delivered to the Release
branch only if they are found in that particular Release. But if there are
any productions fixes then a new hot fix branch should be cut out of Master
and once the changes are made and released, the branch should be merged
back
I would rather say that the bug fix branch should be cut from *developer
branch, not master, then merged to *developer upon fixing so all the tests
are run for the fix. Only after tests pass, the merge to master from
developer should be done. If the bug doesn’t require branching out (see
the
This seems like a reasonable use scenario, but is it not what the article
located at @ http://nvie.com/posts/a-successful-git-branching-model/
already describes?
On Tue, Jul 29, 2014 at 1:45 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
I would rather say that the bug fix branch
Tanner,
My question was about bugs happening not in production (the branch that is
already released). For those hot fix branches are needed - and that
described in the article. My question was about new bugs happening either
in the *developer branch or *release branch that hasn’t been released
Ah. I simply misunderstood. That sounds very reasonable to me.
On Tue, Jul 29, 2014 at 1:59 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Tanner,
My question was about bugs happening not in production (the branch that is
already released). For those hot fix branches are needed
If a bug fix branch is cut off from Develop branch then all the current
changes like new feature merges, new enhancement/development of a future
release will also get merged to Master branch instead of a Release branch
once the bug fix branch is merged. Our motto about keeping Master is to
My understanding is - we should always merge the fixes to both *develop
and *master branches. Merging to develop branch should be mandatory as
that’s the place where automatic nightly builds + the regression tests are
run against. That’s what the article from Daan’s email says:
Master branch: We
I'm not sure this applies to hotfixes to previous versions, ie. not the
current master release.
The hotfix might not code wise apply to the current develop/master at all.
Assume that we one year from now, after releasing 4.5 and 4.6 using
gitflow, and are working towards a 4.7 in develop, we
I think the general rule for fixes is to branch from where the bug is. If
the bug is in prod, branch from master. If the bug is in the release
process, branch from the release branch. If the bug is in development,
branch from development. The previous comment about pulling dev code into
master via
Hi Leo,
I am afraid the answer is too generic. We'd better look into details to see
what's the exactly problem.
So I am trying to sort it out.
The first question we want to ask is:
A. What's current develop process?
I don't know where is it documented, but as I know, it works like
this(please
And talking about to achieve good code quality, I think compulsive review
and testing through some kind of automation system is much more helpful.
--Sheng
On Tue, Jul 29, 2014 at 4:14 PM, Sheng Yang sh...@yasker.org wrote:
Hi Leo,
I am afraid the answer is too generic. We'd better look into
H,
I see a lot of commits happening directly on the master branch. Yet
there were no counter arguments against the proposed gitflow and the
discussion around it. This leaves me with the idea that the thread is
largely ignored by the community. It is my understanding that we
agreed never to commit
On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
H,
I see a lot of commits happening directly on the master branch. Yet
there were no counter arguments against the proposed gitflow and the
discussion around it. This leaves me with the idea that the thread is
+1 to what Erik said.
On 28 July 2014 13:04, Erik Weber terbol...@gmail.com wrote:
On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
H,
I see a lot of commits happening directly on the master branch. Yet
there were no counter arguments against the proposed
Agreed, this kind of important decisions should be made by a vote.
Sebastien, Daan, can one of you kick of the vote thread? Preferably with a
condensed summary of the thread?
Cheers,
Hugo
On 28 jul. 2014, at 14:07, Ian Duffy i...@ianduffy.ie wrote:
+1 to what Erik said.
On 28 July
Yeah, I was under the impression this decision would require a vote and
formal announcement, if it passes.
On Monday, July 28, 2014, Hugo Trippaers h...@trippaers.nl wrote:
Agreed, this kind of important decisions should be made by a vote.
Sebastien, Daan, can one of you kick of the vote
Let me explain a little more about this lat mail of mine.
I was assuming a lot of context that most people may not have.
We want to start working differently with respect to our release
procedure and branching habits. The proposals that are out there and
about to be voted for are going to require
Hi Daan,
We've a page on Git [1] and recommended workflow for committers and
non-committers, should we update the workflow we want for committers
there and start a separate vote thread?
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git
Regards.
Daan Hoogland wrote:
Let me
I am +1 on the principle.
--
Stephen Turner
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 28 July 2014 16:08
To: dev
Subject: Re: [DISCUSS] git commit proces
Let me explain a little more about this lat mail of mine.
I was assuming a lot of context
:08
To: dev
Subject: Re: [DISCUSS] git commit proces
Let me explain a little more about this lat mail of mine.
I was assuming a lot of context that most people may not have.
We want to start working differently with respect to our release procedure
and branching habits. The proposals
...@citrix.com wrote:
I am +1 on the principle.
--
Stephen Turner
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 28 July 2014 16:08
To: dev
Subject: Re: [DISCUSS] git commit proces
Let me explain a little more about this lat mail of mine.
I
35 matches
Mail list logo
