> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Wednesday, August 20, 2014 3:15 PM
> To: dev
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
> >
> >
> > > > There are several proposals from
Edison buddy,
On 21-Aug-2014, at 1:11 am, Edison Su wrote:
> If you think I am not a good PMC members, you can start a vote to kick me
> out, if that's something you want.
You’re taking this the wrong way, it would be immature and unprofessional to
take any severe action for petty disagreement
Let’s keep this civil, folks.
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Wednesday, August 20, 2014 3:59 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
>
> On 20-Aug-2014, at 10:33 pm, Edison Su
On 20-Aug-2014, at 10:33 pm, Edison Su wrote:
> There are several proposals from Citrix:
> http://markmail.org/thread/c4pded5i3r22keqw
> http://markmail.org/thread/xoyjw2sduenlytwm
Ahem ahem, what Sebastien said. Edison, we have more expectations from PMC
members :)
Thanks to Citrix for donat
>
>
> > > There are several proposals from Citrix:
> > > http://markmail.org/thread/c4pded5i3r22keqw
> > > http://markmail.org/thread/xoyjw2sduenlytwm
> >
> > Edison, Citrix can't make proposals. Individuals do..
> Sorry, what I am trying to say is "from people, who happen to be employee
> from Cit
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Wednesday, August 20, 2014 1:47 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
>
> On Aug 20, 2014, at 4
Sent from my Windows Phone
From: Sebastien Goasguen<mailto:run...@gmail.com>
Sent: 8/20/2014 1:47 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: [VOTE] Adapting git workflow for release branches
On Aug 20, 2014
On Aug 20, 2014, at 4:33 PM, Edison Su wrote:
>
>
>> -Original Message-
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: Wednesday, August 20, 2014 1:17 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] Adapting git workflo
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Wednesday, August 20, 2014 1:17 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
>
> On 20-Aug-2014, at 9:55 pm, Edison Su
On 20-Aug-2014, at 9:55 pm, Edison Su wrote:
> Maybe I need to reiterate why I reject the proposal for now, as I am the only
> person vote -1(binding).
> I think we all understand the pain as a release manager, even right after 4.2
> release, I asked community to think about how
> We gonna fix
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Wednesday, August 20, 2014 11:42 AM
> To: dev
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
> Rohit,
>
> I don't see your count. At least Wido and
Hi Daan and Sebastien,
Thank you for your inputs.
I did not vote as I wanted to have a positive consensus before I vote for my
own proposal just to add to the counter or satisfy my ego. I understand that
the gavel is with our PMC but I would still want us to try if we can meet half
way, improv
On Aug 20, 2014, at 12:52 PM, Rohit Yadav wrote:
> Hi all,
>
> Thanks for participating. After 120 hours or 5 days, the voting result for
> the proposal is as follows:
>
> +1 (PMC / binding)
> none
>
> +1 (non binding)
> 6 people
>
> 0
> none
>
> -1 (PMC / binding)
> 1 person
>
> -1 (non
Rohit,
I don't see your count. At least Wido and I have voted +1 so that would be
+2 from the PMC. But the vote is a communitee vote. It is about techinique
not process is it. If not then non binding votes are merely for information
and only PMC votes are counted.
In cases like these I think eith
h?v=-F-3E8pyjFo
>
> Thanks
> /Sudha
>
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Wednesday, August 20, 2014 9:52 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
> Hi all,
like 80-90% of
pieces are in place. Just need community agreement.
Thanks
/Sudha
-Original Message-
From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
Sent: Wednesday, August 20, 2014 9:52 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Adapting git workflow for release branches
Hi all,
Thanks for participating. After 120 hours or 5 days, the voting result for the
proposal is as follows:
+1 (PMC / binding)
none
+1 (non binding)
6 people
0
none
-1 (PMC / binding)
1 person
-1 (non binding)
3 people
We don’t have a consensus/majority or a veto as per our bylaws; and t
On 19-Aug-2014, at 8:11 pm, Min Chen wrote:
> I personally don't think introducing CI or gerrit or github pull request
> will take away a committer's privilege to commit. If you are a stakeholder
> who really care about your product, you will not be scared away by this
> extra enforcement, this
My opinion is totally the same as Min's.
-Original Message-
From: Min Chen [mailto:min.c...@citrix.com]
Sent: Tuesday, August 19, 2014 11:12 AM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Adapting git workflow for release branches
I personally don't think introducing CI
: RE: [VOTE] Adapting git workflow for release branches
I agree with Edison.
I am -1 on this as well.
-Original Message-
From: Edison Su [mailto:edison...@citrix.com]
Sent: Saturday, August 16, 2014 12:11 PM
To: dev
Subject: RE: [VOTE] Adapting git workflow for release branches
I agree
I personally don't think introducing CI or gerrit or github pull request
will take away a committer's privilege to commit. If you are a stakeholder
who really care about your product, you will not be scared away by this
extra enforcement, this will actually make our cloudstack ecosystem better
and
tl;dr? hope you read it;
On 19-Aug-2014, at 7:10 pm, Min Chen wrote:
> I will hesitate on this "No enforcement" approach in the flow. I bet that
> without some kind of enforcement, based on past experience, after one
Stakeholder will always care. The system should be optimistic to allow things
I will hesitate on this "No enforcement" approach in the flow. I bet that
without some kind of enforcement, based on past experience, after one
release, we will come together to discuss flaw in our flow again:) Sorry
if I am too pessimistic on this.
Thanks
-min
On 8/19/14 10:00 AM, "Rohit Yadav"
Hi,
On 19-Aug-2014, at 6:48 pm, Min Chen wrote:
> In that case, we should call out this procedure
>
> If (you¹re a committer) {
> Go create a hotfix branch and ask RM to pick it up
> } else {
> Go upload your patch and get RM to review your request from reviewboard
> }
>
>
> in your proposal. I
In that case, we should call out this procedure
If (you¹re a committer) {
Go create a hotfix branch and ask RM to pick it up
} else {
Go upload your patch and get RM to review your request from reviewboard
}
in your proposal. I don't want people to have a misunderstanding that with
this proposal
Hey,
On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion wrote:
> Thanks Min for the comment, make sense.
>
> Rohit, how do we plan to managed merge request or submit one? I don't
> think using the mailing list to keep track of merge request is good, does
> https://reviews.apache.org/account/login/ is
On 19-Aug-2014, at 5:08 pm, Pierre-Luc Dion wrote:
> +1 , CI shouldn't be another topic?
>
> What is required or missing to have CI in place?
We need more servers for running Jenkins slaves on them and automation around
kicking builds for hotfixes that have a for release branches.
We can work
Thanks Min for the comment, make sense.
Rohit, how do we plan to managed merge request or submit one? I don't
think using the mailing list to keep track of merge request is good, does
https://reviews.apache.org/account/login/ is keep up to date and all merge
request should go there ?
What about
I would rather CI be considered together with this thread, since this thread
needs to decide at what condition RM can merge a hotfix/bugfic branch to
release branch.
Thanks
-min
Sent from my iPhone
> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" wrote:
>
> +1 , CI shouldn't be another topic
+1 , CI shouldn't be another topic?
What is required or missing to have CI in place?
*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683
*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w
On 19-Aug-2014, at 11:29 am, Sebastien Goasguen wrote:
> Say you grab a patch from review board and stick it in a hotfix branch, test
> that …call for merge on release branch.
> Do we *merge* to master or can we apply the patch directly to master (git am
> -s…) ?
Once the hotfix branch is merg
On Aug 19, 2014, at 5:23 AM, Rohit Yadav wrote:
>
> On 19-Aug-2014, at 10:58 am, Sebastien Goasguen wrote:
>
>> +1
>>
>> just one question (which was not clear from the email), once RM merges into
>> release branch, who merges into master ?
>
> Merging on master can be done by the RM or an
On 19-Aug-2014, at 10:58 am, Sebastien Goasguen wrote:
> +1
>
> just one question (which was not clear from the email), once RM merges into
> release branch, who merges into master ?
Merging on master can be done by the RM or any of the committers (can be even
more than once a day), the only
+1
just one question (which was not clear from the email), once RM merges into
release branch, who merges into master ?
-sebastien
On Aug 19, 2014, at 4:18 AM, Rohit Yadav wrote:
>
> On 19-Aug-2014, at 1:54 am, Min Chen wrote:
>
>> [Min] I don't quite understand why you are saying that it
On 19-Aug-2014, at 1:54 am, Min Chen wrote:
> [Min] I don't quite understand why you are saying that it won't cause
> conflicts when we do 4.2 fast-forward to 4.3 branch. What if the codebase
> in 4.3 has been changed a lot?
That was an example, yes conflicts can happen but they will be minimal
> -Original Message-
> From: Nate Gordon [mailto:nate.gor...@appcore.com]
> Sent: Monday, August 18, 2014 7:36 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
> +1 This is at least is a step in the right directio
e above will try to implement.
>>>
>>> Cheers.
>>>
>>>
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>>
>>>> On 8/18/14 10:59 AM, "Rohit Yadav" wrote:
>>>>
>>&g
Hi Edison,
in-lin;
On 18-Aug-2014, at 9:04 pm, Edison Su wrote:
> It's exactly the problem I have, I still not quite understand what's your
> intention to change the work flow?
> What's the problem you trying to solve?
> In your proposed git flow, there is no release-forward branch, only releas
>>> We have three -1s (1 binding) but none of them share valid reasons or
>>>> concerns that would point out issues and challenges with adopting the
>>>> proposed items so we¹ll continue with the voting.
>>>>
>>>> Min, Jessica, Edison ‹ I would
;> things" so we don¹t make mistake.
>>>
>>> @Rajani ‹ Thanks, but when we should cut a release branch is a
>>>different
>>> topic and IMO is per the RM¹s discretion so if you¹ve any ideas or
>>> proposals please go ahead and start a thread on tha
t;>
>> Cheers.
>>
>> On 18-Aug-2014, at 6:52 pm, Jessica Wang wrote:
>>
>>> I agree with Edison.
>>> I am -1 on this as well.
>>>
>>>
>>> -Original Message-
>>> From: Edison Su [mailto:edison...@citrix.
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Saturday, August 16, 2014 2:32 PM
> To: dev@cloudstack.apache.org
> Cc: Edison Su
> Subject: Re: [VOTE] Adapting git workflow for release branches
>
> Hi Edison,
>
> Thank
l Message-
>> From: Edison Su [mailto:edison...@citrix.com]
>> Sent: Saturday, August 16, 2014 12:11 PM
>> To: dev
>> Subject: RE: [VOTE] Adapting git workflow for release branches
>>
>> I agree with what Min said on thread:
>>http://markmail.org/message
ilto:edison...@citrix.com]
> Sent: Saturday, August 16, 2014 12:11 PM
> To: dev
> Subject: RE: [VOTE] Adapting git workflow for release branches
>
> I agree with what Min said on thread:
> http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with your
> answer:
> C
I agree with Edison.
I am -1 on this as well.
-Original Message-
From: Edison Su [mailto:edison...@citrix.com]
Sent: Saturday, August 16, 2014 12:11 PM
To: dev
Subject: RE: [VOTE] Adapting git workflow for release branches
I agree with what Min said on thread:
http://markmail.org
+1 This is at least is a step in the right direction. I don't think this
goes far enough, but I'm not going to stand in the way of making forward
progress and nothing in this proposal seems to be a bad idea.
I would also encourage those who are against this to think about if this
proposal at least
+1 for merges(no-ff) from stable to unstable.
There are pros and cons of ff and no-ff. I prefer no-ff.
-1 on frequent merges in RC stage.
IMO, we shouldn't cut a release a branch until we are reasonably sure that
we have a stable branch. Which would mean everyone working on the release.
once we cu
I am -1 on this as well. Any git process change needs to be considered
together with the quality problem we are facing now, which i believe that it is
the root cause for RM manual cherry pick issue. We cannot just adopt a process
by ignoring its root quality problem. Sorry that your answer here
Hi Edison,
Thank you for your email, I suggest you read my reply to Min’s email as well:
http://markmail.org/message/vytkbqhdjmhewonl
Let me begin by saying that perhaps I was unable to capture everyone’s
imagination with my proposal, I’ll work on my writing skills and try to keep
them short a
I agree with what Min said on thread:
http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with your
answer:
Currently we don't have a CI running continuously, no code review, it's too
risky to let developer check in whatever commit they want into release branch.
RM needs to have to
+1
On Fri, Aug 15, 2014 at 1:46 PM, Rohit Yadav
wrote:
> Thanks Wido!
>
> Let me clarify the baseline protocol or flow of change:
> When fixing a bug, you start with the oldest ACS release you want to fix
> it for say 4.2 and go on with 4.3, then 4.4 etc. until you land master,
> followed by fe
Thanks Wido!
Let me clarify the baseline protocol or flow of change:
When fixing a bug, you start with the oldest ACS release you want to fix it for
say 4.2 and go on with 4.3, then 4.4 etc. until you land master, followed by
feature/personal branches. When in doubt, use the flow which is from
On 08/15/2014 12:25 PM, Rohit Yadav wrote:
Hello everyone,
With reference to my proposal on changing our release-master commit flow [1], I
would like to start a voting thread to decide on the adoption starting 4.5
release. Any opinion, ideas, modifications is welcome to help reach a consensu
54 matches
Mail list logo
