RE: [DISCUSS] Release principles for Apache CloudStack

[Raja Pullela]

Remi, 

couple of questions on the branching part - when we take the Feature PR and 
Feature is back in Master, feel like we are potentially destabilizing Master ?  
 I know, currently we push changes to master even before anything is tested 
fully - agree, we are now running the Travis test before a checkin - however, I 
feel those are not sufficient ?  

IMHO - we should take a release branch open it up for PR/checkins and once the 
testing is done the branch gets into Master - we take RC from the master and 
release it.  That way no one checkins to master and constantly tested changes 
get into/merged to master.  

I remember seeing similar changes proposed by few folks... I have been little 
out of touch on those changes.

best,
Raja
-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org] 
Sent: Friday, July 3, 2015 8:00 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Release principles for Apache CloudStack

I do not agree to backporting aka cherry picking. I prefer forward merges(tofu 
scale) 4.4 to 4.5 to master etc.
That way, none of the changes will be missed and git branch --contains gives a 
nice view of where all the changes went.


On Thu, Jul 2, 2015 at 23:16 PM, Remi Bergsma  wrote:

Hi Daan,

Indeed. I prefer committing to master first, as it will ensure everything ends 
up there (unless some specific use cases). Currently, we have the risk of 
forgetting to include a fix to a release branch back to master.

When we reverse it, some bug fix that should end up in the x.y branch, is 
committed to master, then also applied (or reimplemented) to x.y. If you then 
only take one of the two steps, there is no issue as it will be in master only 
(and people will notice). In the other situation, when we accept a PR to x.y 
and forget to merge back, we possibly introduce regression bugs.

I will update the diagram and wiki later tonight.

While reviewing PRs, let’s be alert to see PRs not pointed towards master and 
at least discuss it.

Regards,
Remi


> On 2 jul. 2015, at 16:54, Daan Hoogland > wrote:
>
> On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma  >
wrote:
>> Since the goal is a stable master, I’d say the bug fix should go to
master first.
>
>
> Remi, this means that merge back of the branch makes no sense anymore.
>
> --
> Daan



--
-
Sent from Windows Phone
~Rajani

Re: [DISCUSS] LTS releases?

[sebgoa]

On Jul 2, 2015, at 4:58 PM, Remi Bergsma  wrote:

> Bug fixing in older releases is actually a lot of work. For security related 
> issues we could maybe do it. 
> 
> Personally, I prefer to have a fast release cycle and smooth (tested) upgrade 
> paths over 2-year LTS release cycle. It's more agile. As a bonus, people get 
> the new features. 
> 
> The more people do upgrades that work (tm) the more confident they are. I'd 
> really want to show that upgrades work so well that we need no LTS. 
> 
> But there might be other reasons people have where LTS would help. Please 
> share!
> 
> Regards, Remi 

I think we got in a situation with 4.4 that called for us to keep maintaining 
4.3….and even after 4.5 was released. Because 4.3 was seen as a good release.

Now that we have 4.4 and 4.5.2 etc, I don't think we will have the cycles to 
maintain that many release branches.

The big issue is upgrade path, 

IMHO our LTS strategy is to have master as a release branch itself, adopt good 
practice to merge to master, have great upgrades and no regressions.

Ultimately we should divert our efforts to master.

So I am +1 with Remi on this.

> 
> 
>> On 02 Jul 2015, at 16:25, Rene Moser  wrote:
>> 
>> Maybe a little bit off topic to the new release process, therefor a new
>> thread...
>> 
>> speaking about releases. I just thought about supporting LTS releases.
>> 
>> This would mean "someone" or "we" make a commitment to add bug fixes
>> (only) for a specified time. e.g. 2 years for a release or until the
>> next LTS release?
>> 
>> Would this something anyone would be interested in?
>> 
>> Yours
>> René

Re: [DISCUSS] Release principles for Apache CloudStack

[sebgoa]

On Jul 3, 2015, at 9:06 AM, Raja Pullela  wrote:

> Remi, 
> 
> couple of questions on the branching part - when we take the Feature PR and 
> Feature is back in Master, feel like we are potentially destabilizing Master 
> ?   I know, currently we push changes to master even before anything is 
> tested fully - agree, we are now running the Travis test before a checkin - 
> however, I feel those are not sufficient ?  
> 
> IMHO - we should take a release branch open it up for PR/checkins and once 
> the testing is done the branch gets into Master - we take RC from the master 
> and release it.  That way no one checkins to master and constantly tested 
> changes get into/merged to master.  
> 
> I remember seeing similar changes proposed by few folks... I have been little 
> out of touch on those changes.
> 

Basically yes, we should not merge untested, unfinished features in master.

> best,
> Raja
> -Original Message-
> From: Rajani Karuturi [mailto:raj...@apache.org] 
> Sent: Friday, July 3, 2015 8:00 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Release principles for Apache CloudStack
> 
> I do not agree to backporting aka cherry picking. I prefer forward 
> merges(tofu scale) 4.4 to 4.5 to master etc.
> That way, none of the changes will be missed and git branch --contains gives 
> a nice view of where all the changes went.
> 
> 
> On Thu, Jul 2, 2015 at 23:16 PM, Remi Bergsma  wrote:
> 
> Hi Daan,
> 
> Indeed. I prefer committing to master first, as it will ensure everything 
> ends up there (unless some specific use cases). Currently, we have the risk 
> of forgetting to include a fix to a release branch back to master.
> 
> When we reverse it, some bug fix that should end up in the x.y branch, is 
> committed to master, then also applied (or reimplemented) to x.y. If you then 
> only take one of the two steps, there is no issue as it will be in master 
> only (and people will notice). In the other situation, when we accept a PR to 
> x.y and forget to merge back, we possibly introduce regression bugs.
> 
> I will update the diagram and wiki later tonight.
> 
> While reviewing PRs, let’s be alert to see PRs not pointed towards master and 
> at least discuss it.
> 
> Regards,
> Remi
> 
> 
>> On 2 jul. 2015, at 16:54, Daan Hoogland  > wrote:
>> 
>> On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma > >
> wrote:
>>> Since the goal is a stable master, I’d say the bug fix should go to
> master first.
>> 
>> 
>> Remi, this means that merge back of the branch makes no sense anymore.
>> 
>> --
>> Daan
> 
> 
> 
> --
> -
> Sent from Windows Phone
> ~Rajani

Re: IRC and Slack

[sebgoa]

Some great ideas in there.

I am +1 for:

-consolidate #cloudstack-dev and #cloudstack
-move bots to #cloudstack-announce
-Remi's idea to publish slack message to #cloudstack (and vice versa).
-the idea to use something like discourse or stack overflow etc…

Somebody wants to take this on :)



On Jul 2, 2015, at 11:13 PM, Nux!  wrote:

> Hi,
> 
> Our IRC channels seem to be dead, indeed, at least for "user support" 
> purposes. IRC is pretty established and works great for many projects, it 
> just requires people active then and there.
> 
> Probably any form of chat will have the same fate no matter how trendy and 
> personally -1 for anything like slack, hipchat etc.
> 
> Perhaps a forum might be more user friendly than mailing lists? Discourse ( 
> http://try.discourse.org/ ) looks pretty nice and feature-rich (login with 
> github, facebook etc etc).
> 
> My 2 cents
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Sebastien Goasguen" 
>> To: dev@cloudstack.apache.org
>> Sent: Thursday, 2 July, 2015 09:39:31
>> Subject: IRC and Slack
> 
>> Hi folks,
>> 
>> IRC has been mostly deserted for a while now. But there are still folks 
>> hanging
>> out there with unanswered questions.
>> 
>> I also know of several slack channels on cloudstack.
>> 
>> We need to take a decision here. Shall we officially abandon IRC and out a
>> notice there that points towards Slack.
>> 
>> If we do, how do we invite everyone to the slack channel ?
>> 
>> -Sebastien

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

