A git workflow change will not solve the quality problems we have. They
have to be dealt with independently. Just because we are changing the way
we commit the code doesnt mean we wont have any quality issues introduced
by the commits. It just ensures that issues/fixes are properly transferred
to
I see a lot of confusion around the fact that the name of gitflow is
being used. What was proposed was a model that could be supported by
the tool gitflow, not a workflow exactly as gitflow 'prescribes' it.
If we forget about gitflow for a moment and look at the branching
model that we want we all
Hi all,
Let’s end this discussion thread.
I asked Vincent (nvie) and some friends from google and facebook on this and
all of them recommended that this is not for us; then I read the whole thread
again without prejudice or ego and I think it’s not for us though we should
pick up couple of
3 it should be made in a hotfix/4.4-jira number branch and reviewed
and merged from there
On Fri, Aug 8, 2014 at 9:16 AM, Rajani Karuturi raj...@apache.org wrote:
A git workflow change will not solve the quality problems we have. They
have to be dealt with independently. Just because we are
Rohit, this is not a git-flow or gitflow discussion. It seems to be at
times but it is not. It is a discussion about how to branch in our
repository. That discussion should not end, but maybe so in this
thread.
On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
Hi all,
Hi,
Vincent (nvie) has allowed me to share his email publicly, here you go:
Hi Rohit,
Thanks for reaching out. I don't think git-flow suits your use case very well.
Git flow was mainly optimized as a set of rules to help bring forth
forward-only releases, and does not support multiple
This sounds like an end goal that we shouldn't try to reach in one go.
Let's take baby steps.
On Fri, Aug 8, 2014 at 1:28 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
Hi,
Vincent (nvie) has allowed me to share his email publicly, here you go:
Hi Rohit,
Thanks for reaching out. I
Rohit,
Thank you to bring this to a end.
Finally handling multiple maintenance release is recognized as an issue in
this model.
--Sheng
On Fri, Aug 8, 2014 at 4:28 AM, Rohit Yadav rohit.ya...@shapeblue.com
wrote:
Hi,
Vincent (nvie) has allowed me to share his email publicly, here you go:
Hey Rohit,
On Aug 6, 2014, at 9:08 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
The proposal thread warriors Rajani, Daan, Leo and others can comment and
advise [on git flow]?
Hah, “thread warrior, I like that :-)
Cloudstack right now has, erm, some challenges when it comes to continuous
(Like most of the internet...) I strongly believe using cherry picks as the
basic
tool for (release) branch management is one of the worst choices you can
make.
But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1]
[Animesh] Leo I don't mind moving to merging branches rather
Animesh, cherry-picking from a single branch will cause conflicts in
the long run (of two to three months) so it is a major problem with
the way we release now. Also it will add the code and I was not
convinced that merging was better until Leo showed me a history graph
as example. With merging a
On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi animesh.chaturv...@citrix.com
wrote:
(Like most of the internet...) I strongly believe using cherry picks as the
basic
tool for (release) branch management is one of the worst choices you can
make.
But. Please. Can. We. Just. Stop. Cherry.
On Aug 6, 2014, at 7:15 PM, David Nalley da...@gnsa.us wrote:
On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Edison, thank you for raising the concern about the BVT/CI. Somebody
mentioned earlier that we should separate git workflow implementation from
Here is where we stand:
1-We have a successful VOTE that got derailed after the voting period ended
with a few -1
- Since we should have a strong consensus on this that means that the VOTE is
canned and folks who want a change are send back to the drawing board.
2-The main concerns I can see
Hey,
On 07-Aug-2014, at 9:22 am, Leo Simons lsim...@schubergphilis.com wrote:
On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi
animesh.chaturv...@citrix.com wrote:
(Like most of the internet...) I strongly believe using cherry picks as the
basic
tool for (release) branch management is one
I am not for grand proposals so I don't agree that we should first
make an inventory of all problems. The idea that we are going to do CI
on a staging branch I take for a fact for the moment. Given that I
would like to propose that we:
proposal version='future'
work on a 'development' branch.
, Stable will have the new Release code
A similar approach was discussed in the wikis/blogs shared by Rajani and Sheng.
Thanks,
Raja
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: Thursday, August 07, 2014 2:03 PM
To: dev
Subject: Re: [VOTE] git workflow
I am
/address the stability issue completely.
Thanks,
Raja
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: Thursday, August 07, 2014 2:46 PM
To: dev
Subject: Re: [VOTE] git workflow
Raja,
On Thu, Aug 7, 2014 at 11:03 AM, Raja Pullela raja.pull...@citrix.com wrote
On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen run...@gmail.com wrote:
On Aug 6, 2014, at 7:15 PM, David Nalley da...@gnsa.us wrote:
On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Edison, thank you for raising the concern about the BVT/CI. Somebody
, Edison Su edison...@citrix.com wrote:
-Original Message-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol
[mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
alena.prokharc...@citrix.com
-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
...@citrix.com wrote:
-Original Message-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed
@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Agree with you, Rohit. The changes to the git model we use, are
needed indeed. But we should
On Aug 7, 2014, at 8:33 AM, David Nalley da...@gnsa.us wrote:
On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen run...@gmail.com wrote:
On Aug 6, 2014, at 7:15 PM, David Nalley da...@gnsa.us wrote:
On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
On 8/7/14, 1:42 PM, Sebastien Goasguen run...@gmail.com wrote:
On Aug 7, 2014, at 8:33 AM, David Nalley da...@gnsa.us wrote:
On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen run...@gmail.com
wrote:
On Aug 6, 2014, at 7:15 PM, David Nalley da...@gnsa.us wrote:
On Wed, Aug 6, 2014 at
:
-Original Message-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014
On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
On 8/7/14, 1:42 PM, Sebastien Goasguen run...@gmail.com wrote:
On Aug 7, 2014, at 8:33 AM, David Nalley da...@gnsa.us wrote:
On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen run...@gmail.com
wrote:
On Thu, Aug 7, 2014 at 10:44 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Daan, thank you. Please see my comments inline.
On 8/7/14, 1:19 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:
On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Any process is better than what is being used right now.
git-flow is just a proven process that is working for folks who use it.
That is a fact.
git-flow somewhat enforces a process, especially if you use the git-flow
plugin:
git flow feature start 2345-eye-candy
git flow feature publish etc,
Erik, addressing What's the downside of having master represent the
latest released version?²
No real downside (rather than the pain when it comes to managing
maintenance releases for earlier versions of CS), but what are the
advantages really?
If you are the user who wants to get the latest
Sebastian, addressing the following comment of yours
The main issue with master right now is that it moves really fast as a
shared branch, people merge features without warning, we see regressions
etc..
By the time we release a major version, master has moved so much that it
feels like starting
This is what I was wondering about, as well. It seems all of our 'master'
problems become 'develop' problems.
I do like the idea of merging versus cherry picking (as a general rule),
though.
On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Sebastian,
I am just wondering if the shift to a new develop branch is causing the
problems. Its a simple branch shift and should be no different from the current
master.
may be we should leave the master as is and create a ‘stable' branch which
would act like master in git-flow ?
ie)
ACS master -
Exactly Rajani, and other solutions are possible. The issue is not how
branches are called ;)
On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi
rajani.karut...@citrix.com wrote:
I am just wondering if the shift to a new develop branch is causing the
problems. Its a simple branch shift and should
frequent we can planning to merge from develop to master ? during
release ?
Regards,
Rayees
-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com]
Sent: Tuesday, August 05, 2014 11:51 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow
Sorry
On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
Hi,
Comments in-line;
On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
Rayees,
I think you have the same misunderstanding as a lot of other folks
(including myself) had
To me this pretty much ties in to the discussion about the simulator and the
BVT/CI suite. This works very neatly with the work Alex has been doing and his
proposal on how to deal with the BVT test suite.
His original proposal was about constantly checking master and reverting any
commits that
Hi David,
On 06-Aug-2014, at 4:10 pm, David Nalley da...@gnsa.us wrote:
On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
Hi,
Comments in-line;
On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Rayees,
I think you have the
On Wed, Aug 6, 2014 at 10:53 AM, Hugo Trippaers h...@trippaers.nl wrote:
To me this pretty much ties in to the discussion about the simulator and the
BVT/CI suite. This works very neatly with the work Alex has been doing and
his proposal on how to deal with the BVT test suite.
His original
: Prachi Damle [mailto:prachi.da...@citrix.com]
Sent: Tuesday, August 05, 2014 11:51 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow
Sorry if this is already discussed, but few areas that are unclear to
me
with this process are:
- does every fix, however minor it be(say
Why implement something that doesn¹t serve any practical purpose for CS??
We should adopt only things that would address current CS problems -
regressions, unstable releases, etc. That would mean - running the
automation (CI, BVT) on *develop branch, cut the *fix branches for hot
On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
Why implement something that doesn¹t serve any practical purpose for CS??
We should adopt only things that would address current CS problems -
regressions, unstable releases, etc. That would mean - running the
Rohit, thank you for the explanation. So we cut the maintenance release
from the master branch, not *develop as opposed to the major release
branch.
One more open question. Its clear that we cut the maintenance release from
the master branch, but what would be the right way to merge it back if
Hi,
On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
Rohit, thank you for the explanation. So we cut the maintenance release
from the master branch, not *develop as opposed to the major release
branch.
One more open question. Its clear that we cut the
Rohit, whatever you say below, just proves our original worry about
handling the maintenance minor releases (see my comments below). We can’t
possibly adopt the way where release branches get removed since we always
support maintenance releases for multiple versions at a time: 4.2.1,
4.3.1, 4.4.1.
On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
Hi,
On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
Rohit, thank you for the explanation. So we cut the maintenance release
from the master branch, not *develop as opposed to the
On 8/6/14, 11:22 AM, David Nalley da...@gnsa.us wrote:
On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav rohit.ya...@shapeblue.com
wrote:
Hi,
On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Rohit, thank you for the explanation. So we cut the maintenance release
Hi,
If it was not clear, let me re-state — just because I’m participating in this
thread does not mean I fully support git-flow, or I am here to defend it.
The proposal thread warriors Rajani, Daan, Leo and others can comment and
advise?
I like couple of good ideas in it, and I think it’s
Agree with you, Rohit. The changes to the git model we use, are needed
indeed. But we should address only the problems that CS faces, and the
main problem - quality control. The proposal should be limited just to the
changes that are really needed for the CS, and that will work with the
current CS
On Wed, Aug 6, 2014 at 7:30 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Rohit, thank you for the explanation. So we cut the maintenance release
from the master branch, not *develop as opposed to the major release
branch.
Here's what happens if you want to create a support (ie
Once you merge release branch it on master/stable branch, you don’t lose
commit if you delete it. It’s like removing a feature branch once it’s
merged on master/target branch.
Correct. At t his point your release is in master. If you need to bug
fix, you checkout that tag from master.
Also, as
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Agree with you, Rohit. The changes to the git model we use, are needed
indeed. But we should address only the problems that CS faces, and the
main problem - quality control. The proposal should be limited
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Agree with you, Rohit. The changes to the git model we use, are needed
indeed. But we should address only the problems that CS faces, and the
Alena,
I think this is a matter of semantics. If you call the latest version
that got through the CI a pre-release and add them as releases in the
git-flow way of working on master you've got what you envision.
In spite of my mail this morning I am not a warrior (though I like the
compliment,
-Original Message-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21
Daan, thank you for the summary. See my answers below.
On 8/6/14, 1:59 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:
Alena,
I think this is a matter of semantics. If you call the latest version
that got through the CI a pre-release and add them as releases in the
git-flow way of working on
[mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Agree
:
-Original Message-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21
/14, 2:30 PM, Edison Su edison...@citrix.com wrote:
-Original Message-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol
-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Agree with you, Rohit. The changes to the git model we
-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: Wednesday, August 06, 2014 3:23 PM
To: dev@cloudstack.apache.org
Cc: Edison Su
Subject: Re: [VOTE] git workflow
On Aug 6, 2014, at 6:13 PM, Prachi Damle prachi.da...@citrix.com wrote:
Edison, thank you
-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: Wednesday, August 06, 2014 3:19 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
[top posting, apologies in advance]
I am on vacation, so I will go straight to it :)
This all
On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
alena.prokharc...@citrix.com wrote:
Edison, thank you for raising the concern about the BVT/CI. Somebody
mentioned earlier that we should separate git workflow implementation from
the CI effort, but I do think we have to do in in conjunction.
I am not advocating that we should follow git-flow.
If you see my original [proposal], it has no mention of git-flow. I just
felt that we are abusing git and put some points which could help us
improve.
Git-flow is something which I liked and felt that it would make us treat
git well.
I am okay
-
From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
Sent: Wednesday, August 06, 2014 12:59 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
but the issues that we have shift to
develop branch.
-Original Message-
From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
Sent: Thursday, July 31, 2014 3:28 AM
To: dev
Subject: [VOTE] git workflow
Hi All,
We had long discussions on the git flow.
I tried to capture
Exactly. This just shifts pain from one branch to another.
I don't see any gains from this, either.
I vote -1.
Jessica
-Original Message-
From: Min Chen [mailto:min.c...@citrix.com]
Sent: Tuesday, August 05, 2014 11:27 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
this until all processes are
clear.
Prachi
-Original Message-
From: Jessica Wang [mailto:jessica.w...@citrix.com]
Sent: Tuesday, August 05, 2014 11:33 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow
Exactly. This just shifts pain from one branch to another.
I don't see
on this. We should not start implementing this until all processes
are clear.
Prachi
-Original Message-
From: Jessica Wang [mailto:jessica.w...@citrix.com]
Sent: Tuesday, August 05, 2014 11:33 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow
Exactly. This just
-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com]
Sent: Tuesday, August 05, 2014 11:51 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow
Sorry if this is already discussed, but few areas that are unclear to me
with this process are:
- does every fix, however
, 2014 11:51 AM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow
Sorry if this is already discussed, but few areas that are unclear to me
with this process are:
- does every fix, however minor it be(say a signle line), needs to be
developed in a separate branch? And then we have
: [VOTE] git workflow
Agree with Animesh. Didn't see any gains from this, we just shift pain
from one branch to another, so vote -1.
-min
On 8/2/14 9:50 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com
wrote:
+0
While this protects master with only commits which are merges from
.
Thanks,
Prachi
-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: Tuesday, August 05, 2014 2:56 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On Aug 5, 2014, at 2:33 PM, Jessica Wang jessica.w...@citrix.com wrote:
Exactly. This just shifts
@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On Aug 5, 2014, at 2:33 PM, Jessica Wang jessica.w...@citrix.com wrote:
Exactly. This just shifts pain from one branch to another.
I don't see any gains from this, either.
I vote -1.
It is much more than shifting pains, the wiki page
On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber terbol...@gmail.com wrote:
On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle prachi.da...@citrix.com
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
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
hindsight;
The argument of Animesh that we are shifting the
+1
On Thu, Jul 31, 2014 at 5:28 AM, Rajani Karuturi rajani.karut...@citrix.com
wrote:
Hi All,
We had long discussions on the git flow.
I tried to capture the summary of it @
http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @
@cloudstack.apache.org dev@cloudstack.apache.org
Subject: RE: [VOTE] git workflow
+0
While this protects master with only commits which are merges from release
branch and keeps it clean but the issues that we have shift to develop branch.
-Original Message-
From: Rajani Karuturi
and keeps it clean but the issues that we have shift to develop branch.
-Original Message-
From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
Sent: Thursday, July 31, 2014 3:28 AM
To: dev
Subject: [VOTE] git workflow
Hi All,
We had long discussions on the git flow.
I tried
There were 17 votes on the proposal
+1 15 people
+0 2 people
-1 none
Thanks everyone for participating.
The only open question I see in the thread is about hot fix branch naming
convention.
Since there aren’t any major concerns and the vote has passed, I believe we
should start adopting to
Subject: [VOTE] git workflow
Hi All,
We had long discussions on the git flow.
I tried to capture the summary of it @
http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
ProposedGitflowbasedCheck-inProcess
+1
On 31 Jul 2014 21:33, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
+1 on the proposal. But I second Rohit and Sheng Yang - we should agree on
all the flow points before we adopt it for CloudStack. We can¹t just
blindly follow http://nvie.com/posts/a-successful-git-branching-model/,
From: Sheng Yang [mailto:sh...@yasker.org]
Work need to be tested, but create one branch for every bug seems over doing.
Branch in Git suppose to use with substantial changes.
Actually, I don't agree with you on that point. I think git is unusual among
source control systems in that the git
Hi,
On 01-Aug-2014, at 1:59 am, Sheng Yang sh...@yasker.org wrote:
Work need to be tested, but create one branch for every bug seems over
doing. Branch in Git suppose to use with substantial changes. I don't think
anyone would like the idea to have 2 commits for every bug fixes(one merge
On 01-Aug-2014, at 1:40 am, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
Thank you, Rohit. Couple more things we have to clarify in the wiki. The
doc says Developer should run the BVT on the simulator before doing a
checkin², but it doesn¹t mention anything about the CI. So here are
+1
On CI, I think it should run on any branch that wants to maintain quality.
So master, develop, releases, hotfixes, and support. It would be awesome if
I could elect to have my random other branches run CI as well, but my guess
is that we would need more hardware to pull that off. Hopefully
On Aug 1, 2014, at 10:30 AM, Nate Gordon nate.gor...@appcore.com wrote:
+1
On CI, I think it should run on any branch that wants to maintain quality.
So master, develop, releases, hotfixes, and support. It would be awesome if
I could elect to have my random other branches run CI as well,
-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: Friday, August 01, 2014 7:42 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] git workflow
On Aug 1, 2014, at 10:30 AM, Nate Gordon nate.gor...@appcore.com
wrote:
+1
On CI, I think
Hi All,
We had long discussions on the git flow.
I tried to capture the summary of it @
http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
and is up for a vote:
Can you share
Rajani,
To make it clear for everyone. This is the vote to adopt this new way of
working right? Or is it just to get an opinion on the proposal?
If it is indeed the vote to adopt this way of working it means that all
committers will change how we interact with the branches in the CloudStack
+1
On Thu, Jul 31, 2014 at 12:28 PM, Rajani Karuturi
rajani.karut...@citrix.com wrote:
Hi All,
We had long discussions on the git flow.
I tried to capture the summary of it @
http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @
+1
Hugo, I think we started this voting thread to get opinion on the proposal. I
feel it may need some iteration and community agreement before we adopt it.
Suggestions, flames and opinions are welcome.
Regards.
On 31-Jul-2014, at 12:43 pm, Hugo Trippaers h...@trippaers.nl wrote:
Rajani,
Hi Hugo,
Its mainly to get an opinion on the proposal.
I am expecting all the active committers to take a look at it and raise any
concerns they have.
If we don’t get any -1’s or edits, we should start on it.
Post voting, if its approved, we should do the required git branch changes as
+1
PL
On Thu, Jul 31, 2014 at 7:40 AM, Rajani Karuturi rajani.karut...@citrix.com
wrote:
Hi Hugo,
Its mainly to get an opinion on the proposal.
I am expecting all the active committers to take a look at it and raise
any concerns they have.
If we don’t get any -1’s or edits, we should
On Jul 31, 2014, at 12:28 PM, Rajani Karuturi rajani.karut...@citrix.com
wrote:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess
...
is up for a vote:
+1
- Leo
+1 from me.
--
Stephen Turner
-Original Message-
From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
Sent: 31 July 2014 11:28
To: dev
Subject: [VOTE] git workflow
Hi All,
We had long discussions on the git flow.
I tried to capture the summary of it @
http://markmail.org
+1 on the proposal
Cheers,
Hugo
On 31 jul. 2014, at 14:31, Stephen Turner stephen.tur...@citrix.com wrote:
+1 from me.
--
Stephen Turner
-Original Message-
From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
Sent: 31 July 2014 11:28
To: dev
Subject: [VOTE] git
[mailto:rajani.karut...@citrix.com]
Sent: 31 July 2014 11:28
To: dev
Subject: [VOTE] git workflow
Hi All,
We had long discussions on the git flow.
I tried to capture the summary of it @
http://markmail.org/message/j5z7dxjcqxfkfhpj
This is updated on wiki @
https://cwiki.apache.org
1 - 100 of 113 matches
Mail list logo
