On Thu, Jul 31, 2014 at 12:55 AM, Leo Simons
wrote:
> On Jul 31, 2014, at 12:55 AM, Sheng Yang 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/
On Jul 31, 2014, at 12:55 AM, Sheng Yang 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 model, when one
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 c
On Wed, Jul 30, 2014 at 1:21 AM, Leo Simons
wrote:
> On Jul 30, 2014, at 1:14 AM, Sheng Yang 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 n
On Wed, Jul 30, 2014 at 12:37 AM, Sebastien Goasguen
wrote:
>
> On Jul 29, 2014, at 8:40 PM, Sheng Yang 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
On Jul 30, 2014, at 1:14 AM, Sheng Yang 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 MASTER.
> 3. I b
On Jul 29, 2014, at 8:40 PM, Sheng Yang 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 wise man
tol
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 wrote:
> Hi Leo,
>
> I am afraid the answer is too generic. We'd better look into details to
>
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
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
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 need
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
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
maintain
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 ne
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 ye
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
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 propos
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
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 s
On 7/29/14, 11:05 AM, "Nate Gordon" 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 do some significan
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
nee
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 t
On Tue, Jul 29, 2014 at 1:42 PM, Sebastien Goasguen 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
On Jul 29, 2014, at 4:01 AM, Daan Hoogland wrote:
> On Tue, Jul 29, 2014 at 5:45 AM, Sheng Yang 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 earlier) It is about time to take ste
On Tue, Jul 29, 2014 at 5:45 AM, Sheng Yang 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 earlier) It is about time to take steps as we are at
4.5 freeze time.
--
Daan
On Jul 29, 2014, at 5:45 AM, Sheng Yang 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 issue with
47 PM, Stephen Turner
> 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
> >
nt: 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 that most people may not have.
> We want to start working differently with respect to our release procedure
> a
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 that
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 explain
Hi,
This thread summarizes gitflow and the git process talk Rajani shared
with us in the other thread:
http://markmail.org/message/4hk2jwvxt4lcpqig
This is what Rajani shared during the end of the thread:
http://markmail.org/message/2642ilfajkpshnfn
After reading 58 emails on the orig
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 a
I am not for a grand proposal but ok, I can live with it.
It would be easiest to just vote for using the gitflow model.
Leo is preparing a page on how to do it. I don't know what the status
is on it. The vote for my part would be on the contents of that page.
On Mon, Jul 28, 2014 at 4:03 PM, Mike
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 wrote:
> Agreed, this kind of important decisions should be made by a vote.
>
> Sebastien, Daan, can one of you kick of the vote thread? Preferably
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 wrote:
> +1 to what Erik said.
>
>
> On 28 July 2014 13:04, Eri
+1 to what Erik said.
On 28 July 2014 13:04, Erik Weber wrote:
> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland
> 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
On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland
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
> largely ignored by th
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
38 matches
Mail list logo