> On 3 jul. 2015, at 09:21, sebgoa  wrote:
> 
> On Jul 3, 2015, at 9:06 AM, Raja Pullela  wrote:
> 
>> Remi, 
>> 
>> couple of questions on the branching part - when we take the Feature PR and 
>> Feature is back in Master, feel like we are potentially destabilizing Master 
>> ?   I know, currently we push changes to master even before anything is 
>> tested fully - agree, we are now running the Travis test before a checkin - 
>> however, I feel those are not sufficient ?  
>> 
>> IMHO - we should take a release branch open it up for PR/checkins and once 
>> the testing is done the branch gets into Master - we take RC from the master 
>> and release it.  That way no one checkins to master and constantly tested 
>> changes get into/merged to master.  
>> 
>> I remember seeing similar changes proposed by few folks... I have been 
>> little out of touch on those changes.
>> 
> 
> Basically yes, we should not merge untested, unfinished features in master


Exactly. Whatever is merged to master “should just work (tm)”. 
The purpose of having people say this "LGTM", is also to have them verify / 
test it. In a perfect world this testing is automated. Until we’re there, we 
need to rely on people to do this. 

Regards, Remi

Re: [PROPOSAL] Commit to master through PR only

[sebgoa]

On Jul 2, 2015, at 8:43 AM, Wilder Rodrigues  
wrote:

> Sateesh and Rajesh,
> 
> It seems you were the only guys who +1 the squash idea. Could you please 
> share with us what benefits you think squashing commits will bring? 
> 
> I wil give you the simplest example that could come to my mind to encourage 
> no squash:
> 
> * I open a Java class with 5 thousand lines. The first thing I do is format 
> the code and commit the change.
> * I go back to the class and apply the fix, let’s say, a 3 lines change, then 
> I commit the change again.
> 

In our overall effort, I think squashing discussion is lower priority. Agreeing 
to do PR reviews with 2 LGTM before merge is already a very big step in 
stabilizing master and helping with releases.

that should be our higher priority.

That said, I work on libcloud as well. It is a much smaller project. But there 
we squash before committing on master. There can be several commits in the PR, 
because one will surely amend the PR based on review. But once it's accepted, 
it gets merged as a single commit.

You all know I am not a hard core dev guy like some of you Java gurus.

The benefit I see in squashing is that in your release branch (master), one 
functionality is encapsulated in a single commit. You don't need to look 
through 10-20 commits whose messages seem   unrelated. You might be able to run 
some git magic to get all of it, but when I look a the basic commit history, 
things are right there in front of me.

Now if I want to create a bug fix release, and I choose to cherry-pick that 
very thing. I cherry pick one commit, and that's it.

So IMHO, the history of the commit should be in the PR review, not on the 
master git history.

I dream for a day with a super clean master commit history of only merges/PR, 
with JIRA bug ID.

-sebastien


> Now, think about the PR. It will contain 2 commits: 1 with the formatting 
> changes only; and a second commit with 3 lines change.
> 
> Would you like to see it quashed and all messed up? It would be very 
> difficult to review.
> 
> That’s just a simple example.
> 
> Cheers,
> Wilder 
> 
>> On 02 Jul 2015, at 07:22, Rajesh Battala  wrote:
>> 
>> +1 for squashing commit
>> 
>> -Original Message-
>> From: John Burwell [mailto:john.burw...@shapeblue.com] 
>> Sent: Thursday, July 2, 2015 12:14 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Commit to master through PR only
>> 
>> All,
>> 
>> I think we should stick to 2 votes per PR.  Defining types of PRs becomes 
>> difficult bordering on the arbitrary — adding a process complexity and the 
>> potential to start debating if a particular PR is one type or another.
>> 
>> I agree regarding the fast forward, and feel that all PRs should squashed 
>> down to one commit.  Ultimately, intermediate commits that seem informative 
>> in a feature branch become noise in a history as large as CloudStack’s.
>> 
>> To enforce the policy and ensure that PRs are merged in an orderly and 
>> correct manner (i.e. one at time), I think we should consider adopting a 
>> tool such as bors [1] to verify that the merge passes all tests and then 
>> performs the merge. It would some minor modification to require two votes, 
>> but I doubt that would take much effort to implement.  If there is interest, 
>> I would happy to make those changes for the project.
>> 
>> Thanks,
>> -John
>> 
>> [1]: https://github.com/graydon/bors
>> 
>> ---
>> John Burwell (@john_burwell)
>> VP of Software Engineering, ShapeBlue
>> (571) 403-2411 | +44 20 3603 0542
>> http://www.shapeblue.com
>> 
>> 
>> 
>>> On Jul 1, 2015, at 1:48 PM, Rohit Yadav  wrote:
>>> 
>>> Hi,
>>> 
 On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen  wrote:
 
 A few of us are in Amsterdam at DevOps days. We are chatting about release 
 management procedure.
 Remi is working on a set of principles that he will put on the wiki to 
 start a [DISCUSS].
 
 However to get started on the right track. I would like to propose the 
 following easy step:
 
 Starting Monday June 29th (next monday):
 
 - Only commit through PR will land on master (after a minimum of 2 LGTM 
 and green Travis results)
 - Direct commit will be reverted
 - Any committer can merge the PR.
>>> 
>>> +1
>>> 
>>> I’ve been trying to help close PRs, it was difficult at first but then I 
>>> found some tooling to help me do that. I think it’s certainly do-able 
>>> without investing a lot of effort to do it, perhaps can done everyday or 
>>> every few days in a week.
>>> 
>>> Some suggestions and comments to improve PR reviewing/merging:
>>> 
>>> - Let's merge the PR commits in a fast forward way instead of doing a 
>>> branch merge that introduces frivolous merge commits. This is one approach 
>>> to do quickly and painlessly:
>>> 
>>> http://blog.remibergsma.com/2015/05/24/accepting-pull-requests-the-easy-way/
>>> 
>>> - Let’s try to send PR around on one issue or one broad issue, or again

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Hi Rajani, all,

I do think we have the same goal in mind: no regression and no cherry-pick mess.

Just did some reading on "tofu scale" and see two issues:
- if it doesn't happen / isn't completed we'll have regression as we've seen 
before. I want a working model that prevents regression by default or else we 
will not reach smooth upgrades without introducing old bugs again. 
- we are doing lots of refactoring work (probably will be doing even more) 
where this model also will not work because the merge fails to apply cleanly 
(this is what Erik mentioned yesterday). Fixing that conflict is invisible on 
the dev-list (as we have no PR) and error prone (not tested before commit, no 
LGTMs).

Don’t get me wrong, I don’t want the cherry-pick mess we experienced before.

What will be different:
- master is stable instead of unstable
- we’ll branch off x.y (say 4.6 which is up next) only after a vote on a RC 
passes. Instead of branching it off first, then make it stable and release it 
and cherry-pick stuff around. So, no cherry-picking here.
- once the x.y branch is there, we should do no back ports of features. Only 
(critical?) bug fixes. 

Those bug fixes (that went to master first through PR and got 2x LGTM) could 
now also be applied to the x.y. branch (and become x.y.1 or similar) Instead of 
cherry-picking, I’d apply the same PR to x.y (if possible, or else a new PR 
that reimplements the fix for x.y in which case it would need its own 2x LGTM). 
In any bug fix PR we should mention the jira bug id (and PR id) in the commit 
message. This, you could argue, is like cherry-picking as it makes a new commit 
id. As the amount of bug fix commits should me minimal, I think this is ok.

We should make sure upgrades are so smooth that our users can upgrade easily 
and we don’t have to maintain previous releases for a long time.

I clarified some more things on the wiki and also updated the diagrams.

Regards,
Remi


