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
wrote:
> Hi,
>
> Vincent (nvie) has allowed me to share his email publicly, here you go:
>
> "
> Hi Rohit,
>
> Th
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 wrote:
> 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
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 conc
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 wrote:
> Hi all,
>
> Let’s end this discus
3 it should be made in a hotfix/4.4- branch and reviewed
and merged from there
On Fri, Aug 8, 2014 at 9:16 AM, Rajani Karuturi wrote:
> 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 t
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 goo
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
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 t
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, ad
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
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 st
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, e
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" wrote:
>
> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
> > wrote:
> >> Plus if you read the discussion below
On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
wrote:
>
>
> On 8/7/14, 1:42 PM, "Sebastien Goasguen" wrote:
>
>>
>> On Aug 7, 2014, at 8:33 AM, David Nalley wrote:
>>
>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen
>>> wrote:
On Aug 6, 2014, at 7:15 PM, David Nalley wr
thing - when
> >>>>>master
> >>>>> reflects the latest stable release with the tags for all previous
> >>>>>releases
> >>>>> - because support maintenance releases for multiple CS versions in
> >>>>> parallel. And while master
On 8/7/14, 1:42 PM, "Sebastien Goasguen" wrote:
>
>On Aug 7, 2014, at 8:33 AM, David Nalley wrote:
>
>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen
>>wrote:
>>>
>>> On Aug 6, 2014, at 7:15 PM, David Nalley wrote:
>>>
On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
wrote
>>
>>>>> The model when master reflects the latest released branch, can be
>>>>>used
>>>>>for
>>>>> the systems with rolling upgrades only, no maintenance releases for
>>>>> previous versions of the software.
>>>>>
On Aug 7, 2014, at 8:33 AM, David Nalley wrote:
> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen wrote:
>>
>> On Aug 6, 2014, at 7:15 PM, David Nalley wrote:
>>
>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>> wrote:
Edison, thank you for raising the concern about the BVT/
gt;>>> >
>>>> >-Release: from the time a release branch is cut, features are only
>>>>merged
>>>> >by RM. hot fixes are only merged by RM. the RM is responsible for the
>>>> >entire release process. Since he defines the scope and
and call the RM for a merge into a release branch
>>> >(this may vary with gitflow, where release branch is cut from develop)
>>> >
>>> >Once we have CI, it should run on every branch.
>>> >
>>> >-sebastien
>>> >
>>> &g
On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
>> > wrote:
>> >
>> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
>> >> mentioned earlier that we should separate git workflow implementation
>> >>from
>>
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.
> Otherwis
oducing staging/develop branch? If there is no
> >> daily automation run verifying all the code merged from hotFixes/feature
> >> branches (and possibly reverting wrong checkins), we can as well merge
> >>the
> >> code directly to master.
> >>
> >>
On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen wrote:
>
> On Aug 6, 2014, at 7:15 PM, David Nalley wrote:
>
>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>> wrote:
>>> Edison, thank you for raising the concern about the BVT/CI. Somebody
>>> mentioned earlier that we should separate gi
not solve/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 wrote:
> If
Raja,
On Thu, Aug 7, 2014 at 11:03 AM, Raja Pullela wrote:
> If we are using "Development" branch as a shadow branch for "Stable" - is not
> worth going that route because the existing automation may not find all the
> issues. As a result, "Stable" is not completely protected from breakage or
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 not for grand proposals so I don't agree that we shou
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:
work on a 'development' branch.
merge on a nightly basis to a
Hey,
On 07-Aug-2014, at 9:22 am, Leo Simons wrote:
> On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi
> 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.
>>>
>>>
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 f
On Aug 6, 2014, at 7:15 PM, David Nalley wrote:
> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> 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
On Aug 7, 2014, at 8:40 AM, Animesh Chaturvedi
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. Picking!!! :-D [1]
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 l
>
> (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 r
Hey Rohit,
On Aug 6, 2014, at 9:08 PM, Rohit Yadav 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
integration and produ
ntioned earlier that we should separate git workflow implementation
> >>from
> >> the CI effort, but I do think we have to do in in conjunction.
Otherwise
> >> what is the point in introducing staging/develop branch? If there is no
> >> daily automation run ver
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
On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
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. Otherwise
> what is the poin
> -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
-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 wrote:
>
>> Edison, thank you for raising th
checkins), we can as well merge
>>the
>> code directly to master.
>>
>> -Alena.
>>
>> On 8/6/14, 2:30 PM, "Edison Su" wrote:
>>
>>>
>>>
>>>> -Original Message-
>>>> From: Alena Prokharchyk [
ree, we may want to add others)
> Thanks,
> Prachi
>
> On 8/6/14, 2:30 PM, "Edison Su" wrote:
>
>>
>>
>>> -Original Message-
>>> From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
>>> Sent: Wednesday, Augus
>
> -Alena.
>
> On 8/6/14, 2:30 PM, "Edison Su" wrote:
>
>>
>>
>>> -Original Message-
>>> From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
>>> Sent: Wednesday, August 06, 2014 12:59 PM
>>> To: dev@cloudstac
s,
Prachi
On 8/6/14, 2:30 PM, "Edison Su" 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
rchyk [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" wrote:
>>
>>
Daan, thank you for the summary. See my answers below.
On 8/6/14, 1:59 PM, "Daan Hoogland" 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 master you've go
> -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" 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 master you've got what you envision.
In spite of my mail this morning I am not a warrior (though I like the
compliment, Roh
On 8/6/14, 12:52 PM, "Erik Weber" 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
>> main probl
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 limite
"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, a
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 suppor
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
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 bett
On 8/6/14, 11:22 AM, "David Nalley" wrote:
>On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav
>wrote:
>> Hi,
>>
>> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
>> wrote:
>>
>>> Rohit, thank you for the explanation. So we cut the maintenance release
>>> from the master branch, not *develop as oppose
On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav wrote:
> Hi,
>
> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
> 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
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.
Hi,
On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk
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 maintenance release from
> th
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
thi
On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk
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
> automation (CI, BVT) on
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
fixes/critical/fea
nt the advantages of #2 approach over
>> #1, as to me #1 seems to be the approach most people will find more
>> intuitive and its used a lot in the field.
>>
>> -Alena.
>>
>>
>>
>> On 8/5/14, 1:22 PM, "Rayees Namathponnan"
>>
>> wrot
On Wed, Aug 6, 2014 at 10:53 AM, Hugo Trippaers 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 proposal was
Hi David,
On 06-Aug-2014, at 4:10 pm, David Nalley wrote:
> On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav wrote:
>>
>> Hi,
>>
>> Comments in-line;
>>
>> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk
>> wrote:
>>
>>> Rayees,
>>>
>>> I think you have the same misunderstanding as a lot of other f
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
On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav wrote:
>
> Hi,
>
> Comments in-line;
>
> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk
> wrote:
>
> > Rayees,
> >
> > I think you have the same misunderstanding as a lot of other folks
> > (including myself) had in the beginning - seeing develop branc
>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 if this is already discus
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
>
Good morning,
I have some difficulty believing having to type 'git checkout develop' is
enough reason for an apache committer to veto a change like this, especially
after the extensive discussions we had and all the docs we wrote.
I think people are seeing bigger problems or haven't quite under
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
wrote:
> 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
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 -> deve
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 bur
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:
>
> https:/
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:
https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
>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 wrote:
>
>> Exactly. This just shifts pain from one branch to another.
serve such use.
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 wrote:
> Exactly. This just shifts pain
vely, with several pointers that we should all take the
time to view/read:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git
> Jessica
>
>
> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: Tuesday, August 05, 2014 11:27 AM
> To
field.
>>
>> -Alena.
>>
>>
>>
>> On 8/5/14, 1:22 PM, "Rayees Namathponnan"
>> wrote:
>>
>>> How frequent we can planning to merge from develop to master ? during
>>> release ?
>>>
>>> Regards,
>>> Rayees
;Rayees Namathponnan"
>wrote:
>
>>How frequent we can planning to merge from develop to master ? during
>>release ?
>>
>>Regards,
>>Rayees
>>
>>
>>-Original Message-
>>From: Prachi Damle [mailto:prachi.da...@citrix.com]
&g
nd they would expect it to
work
Cheers.
>
>
> I am -1 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:
ot;
wrote:
>How 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.a
How 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 if
rt 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 shifts pain from one branch to anothe
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:
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"
wrote:
>+0
>
>While this protects master with only commits which are merges from
>release branch and keeps it clean but the issues that we
+1
On Thu, Jul 31, 2014 at 5:28 AM, Rajani Karuturi 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 @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
Animesh,
There will always be developers creating conflicts or not taking into
account the semantics of other peoples code. Certainly in a worldwide
project like ACS. I see your reservation. The question is if we
improve the situation by working differently. I don't know but I think
we will. More
e.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 [mailto:rajani.karut...@citrix.c
+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 [mailto:rajani.karut...@citrix.com]
> Sent: Thursday, July 31, 2014 3:28 AM
> To: de
> -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
> wrote:
>
> > +1
On Aug 1, 2014, at 10:30 AM, Nate Gordon 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, but my guess
> is th
+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 I'll
On 01-Aug-2014, at 1:40 am, Alena Prokharchyk
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 my
> questions:
>
> 1) C
Hi,
On 01-Aug-2014, at 1:59 am, Sheng Yang 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
> commit and one r
> 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 gi
+1
On 31 Jul 2014 21:33, "Alena Prokharchyk"
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/,
> plus some use cases a
On Thu, Jul 31, 2014 at 4:28 PM, Rohit Yadav
wrote:
> Comments in-line;
>
> On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
> > Done, updated the wiki page with my comments. Copy/pasting here:
> >
> > Open items:
> > 1) Which bugs can be submitted to deve
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 my
questions:
1) CI execution
* on which branches we are planning to run the CI
* wi
Comments in-line;
On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk
wrote:
> Done, updated the wiki page with my comments. Copy/pasting here:
>
> Open items:
> 1) Which bugs can be submitted to develop branch directly.
> Document http://nvie.com/posts/a-successful-git-branching-model/ mentions
> t
Sorry, ignore #2. I’ve read on the model more, and realized that master
branch would reflect the branch that has been released, not the current
release.
So only #1 is yet to be addressed.
-alena.
On 7/31/14, 2:03 PM, "Alena Prokharchyk"
wrote:
>Done, updated the wiki page with my comments. Cop
1 - 100 of 118 matches
Mail list logo