> On 3 jul. 2015, at 04:29, Rajani Karuturi  wrote:
> 
> I do not agree to backporting aka cherry picking. I prefer forward
> merges(tofu scale) 4.4 to 4.5 to master etc.
> That way, none of the changes will be missed and git branch --contains
> gives a nice view of where all the changes went.
> 
> 
> On Thu, Jul 2, 2015 at 23:16 PM, Remi Bergsma  > wrote:
> 
> Hi Daan,
> 
> Indeed. I prefer committing to master first, as it will ensure everything
> ends up there (unless some specific use cases). Currently, we have the risk
> of forgetting to include a fix to a release branch back to master.
> 
> When we reverse it, some bug fix that should end up in the x.y branch, is
> committed to master, then also applied (or reimplemented) to x.y. If you
> then only take one of the two steps, there is no issue as it will be in
> master only (and people will notice). In the other situation, when we
> accept a PR to x.y and forget to merge back, we possibly introduce
> regression bugs.
> 
> I will update the diagram and wiki later tonight.
> 
> While reviewing PRs, let’s be alert to see PRs not pointed towards master
> and at least discuss it.
> 
> Regards,
> Remi
> 
> 
>> On 2 jul. 2015, at 16:54, Daan Hoogland  > wrote:
>> 
>> On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma >  >
> wrote:
>>> Since the goal is a stable master, I’d say the bug fix should go to
> master first.
>> 
>> 
>> Remi, this means that merge back of the branch makes no sense anymore.
>> 
>> --
>> Daan
> 
> 
> 
> -- 
> -
> Sent from Windows Phone
> ~Rajani

Re: IRC and Slack

[Erik Weber]

On Fri, Jul 3, 2015 at 9:27 AM, sebgoa  wrote:

> Some great ideas in there.
>
> I am +1 for:
>
> -consolidate #cloudstack-dev and #cloudstack
> -move bots to #cloudstack-announce
> -Remi's idea to publish slack message to #cloudstack (and vice versa).
> -the idea to use something like discourse or stack overflow etc…
>
> Somebody wants to take this on :)
>
>

+1 :-)

Is this slack available already? If so, how do I get an invitation?

-- 
Erik

Re: [DISCUSS] Release principles for Apache CloudStack

[Erik Weber]

On Fri, Jul 3, 2015 at 10:06 AM, Remi Bergsma  wrote:

> Hi Rajani, all,
>
> I do think we have the same goal in mind: no regression and no cherry-pick
> mess.
>
> Just did some reading on "tofu scale" and see two issues:
> - if it doesn't happen / isn't completed we'll have regression as we've
> seen before. I want a working model that prevents regression by default or
> else we will not reach smooth upgrades without introducing old bugs again.
> - we are doing lots of refactoring work (probably will be doing even more)
> where this model also will not work because the merge fails to apply
> cleanly (this is what Erik mentioned yesterday). Fixing that conflict is
> invisible on the dev-list (as we have no PR) and error prone (not tested
> before commit, no LGTMs).
>
> Don’t get me wrong, I don’t want the cherry-pick mess we experienced
> before.
>
> What will be different:
> - master is stable instead of unstable
> - we’ll branch off x.y (say 4.6 which is up next) only after a vote on a
> RC passes. Instead of branching it off first, then make it stable and
> release it and cherry-pick stuff around. So, no cherry-picking here.
> - once the x.y branch is there, we should do no back ports of features.
> Only (critical?) bug fixes.
>
> Those bug fixes (that went to master first through PR and got 2x LGTM)
> could now also be applied to the x.y. branch (and become x.y.1 or similar)
> Instead of cherry-picking, I’d apply the same PR to x.y (if possible, or
> else a new PR that reimplements the fix for x.y in which case it would need
> its own 2x LGTM). In any bug fix PR we should mention the jira bug id (and
> PR id) in the commit message. This, you could argue, is like cherry-picking
> as it makes a new commit id. As the amount of bug fix commits should me
> minimal, I think this is ok.
>
> We should make sure upgrades are so smooth that our users can upgrade
> easily and we don’t have to maintain previous releases for a long time.
>
> I clarified some more things on the wiki and also updated the diagrams.
>
>

I'm no hardcore dev, so take my opinions with a grain of salt, but this
looks reasonable to me and a step in the right direction.

+1

-- 
Erik

Re: IRC and Slack

[Remi Bergsma]

I setup a proof-of-concept a while back to test it: 
http://cloudstackdev.slack.com. There currently are around 30 people, mostly 
dev from this list.

Anyone with an @apache.org account can sign-up and anyone else could ask me, 
Daan, Rohit, Wilder or Funs for an invite (for now). I can imagine we setup 
some other structure for this later on. If you want to be admin, just ping me.

Regards,
Remi
 

> On 3 jul. 2015, at 10:10, Erik Weber  wrote:
> 
> On Fri, Jul 3, 2015 at 9:27 AM, sebgoa  wrote:
> 
>> Some great ideas in there.
>> 
>> I am +1 for:
>> 
>> -consolidate #cloudstack-dev and #cloudstack
>> -move bots to #cloudstack-announce
>> -Remi's idea to publish slack message to #cloudstack (and vice versa).
>> -the idea to use something like discourse or stack overflow etc…
>> 
>> Somebody wants to take this on :)
>> 
>> 
> 
> +1 :-)
> 
> Is this slack available already? If so, how do I get an invitation?
> 
> -- 
> Erik

Re: IRC and Slack

[sebgoa]

On Jul 3, 2015, at 10:17 AM, Remi Bergsma  wrote:

> I setup a proof-of-concept a while back to test it: 
> http://cloudstackdev.slack.com. There currently are around 30 people, mostly 
> dev from this list.
> 
> Anyone with an @apache.org account can sign-up and anyone else could ask me, 
> Daan, Rohit, Wilder or Funs for an invite (for now). I can imagine we setup 
> some other structure for this later on. If you want to be admin, just ping me.
> 
> Regards,
> Remi
> 

any chance you can try that IRC/Slack integration pointing to #cloudstack ?

> 
>> On 3 jul. 2015, at 10:10, Erik Weber  wrote:
>> 
>> On Fri, Jul 3, 2015 at 9:27 AM, sebgoa  wrote:
>> 
>>> Some great ideas in there.
>>> 
>>> I am +1 for:
>>> 
>>> -consolidate #cloudstack-dev and #cloudstack
>>> -move bots to #cloudstack-announce
>>> -Remi's idea to publish slack message to #cloudstack (and vice versa).
>>> -the idea to use something like discourse or stack overflow etc…
>>> 
>>> Somebody wants to take this on :)
>>> 
>>> 
>> 
>> +1 :-)
>> 
>> Is this slack available already? If so, how do I get an invitation?
>> 
>> -- 
>> Erik
> 

[GitHub] cloudstack pull request: Vpcr Marvin test and some fixes for vprc

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/558#issuecomment-118274161
  
Nice one, @isoutham !

I will test it this week and also try to get someone else to have a look so 
we get the 2 LGTM needed to merge.

Thanks!

Cheers,
Wilder


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Vpcr Marvin test and some fixes for vprc

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/558#issuecomment-118274398
  
Travis failed due timeout... so, that's not relevant and won't be taken 
into account when reviewing the PR:

===
No output has been received in the last 10 minutes, this potentially 
indicates a stalled build or something wrong with the build itself.
The build has been terminated
===

Cheers,
Wilder


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: IRC and Slack

[Remi Bergsma]

Yes, I’ll have some time off coming up so I’ll give it a go.

> any chance you can try that IRC/Slack integration pointing to #cloudstack ?

[GitHub] cloudstack pull request: Vpcr Marvin test and some fixes for vprc

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/558#issuecomment-118275941
  
@isoutham @wilderrodrigues is there a way to trigger the build again? 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Vpcr Marvin test and some fixes for vprc

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/558#issuecomment-118279061
  
Only if something get pushed to the branch which generated the PR.

Only 1 job out of 9 timed out... I wouldn't bother. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] LTS releases?

[Rene Moser]

Sebastien,

So wouldn't it be nice to make clear which release is still supported
and which release is not?

On 03.07.2015 09:20, sebgoa wrote:

> I think we got in a situation with 4.4 that called for us to keep maintaining 
> 4.3….and even after 4.5 was released. Because 4.3 was seen as a good release.

Your are saying 4.3 is a good release, shouldn't it be maintained a bit
"longer"?

So currently we have:

main 4.5.x
stable: 4.4.x
legacy: 4.3.x
deprecated: 4.2.0

When 4.6 is released, what should a release be dropped? 4.4.x?

main: 4.6.0
stable: 4.5.x
legacy: 4.3.x

What is your plan about this?

Yours
René

Re: [GitHub] cloudstack pull request: As an operator I want to be able to chang...

[Daan Hoogland]

John,

The descriptive message should be in the merge commit. It should state
the cause of the collective. each individual should have a smaller
message stating the reason for a simple atomic change. Taking what you
say here we could squah the whole repo with the message 'making an
cloud orchestration platform'.
What I mean by this is that at any level of squashing the intent of
the work will become meaningless at some point.


On Wed, Jul 1, 2015 at 8:58 PM, John Burwell  wrote:
> Daan,
>
> I disagree regarding the squash.  As I read through the list of commits, they 
> read as a series of small commits that do not explain the overall change.  
> When this batch of small of commits is merged into the large history of 
> master, the intent of this work will be lost.  In my opinion, squashing them 
> into one commit with a descriptive commit message will be much more helpful 
> to people trying to comprehend the work at some point in the future.
>
> Thanks,
> -John
>
> ---
> John Burwell (@john_burwell)
> VP of Software Engineering, ShapeBlue
> (571) 403-2411 | +44 20 3603 0542
> http://www.shapeblue.com
>
>
>
>> On Jun 29, 2015, at 5:30 AM, Daan Hoogland  wrote:
>>
>> Do not squash commits and hide history unless it makes reading it much
>> and obviously clearer. It is only good in my not so humble opinion in
>> case of to and fro commits where a thing has been reverted and
>> reapplied and reverted again and so on.
>>
>> Also do not rebase commits but make merge commits, this make seeing
>> what happened when much easier and also make reverting of big chunks
>> of work easier: if it seems to work merge, if it turns out it doesn't
>> revert the merge fix and merge again.
>>
>> €0,02
>>
>>
>> On Mon, Jun 29, 2015 at 11:07 AM, wilderrodrigues  
>> wrote:
>>> Github user wilderrodrigues commented on the pull request:
>>>
>>>https://github.com/apache/cloudstack/pull/527#issuecomment-116545842
>>>
>>>I created the issue and added to the last commit. Did it last week:
>>>
>>>https://issues.apache.org/jira/browse/CLOUDSTACK-8589
>>>
>>>Perhaps you missed that.
>>>
>>>Concerning squashed commits, ew should really have discussed about it 
>>> when you were here. I'm 100% if I squash my atomic commits next time you 
>>> guys will complain. It seems I haven't been clear enough about that yet.
>>>
>>>@remibergsma @miguelaferreira Would you guys give your input on these 
>>> "squash commits" matter? I'm a bit tired of this discussion. For me, 
>>> squashed commits won't make a review easier, unless there is no review at 
>>> all or if the committer has changes a couple of lines in a bash script.
>>>
>>>What I would like to see is people testing changes the way I do.
>>>
>>>Cheers,
>>>Wilder
>>>
>>>
>>> ---
>>> If your project is set up for it, you can reply to this email and have your
>>> reply appear on GitHub as well. If your project does not have this feature
>>> enabled and wishes so, or if the feature is enabled but not working, please
>>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>>> with INFRA.
>>> ---
>>
>>
>>
>> --
>> Daan
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.



-- 
Daan

Re: [DISCUSS] LTS releases?

[sebgoa]

On Jul 3, 2015, at 11:13 AM, Rene Moser  wrote:

> Sebastien,
> 
> So wouldn't it be nice to make clear which release is still supported
> and which release is not?
> 
> On 03.07.2015 09:20, sebgoa wrote:
> 
>> I think we got in a situation with 4.4 that called for us to keep 
>> maintaining 4.3….and even after 4.5 was released. Because 4.3 was seen as a 
>> good release.
> 
> Your are saying 4.3 is a good release, shouldn't it be maintained a bit
> "longer"?
> 
> So currently we have:
> 
> main 4.5.x
> stable: 4.4.x
> legacy: 4.3.x
> deprecated: 4.2.0
> 
> When 4.6 is released, what should a release be dropped? 4.4.x?
> 
> main: 4.6.0
> stable: 4.5.x
> legacy: 4.3.x
> 
> What is your plan about this?

What is *our* plan :)

We used to only maintain the last two major releases.

We diverged from that model when 4.5.0 came out and that we still wanted to 
maintain 4.3 because 4.3 was working so well for people.

My personal preference would be to get into a rolling release model, where we 
maintain only the last major release.
This is why making master stable and the base for all our releases is so 
important.

Users should get into a model where they continuously upgrade/deploy and don't 
get stuck on a unmaintained branch with forks that prevents upgrade.

When users face an issue, we patch and release, then they upgrade always to the 
latest version.

That's the ideal world :)

> 
> Yours
> René
> 

RE: [PROPOSAL] Commit to master through PR only

[Stephen Turner]

Personally, if I find a bug, I often go back to find when and why it was 
introduced, and I find it much more useful to be able to identify a specific 
changeset rather than a large pull request.

-- 
Stephen Turner


-Original Message-
From: John Burwell [mailto:john.burw...@shapeblue.com] 
Sent: 02 July 2015 19:35
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] Commit to master through PR only

Wilder,

In the grand scheme of the entire project history (e.g. reading git log), why 
do I care about these discrete operations?   In six months (or long), I (as the 
consumer of your change) want to know what motivated this change which is 
completely lost in those two commits.  I have found this advice [1] for commit 
messages combined with squashing commits to a topic (e.g. defect ticket, 
feature, enhancement ticket, etc) yields a git history that incredible value 
over the long term in a projects with a lot of developers making many changes.

Thanks,
-John

P.S. As an aside, if you encounter a 5000 class, I would encourage you to 
decompose it rather than reformat the file.

[1]: https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message

---
John Burwell (@john_burwell)
VP of Software Engineering, ShapeBlue
(571) 403-2411 | +44 20 3603 0542
http://www.shapeblue.com



> On Jul 2, 2015, at 2:43 AM, Wilder Rodrigues  
> wrote:
>
> Sateesh and Rajesh,
>
> It seems you were the only guys who +1 the squash idea. Could you please 
> share with us what benefits you think squashing commits will bring?
>
> I wil give you the simplest example that could come to my mind to encourage 
> no squash:
>
> * I open a Java class with 5 thousand lines. The first thing I do is format 
> the code and commit the change.
> * I go back to the class and apply the fix, let’s say, a 3 lines change, then 
> I commit the change again.
>
> Now, think about the PR. It will contain 2 commits: 1 with the formatting 
> changes only; and a second commit with 3 lines change.
>
> Would you like to see it quashed and all messed up? It would be very 
> difficult to review.
>
> That’s just a simple example.
>
> Cheers,
> Wilder
>
>> On 02 Jul 2015, at 07:22, Rajesh Battala  wrote:
>>
>> +1 for squashing commit
>>
>> -Original Message-
>> From: John Burwell [mailto:john.burw...@shapeblue.com]
>> Sent: Thursday, July 2, 2015 12:14 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Commit to master through PR only
>>
>> All,
>>
>> I think we should stick to 2 votes per PR.  Defining types of PRs becomes 
>> difficult bordering on the arbitrary — adding a process complexity and the 
>> potential to start debating if a particular PR is one type or another.
>>
>> I agree regarding the fast forward, and feel that all PRs should squashed 
>> down to one commit.  Ultimately, intermediate commits that seem informative 
>> in a feature branch become noise in a history as large as CloudStack’s.
>>
>> To enforce the policy and ensure that PRs are merged in an orderly and 
>> correct manner (i.e. one at time), I think we should consider adopting a 
>> tool such as bors [1] to verify that the merge passes all tests and then 
>> performs the merge. It would some minor modification to require two votes, 
>> but I doubt that would take much effort to implement.  If there is interest, 
>> I would happy to make those changes for the project.
>>
>> Thanks,
>> -John
>>
>> [1]: https://github.com/graydon/bors
>>
>> ---
>> John Burwell (@john_burwell)
>> VP of Software Engineering, ShapeBlue
>> (571) 403-2411 | +44 20 3603 0542
>> http://www.shapeblue.com
>>
>>
>>
>>> On Jul 1, 2015, at 1:48 PM, Rohit Yadav  wrote:
>>>
>>> Hi,
>>>
 On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen  wrote:

 A few of us are in Amsterdam at DevOps days. We are chatting about release 
 management procedure.
 Remi is working on a set of principles that he will put on the wiki to 
 start a [DISCUSS].

 However to get started on the right track. I would like to propose the 
 following easy step:

 Starting Monday June 29th (next monday):

 - Only commit through PR will land on master (after a minimum of 2 LGTM 
 and green Travis results)
 - Direct commit will be reverted
 - Any committer can merge the PR.
>>>
>>> +1
>>>
>>> I’ve been trying to help close PRs, it was difficult at first but then I 
>>> found some tooling to help me do that. I think it’s certainly do-able 
>>> without investing a lot of effort to do it, perhaps can done everyday or 
>>> every few days in a week.
>>>
>>> Some suggestions and comments to improve PR reviewing/merging:
>>>
>>> - Let's merge the PR commits in a fast forward way instead of doing a 
>>> branch merge that introduces frivolous merge commits. This is one approach 
>>> to do quickly and painlessly:
>>>
>>> http://blog.remibergsma.com/2015/05/24/accepting-pull-requests-the-easy-way/
>>>
>>> - Let’s try to send PR around on one issue or one broad issu

[GitHub] cloudstack pull request: BUG-ID:CLOUDSTACK-7472: kvmclock fix for ...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/557#issuecomment-118302519
  
LGTM, merging


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: BUG-ID:CLOUDSTACK-7472: kvmclock fix for ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/557


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8603: Random list VM failures ...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/551#issuecomment-118303081
  
LGTM, merging.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8603: Random list VM failures ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/551


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] LTS releases?

[Remi Bergsma]

Agree with the ideal world scenario :-)

If we look at it from the other side: Why is it that people want to stay on 
older releases?

From personal experience I know that in the beginning the 4.4 release wasn’t 
that stable. I upgraded production systems from 4.3.0 to 4.4.2 and it was 
painful. That is not true anymore today, as 4.4.4 is pretty nice. From what I 
hear, 4.5.1 is also doing well. Great steps have been made already to make sure 
this will not happen again.

Still, I can imagine that this may have scared some people and it made them 
stay where they are (at 4.3). Let’s investigate if people running 4.3 want to 
upgrade to 4.5.x or the upcoming 4.6 and, more important, why not? Then let’s 
fix that or prove it works.

Regards,
Remi


> What is *our* plan :)
> 
> We used to only maintain the last two major releases.
> 
> We diverged from that model when 4.5.0 came out and that we still wanted to 
> maintain 4.3 because 4.3 was working so well for people.
> 
> My personal preference would be to get into a rolling release model, where we 
> maintain only the last major release.
> This is why making master stable and the base for all our releases is so 
> important.
> 
> Users should get into a model where they continuously upgrade/deploy and 
> don't get stuck on a unmaintained branch with forks that prevents upgrade.
> 
> When users face an issue, we patch and release, then they upgrade always to 
> the latest version.
> 
> That's the ideal world :)

Re: [PROPOSAL] Commit to master through PR only

[Wilder Rodrigues]

Hi John,

If you look at the discrete operations wearing a hat of a Project Manager, you 
won’t care… neither would I. However, from a Software Engineer perspective, as 
much as the other people contributing with the Java code, I do care and it 
really makes reviewing the PR easier.

As a consumer of my change (project manager hat again), you should be looking 
for Design Documents. Those will for sure show the motivation behind the 
changes in a higher level.

Concerning the 5k lines classes, I have found a few of them and they haven been 
refactored accordingly. Have a look at the Virtual Router, Citrix/LibVirt 
resource classes, those were cleaned as much as they could. The example I gave 
was simple and should not be used in such a way, Think of it as a 100 lines 
class instead, perhaps it will help.

I’m feeling inclined to send my next PR with squashed commits to see if it will 
get reviewed properly and in an easy way.

Cheers,
Wilder 


> On 02 Jul 2015, at 20:35, John Burwell  wrote:
> 
> Wilder,
> 
> In the grand scheme of the entire project history (e.g. reading git log), why 
> do I care about these discrete operations?   In six months (or long), I (as 
> the consumer of your change) want to know what motivated this change which is 
> completely lost in those two commits.  I have found this advice [1] for 
> commit messages combined with squashing commits to a topic (e.g. defect 
> ticket, feature, enhancement ticket, etc) yields a git history that 
> incredible value over the long term in a projects with a lot of developers 
> making many changes.
> 
> Thanks,
> -John
> 
> P.S. As an aside, if you encounter a 5000 class, I would encourage you to 
> decompose it rather than reformat the file.
> 
> [1]: https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
> 
> ---
> John Burwell (@john_burwell)
> VP of Software Engineering, ShapeBlue
> (571) 403-2411 | +44 20 3603 0542
> http://www.shapeblue.com
> 
> 
> 
>> On Jul 2, 2015, at 2:43 AM, Wilder Rodrigues  
>> wrote:
>> 
>> Sateesh and Rajesh,
>> 
>> It seems you were the only guys who +1 the squash idea. Could you please 
>> share with us what benefits you think squashing commits will bring?
>> 
>> I wil give you the simplest example that could come to my mind to encourage 
>> no squash:
>> 
>> * I open a Java class with 5 thousand lines. The first thing I do is format 
>> the code and commit the change.
>> * I go back to the class and apply the fix, let’s say, a 3 lines change, 
>> then I commit the change again.
>> 
>> Now, think about the PR. It will contain 2 commits: 1 with the formatting 
>> changes only; and a second commit with 3 lines change.
>> 
>> Would you like to see it quashed and all messed up? It would be very 
>> difficult to review.
>> 
>> That’s just a simple example.
>> 
>> Cheers,
>> Wilder
>> 
>>> On 02 Jul 2015, at 07:22, Rajesh Battala  wrote:
>>> 
>>> +1 for squashing commit
>>> 
>>> -Original Message-
>>> From: John Burwell [mailto:john.burw...@shapeblue.com]
>>> Sent: Thursday, July 2, 2015 12:14 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [PROPOSAL] Commit to master through PR only
>>> 
>>> All,
>>> 
>>> I think we should stick to 2 votes per PR.  Defining types of PRs becomes 
>>> difficult bordering on the arbitrary — adding a process complexity and the 
>>> potential to start debating if a particular PR is one type or another.
>>> 
>>> I agree regarding the fast forward, and feel that all PRs should squashed 
>>> down to one commit.  Ultimately, intermediate commits that seem informative 
>>> in a feature branch become noise in a history as large as CloudStack’s.
>>> 
>>> To enforce the policy and ensure that PRs are merged in an orderly and 
>>> correct manner (i.e. one at time), I think we should consider adopting a 
>>> tool such as bors [1] to verify that the merge passes all tests and then 
>>> performs the merge. It would some minor modification to require two votes, 
>>> but I doubt that would take much effort to implement.  If there is 
>>> interest, I would happy to make those changes for the project.
>>> 
>>> Thanks,
>>> -John
>>> 
>>> [1]: https://github.com/graydon/bors
>>> 
>>> ---
>>> John Burwell (@john_burwell)
>>> VP of Software Engineering, ShapeBlue
>>> (571) 403-2411 | +44 20 3603 0542
>>> http://www.shapeblue.com
>>> 
>>> 
>>> 
 On Jul 1, 2015, at 1:48 PM, Rohit Yadav  wrote:
 
 Hi,
 
> On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen  wrote:
> 
> A few of us are in Amsterdam at DevOps days. We are chatting about 
> release management procedure.
> Remi is working on a set of principles that he will put on the wiki to 
> start a [DISCUSS].
> 
> However to get started on the right track. I would like to propose the 
> following easy step:
> 
> Starting Monday June 29th (next monday):
> 
> - Only commit through PR will land on master (after a minimum of 2 LGTM 
> and green Travis results)
> 

Build failed in Jenkins: simulator-singlerun #1333

[jenkins]

See 

--
Started by upstream project "build-master-simulator" build number 2150
originally caused by:
 Started by an SCM change
 Started by upstream project "build-master" build number 2444
 originally caused by:
  Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on simulator in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1258)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/cloudstack.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error:  while accessing 
https://git-wip-us.apache.org/repos/asf/cloudstack.git/info/refs

fatal: HTTP request failed

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at ..remote call to simulator(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at sun.proxy.$Proxy46.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733)
... 11 more
ERROR: Error fetching remote repo 'origin'
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - No test report file(s) were found with the pattern 
'xunit.xml' relative to 
' for the testing 
framework 'JUnit'.  Did you enter a pattern relative to the correct directory?  
Did you generate the result report(s) for 'JUnit'?
[xUnit] [ERROR] - No test reports found for the metric 'JUnit' with the 
resolved pattern 'xunit.xml'. Configuration error?.
[xUnit] [INFO] - Failing 

Jenkins build is back to normal : build-master-jdk18 #183

[jenkins]

See 

Build failed in Jenkins: package-rhel63-4.5 #290

[jenkins]

See 

--
Started by upstream project "build-4.5" build number 494
originally caused by:
 Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on rpmbuilder-2 in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1258)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/cloudstack.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error:  while accessing 
https://git-wip-us.apache.org/repos/asf/cloudstack.git/info/refs

fatal: HTTP request failed

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at ..remote call to rpmbuilder-2(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at sun.proxy.$Proxy46.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733)
... 11 more
ERROR: Error fetching remote repo 'origin'
Archiving artifacts

Build failed in Jenkins: simulator-4.5-singlerun #250

[jenkins]

See 

--
Started by upstream project "build-4.5-simulator" build number 305
originally caused by:
 Started by upstream project "build-4.5" build number 494
 originally caused by:
  Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on simulator in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1258)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/cloudstack.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error:  while accessing 
https://git-wip-us.apache.org/repos/asf/cloudstack.git/info/refs

fatal: HTTP request failed

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at ..remote call to simulator(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at sun.proxy.$Proxy46.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733)
... 11 more
ERROR: Error fetching remote repo 'origin'
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - No test report file(s) were found with the pattern 
'xunit.xml' relative to 
' for the 
testing framework 'JUnit'.  Did you enter a pattern relative to the correct 
directory?  Did you generate the result report(s) for 'JUnit'?
[xUnit] [ERROR] - No test reports found for the metric 'JUnit' with the 
resolved pattern 'xunit.xml'. Configuration error?.
[xUnit] [INFO] - Failing BUILD.
[xUnit] [INFO] -

Re: [DISCUSS] Release principles for Apache CloudStack

[Rajani Karuturi]

I agree to the goal. No regressions can be achieved either by cherry-picks
or merges. Both requires developers to agree to it and has equal
probability to miss.

The advantage in case of merge is, lets say you do a commit a1 to 4.5
branch and forget to merge to master. now, someone else did a2 and is
trying to merge. He will see both the commits and can make choice either to
ask about a1 or merge both.
may be if the merge has conflicts or is not a clean merge, it can be done
as PR which follows the usual process.

with respect to refactoring, we can always do separate PRs on master and
the release branch. The merge from release branch to master in this case
would be an empty merge (git merge -s ours)

The problem I see with the current approach is its not always backporting
the fix to release. This works if the issue reported is already known and
fixed on master or any forward releases.
Usually, you work on a release branch only when an issue is reported on it.
For a issue reported on 4.5, first thing I do is check if the issue really
exists in 4.5 and would also find the solution around the same time. Its
sounds natural to me to push to 4.5(get the load off your head whether it
is customer issue or security issue) and then merge to forward releases.
Now, with the new process, I will have to first verify if the bug exists in
the current release+1, fix in it first, then go back to release branch,
verify if it exists and fix it there.
Obviously there would be exceptions in merging and you may have to
cherry-pick once in a while. But, making it the process is what concerns me.


In addition to the goal mentioned, I would also like to find which all
versions the commit is present in.
For example, If a security issue is reported on 4.5, I found that this is a
regression from commit abcde. Now, I would like to find which all version
this is present as this security patch should be delivered on all the
versions.
In the current situation and also in the new process suggested, the only
way to find it is to go to each and every release and see if the commit is
present.
In the merge route, its simple git merge --contains abcde

Merging is not easy. It requires discipline. But, it has benefits. If
everyone follows it, its as easy as cherry-picking as the code diff will be
exactly same.


Maintaining a release is the second part of the story :) I do agree with
you on the release process for 4.6. Lets start with it for 4.6 release and
continue discussing on how we want to maintain 4.6.x(may be we would never
need one ;))

I can volunteer to be the additional RM for 4.6.


~Rajani

On Fri, Jul 3, 2015 at 1:36 PM, Remi Bergsma  wrote:

> Hi Rajani, all,
>
> I do think we have the same goal in mind: no regression and no cherry-pick
> mess.
>
> Just did some reading on "tofu scale" and see two issues:
> - if it doesn't happen / isn't completed we'll have regression as we've
> seen before. I want a working model that prevents regression by default or
> else we will not reach smooth upgrades without introducing old bugs again.
> - we are doing lots of refactoring work (probably will be doing even more)
> where this model also will not work because the merge fails to apply
> cleanly (this is what Erik mentioned yesterday). Fixing that conflict is
> invisible on the dev-list (as we have no PR) and error prone (not tested
> before commit, no LGTMs).
>
> Don’t get me wrong, I don’t want the cherry-pick mess we experienced
> before.
>
> What will be different:
> - master is stable instead of unstable
> - we’ll branch off x.y (say 4.6 which is up next) only after a vote on a
> RC passes. Instead of branching it off first, then make it stable and
> release it and cherry-pick stuff around. So, no cherry-picking here.
> - once the x.y branch is there, we should do no back ports of features.
> Only (critical?) bug fixes.
>
> Those bug fixes (that went to master first through PR and got 2x LGTM)
> could now also be applied to the x.y. branch (and become x.y.1 or similar)
> Instead of cherry-picking, I’d apply the same PR to x.y (if possible, or
> else a new PR that reimplements the fix for x.y in which case it would need
> its own 2x LGTM). In any bug fix PR we should mention the jira bug id (and
> PR id) in the commit message. This, you could argue, is like cherry-picking
> as it makes a new commit id. As the amount of bug fix commits should me
> minimal, I think this is ok.
>
> We should make sure upgrades are so smooth that our users can upgrade
> easily and we don’t have to maintain previous releases for a long time.
>
> I clarified some more things on the wiki and also updated the diagrams.
>
> Regards,
> Remi
>
>
> > On 3 jul. 2015, at 04:29, Rajani Karuturi  wrote:
> >
> > I do not agree to backporting aka cherry picking. I prefer forward
> > merges(tofu scale) 4.4 to 4.5 to master etc.
> > That way, none of the changes will be missed and git branch --contains
> > gives a nice view of where all the changes went.
> >
> >
> > On Th

[GitHub] cloudstack pull request: BUG-ID: CLOUDSTACK-8484 - Hosts without t...

[sudhansu7]

Github user sudhansu7 commented on the pull request:

https://github.com/apache/cloudstack/pull/335#issuecomment-118331438
  
@remibergsma @karuturi 
I have added marvin test for this issue.
Test result from local setup:

Sudhansus-MAC:cloudstack sudhansu$ nosetests --with-marvin 
--marvin-config=setup/dev/advanced.cfg 
./test/integration/smoke/find_hosts_for_migration.py 

 Marvin Init Started 

=== Marvin Parse Config Successful ===

=== Marvin Setting TestData Successful===

 Log Folder Path: /tmp//MarvinLogs//Jul_03_2015_17_38_01_JVMT7H. All 
logs will be available here 

=== Marvin Init Logging Successful===

 Marvin Init Successful 
===final results are now copied to: 
/tmp//MarvinLogs/find_hosts_for_migration_FKMWAR===
Sudhansus-MAC:cloudstack sudhansu$ cat 
/tmp//MarvinLogs/find_hosts_for_migration_FKMWAR/results.txt 
Test find suitable and not-suitable list of hosts for migration ... === 
TestName: test_01_find_hosts_for_migration | Status : SUCCESS ===
ok

--
Ran 1 test in 27.003s

OK
Sudhansus-MAC:cloudstack sudhansu$ cat 
/tmp//MarvinLogs/find_hosts_for_migration_FKMWAR/failed_plus_exceptions.txt 

Sudhansus-MAC:cloudstack sudhansu$ cat 
/tmp//MarvinLogs/find_hosts_for_migration_FKMWAR/runinfo.txt | grep -i 
'Suitable Hosts'
2015-07-03 17:38:18,171 - DEBUG - Suitable Hosts: set([])
2015-07-03 17:38:18,171 - DEBUG - Not suitable Hosts: 
set([{cpuwithoverprovisioning : u'32000.0', version : u'4.5.2-SNAPSHOT', 
memorytotal : 8589934592, jobstatus : 0, zoneid : 
u'7a83176c-4ae7-49cc-88ff-a794716e74f9', cpunumber : 4, managementserverid : 
4278190080, cpuallocated : u'0%', memoryused : 0, id : 
u'b1b25f17-18f7-4b4d-a8e1-a353ebf33660', cpuused : u'0%', suitableformigration 
: False, clusterid : u'c138587b-c149-4819-9d30-d4fa9d6d5da4', capabilities : 
u'hvm', state : u'Up', memoryallocated : 1879048192, networkkbswrite : 16384, 
cpuspeed : 8000, type : u'Routing', events : u'Ping; StartAgentRebalance; 
ShutdownRequested; ManagementServerDown; HostDown; AgentDisconnected; 
PingTimeout; Remove; AgentConnected', zonename : u'Sandbox-simulator', podid : 
u'b0b72cfb-db0a-4e9c-a9da-84854d8c4a1f', clustertype : u'CloudManaged', hahost 
: False, lastpinged : u'1970-01-17T11:01:01+0530', ipaddress : u'172.16.15.21', 
disconnected : u'2015-07-03T14:32:16+0530', name : u'SimulatedAgent.3
 481871b-7626-450a-b2c1-ab4e6a2e5965', networkkbsread : 32768, created : 
u'2015-07-03T13:39:27+0530', clustername : u'C0', hypervisor : u'Simulator', 
islocalstorageactive : False, resourcestate : u'Enabled', requiresStorageMotion 
: False, podname : u'POD0'}])



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Fairly serious system VM template issue.

[Todd Hebert]

Hello all,

One of my co-workers and I just installed a Cloudstack 4.5 system.   All seemed 
well until we started trying to import templates from another system we manage.

The SSVM downloads the image, then check it using the "vhd-util" utility from 
XenServer.

The error generated is "/bin/vhd-util no such file" or something along those 
lines.   This failure to check the VHD files causes the template imports to 
fail.

This is apparently is caused by vhd-util being a 32-bit binary, linked to 
32-bit libs, and there being no 32-bit libs present on the SSVM image.

Using advice from this article: 
https://github.com/apache/cloudstack/commit/9d8a62d0ee379bf8b67405944c86f68587245db6

we were able to get the system importing templates alright, but this isn't a 
permanent fix of the system VM template.. if we ever change our SSVM, we lose 
the modifications.  

I'm loathe to modify the SSVM template in the system myself, as I don't have 
the facilities to test if this change would break other functions such as VR's 
etc..

If whomever deals with such things could create a new system VM template that 
contains the libs, or uses a statically-linked vhd-util executable, and let the 
list know where to get it & how to replace the existing system VM, that would 
be grand.

Thanks!   :)


Todd Hebert
Hosting engineer

E: theb...@digiweb.ie
A: College Business & Technology Park, Blanchardstown, Dublin 15, Ireland 
W: http://www.digiweb.ie/
 

Re: SystemVM (kvm) : 3 different versions for the same CloudStack version (4.5.1)

[Erik Weber]

On Mon, Jun 8, 2015 at 5:25 PM, David Nalley  wrote:

> On Mon, Jun 8, 2015 at 4:52 AM, Erik Weber  wrote:
> > I'm up for it, delivering from an official ASF source gives it a sense of
> > more authenticity (IMHO).
> >
> > Could we host the RPM/DEB repos there as well?
> >
>
> Yes, that's the easy part. We could turn that on immediately, if we
> are willing to package, vote on, and push RPMs/DEBs there.
>
>
Just to follow up on this; we already vote on the source that creates the
packages and systemvm templates and their contents, is it required to vote
on the binaries as well?


-- 
Erik

Re: [ANNOUNCE] Wilder Rodrigues as a new PMC member of CloudStack

[Daan Hoogland]

finally someone to do the hard work. Go get'm Wilder!

On Thu, Jul 2, 2015 at 5:51 PM, Marco Sinhoreli
 wrote:
> Parabéns Wilder!
>
> Abs!
>
> Marco Sinhoreli
>
> Consultant Manager
>
>
>
>
>
>
>
>
> Phone: +55 21 2586 6390 | Fax: +55 21 2586 6002 | Mobile: +55 21 99159
> 4713 | Mobile: +55 21 98276 3636
>
> Praia de Botafogo 501, bloco 1 - sala 101, Botafogo, Rio de Janeiro, RJ -
> Brazil - CEP 22250-040
>
> marco.sinhor...@shapeblue.com | www.shapeblue.com
>  | Twitter:@shapeBlue
> 
>
>
>
>
>
>
>
>
>
> On 01/07/15 14:12, "Rohit Yadav"  wrote:
>
>>The Project Management Committee (PMC) for Apache CloudStack are pleased
>>to announce that Wilder  Rodrigues (ekho) has accepted our invitation to
>>join the PMC.
>>
>>Please join me in congratulating him.
>>
>>On behalf of the Apache CloudStack PMC,
>>Rohit Yadav
>>
>>---
>>Rohit Yadav
>>Software Architect, ShapeBlue
>>M. +91 88 262 30892 | rohit.ya...@shapeblue.com
>>Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>Find out more about ShapeBlue and our range of CloudStack related services
>>
>>IaaS Cloud Design &
>>Build
>>CSForge ­ rapid IaaS deployment framework
>>CloudStack Consulting
>>CloudStack Software
>>Engineering
>>CloudStack Infrastructure
>>Support
>>CloudStack Bootcamp Training
>>Courses
>>
>>This email and any attachments to it may be confidential and are intended
>>solely for the use of the individual to whom it is addressed. Any views
>>or opinions expressed are solely those of the author and do not
>>necessarily represent those of Shape Blue Ltd or related companies. If
>>you are not the intended recipient of this email, you must neither take
>>any action based upon its contents, nor copy or show it to anyone. Please
>>contact the sender if you believe you have received this email in error.
>>Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>>Services India LLP is a company incorporated in India and is operated
>>under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>>a company incorporated in Brasil and is operated under license from Shape
>>Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
>>South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
>>is a registered trademark.
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.



-- 
Daan

Re: [ANNOUNCE] Karen Voung as a new PMC member of CloudStack

[Daan Hoogland]

Ah, someone to keep the cowboys in line. success Karen.

On Fri, Jul 3, 2015 at 7:20 AM, Koushik Das  wrote:
> Congrats Karen!
>
> -Original Message-
> From: John Burwell [mailto:john.burw...@shapeblue.com]
> Sent: Thursday, 2 July 2015 23:45
> To: dev@cloudstack.apache.org
> Cc: Karen Vuong
> Subject: [ANNOUNCE] Karen Voung as a new PMC member of CloudStack
>
> All,
>
> The Project Management Committee (PMC) for Apache CloudStack are pleased to 
> announce that Karen Voung (karenv) has accepted our invitation to join the 
> PMC.
>
> Please join me in congratulating her.
>
> On behalf of the Apache CloudStack PMC,
> -John Burwell
>
> ---
> John Burwell (@john_burwell)
> VP of Software Engineering, ShapeBlue
> (571) 403-2411 | +44 20 3603 0542
> http://www.shapeblue.com
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build
> CSForge - rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.



-- 
Daan

Re: IRC and Slack

[Rohit Yadav]

+0

Email and MLs are going to stay, so for IMs and chatting we can use one or more 
of such tools. I like Slack, the searchable history and whatnot, but I think 
realtime communication in general may face the same problems as with using IRC.

Another issue with using tools like slack, hipchat etc. are that while they are 
great with their UI/UX and they get the whole platform thing (web, mobile, 
desktop) with their nice looking clients, they don’t offer open protocols and 
therefore don’t offer long term future.

I guess one of the best ways forward would be to keep running the channels on 
IRC and use Slack or whatever wins to become the contemporary IM/collaboration 
tool.

> On 02-Jul-2015, at 2:09 pm, Sebastien Goasguen  wrote:
>
> Hi folks,
>
> IRC has been mostly deserted for a while now. But there are still folks 
> hanging out there with unanswered questions.
>
> I also know of several slack channels on cloudstack.
>
> We need to take a decision here. Shall we officially abandon IRC and out a 
> notice there that points towards Slack.
>
> If we do, how do we invite everyone to the slack channel ?
>
> -Sebastien

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [ANNOUNCE] Karen Voung as a new PMC member of CloudStack

[Rohit Yadav]

Congrats Karen!

> On 02-Jul-2015, at 11:45 pm, John Burwell  wrote:
>
> All,
>
> The Project Management Committee (PMC) for Apache CloudStack are pleased to 
> announce that Karen Voung (karenv) has accepted our invitation to join the 
> PMC.
>
> Please join me in congratulating her.
>
> On behalf of the Apache CloudStack PMC,
> -John Burwell
>
> ---
> John Burwell (@john_burwell)
> VP of Software Engineering, ShapeBlue
> (571) 403-2411 | +44 20 3603 0542
> http://www.shapeblue.com
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build
> CSForge - rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS] Release principles for Apache CloudStack

[Remi Bergsma]

Hi Rajani,

Happy to hear we agree on the goal and on the release process. Also great you 
want to join the RM effort!

What remains is a discussion about the maintenance. I think the difference in 
our approaches, is that you say “commit to release branch, then bring it to 
master” and I say the opposite: “commit to master (pr) and then bring to 
release branch”. There are pros/cons for each.

Let’s first see if we agree on more parts:
- maintenance releases for x.y should only receive bug fixes, no new features
- we should release often and only maintain the current x.y release (and master 
obviously)
- upgrades should be smooth so there is no reason to stay on older releases (we 
should help users upgrade)

I’m trying to understand how the merge workflow would look like. As I’m not a 
hardcore dev, I probably just miss the experience. Let me play a bit with it in 
order to get a good understanding of what you say. That makes it a better 
discussion later on.

Have a nice weekend,

Regards,
Remi


> On 3 jul. 2015, at 13:01, Rajani Karuturi  wrote:
> 
> I agree to the goal. No regressions can be achieved either by cherry-picks
> or merges. Both requires developers to agree to it and has equal
> probability to miss.
> 
> The advantage in case of merge is, lets say you do a commit a1 to 4.5
> branch and forget to merge to master. now, someone else did a2 and is
> trying to merge. He will see both the commits and can make choice either to
> ask about a1 or merge both.
> may be if the merge has conflicts or is not a clean merge, it can be done
> as PR which follows the usual process.
> 
> with respect to refactoring, we can always do separate PRs on master and
> the release branch. The merge from release branch to master in this case
> would be an empty merge (git merge -s ours)
> 
> The problem I see with the current approach is its not always backporting
> the fix to release. This works if the issue reported is already known and
> fixed on master or any forward releases.
> Usually, you work on a release branch only when an issue is reported on it.
> For a issue reported on 4.5, first thing I do is check if the issue really
> exists in 4.5 and would also find the solution around the same time. Its
> sounds natural to me to push to 4.5(get the load off your head whether it
> is customer issue or security issue) and then merge to forward releases.
> Now, with the new process, I will have to first verify if the bug exists in
> the current release+1, fix in it first, then go back to release branch,
> verify if it exists and fix it there.
> Obviously there would be exceptions in merging and you may have to
> cherry-pick once in a while. But, making it the process is what concerns me.
> 
> 
> In addition to the goal mentioned, I would also like to find which all
> versions the commit is present in.
> For example, If a security issue is reported on 4.5, I found that this is a
> regression from commit abcde. Now, I would like to find which all version
> this is present as this security patch should be delivered on all the
> versions.
> In the current situation and also in the new process suggested, the only
> way to find it is to go to each and every release and see if the commit is
> present.
> In the merge route, its simple git merge --contains abcde
> 
> Merging is not easy. It requires discipline. But, it has benefits. If
> everyone follows it, its as easy as cherry-picking as the code diff will be
> exactly same.
> 
> 
> Maintaining a release is the second part of the story :) I do agree with
> you on the release process for 4.6. Lets start with it for 4.6 release and
> continue discussing on how we want to maintain 4.6.x(may be we would never
> need one ;))
> 
> I can volunteer to be the additional RM for 4.6.
> 
> 
> ~Rajani
> 
> On Fri, Jul 3, 2015 at 1:36 PM, Remi Bergsma  > wrote:
> 
>> Hi Rajani, all,
>> 
>> I do think we have the same goal in mind: no regression and no cherry-pick
>> mess.
>> 
>> Just did some reading on "tofu scale" and see two issues:
>> - if it doesn't happen / isn't completed we'll have regression as we've
>> seen before. I want a working model that prevents regression by default or
>> else we will not reach smooth upgrades without introducing old bugs again.
>> - we are doing lots of refactoring work (probably will be doing even more)
>> where this model also will not work because the merge fails to apply
>> cleanly (this is what Erik mentioned yesterday). Fixing that conflict is
>> invisible on the dev-list (as we have no PR) and error prone (not tested
>> before commit, no LGTMs).
>> 
>> Don’t get me wrong, I don’t want the cherry-pick mess we experienced
>> before.
>> 
>> What will be different:
>> - master is stable instead of unstable
>> - we’ll branch off x.y (say 4.6 which is up next) only after a vote on a
>> RC passes. Instead of branching it off first, then make it stable and
>> release it and cherry-pick stuff around. So, no cherry-picking here.
>> -

Re: IRC and Slack

[Erik Weber]

On Fri, Jul 3, 2015 at 7:30 PM, Rohit Yadav 
wrote:

> +0
>
> Email and MLs are going to stay, so for IMs and chatting we can use one or
> more of such tools. I like Slack, the searchable history and whatnot, but I
> think realtime communication in general may face the same problems as with
> using IRC.
>
>
No one has suggested to remove the mailing lists as far as I have seen.

The way I see it, there are two groupings with different needs.

 - Developers, who presumably need/wants something that is real time,
chatty, allows easy collaboration and probably feature rich in terms of
integration etc.
 - Users, who might not know anything about the community, where to look,
who to ask etc.  Their entry point is usually by searching the web.

Which makes me believe that the best solution is to have multiple.

- Let devs, power users or anyone that want, to use and idle on any chosen
realtime solution.
  - I don't honestly care if that is IRC, Slack, HipChat or something else,
whatever the majority wants to use is fine by me.
  - If it's possible to be present multiple places, like with an IRC-Slack
integration or similar, that is great.
  - We should look into making the history publicly available without
having to be a registered user at the chosen platform.

- Deploy discourse, askbot or something similar for users. The primary
focus on this solution IMHO should be:
  - easily searchable (via google/bing/whatever),
  - preserve history,
  - atleast be readable without having to sign up

By combining #cloudstack and #cloudstack-dev it's not like we abandon the
users part of IRC, but we can still use something on the web as the primary
place.

A perspective, and I'm sorry to bring in 'OtherStack', but it is what we're
usually compared to;

http://ask.openstack.org currently has 13.281 questions, where roughly
2.614 are unanswered. That means a bit over 10.000 answered questions, that
is easily linkable, searchable, visible on google etc.

They have 884 people in the generic #openstack IRC channel, but still point
to the web site for answers in their topic.
Thatl does not limit them from being present at both places.
Their #openstack-dev channel has 483 people, and is generally dead, with a
few exceptions from time to time.

I believe it is time for change, Slack has had more activity the last few
days I've been able to scroll back in history, than #cloudstack-dev
probably has had the last half year.
But that does not imply we have to abandon IRC, it just means that we have
something else as the preferred platform and should mention that in the
topic, by a privmsg on join or similar so that users get aware of it.

-- 
Erik
 - who just started on vacation and planned on staying away from computers
:-)