I never intended for all 6 RM to be involved in every commit. Just to have
6 in order to spread the load. I just want at least two of them to verify
each merge.
Op wo 13 mei 2015 om 18:32 schreef sebgoa :
>
> On May 13, 2015, at 6:07 PM, David Nalley wrote:
>
> > On Wed, May 13, 2015 at 8:36 AM,
On May 13, 2015, at 6:07 PM, David Nalley wrote:
> On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
> wrote:
>> Hi guys,
>>
>> I hope that’s not too late to react on this one.
>>
>> Having 6 RMs seems a bit too much for me. For PRs containing a few lines of
>> code, just bug fixes or changi
Thanks, David. I really appreciate that!
Should we change the subject to development guidelines? It is also related the
way we commit/push code to git. I can contribute on that by writing a few lines
that would help the community on producing better code (i.e increasing
coverage) and having a c
On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
wrote:
> Hi guys,
>
> I hope that’s not too late to react on this one.
>
> Having 6 RMs seems a bit too much for me. For PRs containing a few lines of
> code, just bug fixes or changing maven files, python, sh, etc it might be
> simple and quick.
Hi guys,
I hope that’s not too late to react on this one.
Having 6 RMs seems a bit too much for me. For PRs containing a few lines of
code, just bug fixes or changing maven files, python, sh, etc it might be
simple and quick. However, if we get a PR with +30 commits and 10k lines added,
it get
> On 11-May-2015, at 2:51 pm, Daan Hoogland wrote:
>
> I'm fine with that: rm must have a reviewer on merges? Seem heavy for
> trivial changes but alright
>
> On Mon, 11 May 2015 14:16 Sebastien Goasguen wrote:
>
>>
>>> On May 11, 2015, at 2:00 PM, Daan Hoogland
>> wrote:
>>>
>>> +1 how about m
I'm fine with that: rm must have a reviewer on merges? Seem heavy for
trivial changes but alright
On Mon, 11 May 2015 14:16 Sebastien Goasguen wrote:
>
> > On May 11, 2015, at 2:00 PM, Daan Hoogland
> wrote:
> >
> > +1 how about my proposal to have 6 RM and demand that at least 2 agree on
> > e
> On May 11, 2015, at 2:00 PM, Daan Hoogland wrote:
>
> +1 how about my proposal to have 6 RM and demand that at least 2 agree on
> each PR?
+0.5
we can say that we need two pairs of eyes to ok the PR for merge.
no need to formally have 6 RMs ?
so 1 RM (you or me) + another pair of eyes would
+1 how about my proposal to have 6 RM and demand that at least 2 agree on
each PR?
Op ma 11 mei 2015 om 09:52 schreef sebgoa :
>
> On May 6, 2015, at 10:59 AM, Daan Hoogland
> wrote:
>
> > I can have a look at the merge of 4.5.1 and am willing to be one of the
> > RMs, not to be the RM!
> >
>
>
On May 6, 2015, at 10:59 AM, Daan Hoogland wrote:
> I can have a look at the merge of 4.5.1 and am willing to be one of the
> RMs, not to be the RM!
>
I can RM as well.
How about we lock down master on wednesday ?
From that point forward we only take PR into master -either you or me- all
ot
Will do tomorrow
On Wed, 6 May 2015 17:27 Rohit Yadav wrote:
> Hi Daan,
>
> I've merged awsapi after it passed travisCI tests and packaging worked
> (Here's a test repo without awsapi package:
> http://packages.bhaisaab.org/cloudstack/nukeawsapi/).
> Please go ahead with merging 4.5 on master. L
Hi Daan,
I've merged awsapi after it passed travisCI tests and packaging worked
(Here's a test repo without awsapi package:
http://packages.bhaisaab.org/cloudstack/nukeawsapi/).
Please go ahead with merging 4.5 on master. Let me know you've time
and bandwidth to do it otherwise I can help with tha
Fcourse
On Wed, 6 May 2015 15:02 Sebastien Goasguen wrote:
> Can you sync with Rohit, who is merging the noawsapi stuff as well..
>
> > On May 6, 2015, at 10:59 AM, Daan Hoogland
> wrote:
> >
> > I can have a look at the merge of 4.5.1 and am willing to be one of the
> > RMs, not to be the RM!
Can you sync with Rohit, who is merging the noawsapi stuff as well..
> On May 6, 2015, at 10:59 AM, Daan Hoogland wrote:
>
> I can have a look at the merge of 4.5.1 and am willing to be one of the
> RMs, not to be the RM!
>
> Op wo 6 mei 2015 om 09:47 schreef sebgoa :
>
>> So no -1 on this.
>>
I just did a test merge:
~/cloudstack/cloudstack (master)> git merge --no-ff --edit -s ours 4.5
gives a clean merge of the last bits from 4.5 and merges without conflicts
I will rerun a merge and push if the RC passes
Op wo 6 mei 2015 om 10:59 schreef Daan Hoogland :
> I can have a look at the m
I can have a look at the merge of 4.5.1 and am willing to be one of the
RMs, not to be the RM!
Op wo 6 mei 2015 om 09:47 schreef sebgoa :
> So no -1 on this.
>
> Do we have volunteers to RM 4.6 on the master branch ?
>
> I propose to set a date asap, tag master and tell everyone that starting
> f
So no -1 on this.
Do we have volunteers to RM 4.6 on the master branch ?
I propose to set a date asap, tag master and tell everyone that starting from
that tag all commits to master except from RM will be reverted.
will need to make sure that all of 4.5.1 is in master
-sebastien
On May 1, 2
Let's not do more quality improvement proces but just improve quality. If
anybody want to add to the pages on the wiki, you're welkom but nobody did
for long time. +1 for the present state of Sebastien's views on things. We
can refine at any time.
Op vr 1 mei 2015 om 09:55 schreef sebgoa :
>
> On
On May 1, 2015, at 12:52 AM, Pierre-Luc Dion wrote:
> Hi,
>
> In my mind it was kind of making more sense to start by keeping 4.6 into a
> separate branch, enforce pull-requests and deploy the CI. smaller step but
> faster result, and from there, once we get stable with the CI
I hear you.
But
yes, you do :)
Op vr 1 mei 2015 om 05:00 schreef Abhinandan Prateek <
abhinandan.prat...@shapeblue.com>:
> Guys,
>
> Do I see a QACloud in works, something in line with devcloud but with a
> bigger collection of Hypervisors + marvin ?
> If we can bundle these Hypervisors and QA automation then
Guys,
Do I see a QACloud in works, something in line with devcloud but with a
bigger collection of Hypervisors + marvin ?
If we can bundle these Hypervisors and QA automation then effectively we can
have many more people join our QA effort.
> On 29-Apr-2015, at 9:24 pm, Rohit Yadav wrote:
>
On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen wrote:
>
>> On Apr 29, 2015, at 9:49 PM, Marcus wrote:
>>
>> After reviewing the history as mentioned by Daan, unless we propose
>> and vote on a newer workflow model I think the best we can do is to
>> simply be more strict about commits to mas
Hi,
In my mind it was kind of making more sense to start by keeping 4.6 into a
separate branch, enforce pull-requests and deploy the CI. smaller step but
faster result, and from there, once we get stable with the CI and git flow;
move into master, do fastest releases cycle. If we consider we can d
> On Apr 29, 2015, at 9:49 PM, Marcus wrote:
>
> After reviewing the history as mentioned by Daan, unless we propose
> and vote on a newer workflow model I think the best we can do is to
> simply be more strict about commits to master. They all need to be
> merges that have been tested against m
After reviewing the history as mentioned by Daan, unless we propose
and vote on a newer workflow model I think the best we can do is to
simply be more strict about commits to master. They all need to be
merges that have been tested against master before merge. This will in
theory make master more s
Hi Remi,
Thanks. Sure we can work together on this, I guess you would be running
KVM/XenServer on KVM. Ping me if you need help on running ESX 5.x on KVM as it
requires a patched qemu system binary (prebuilt debs here
http://people.apache.org/~bhaisaab/qemu). If these nested hosts are managed b
Hi Rohit,
Nice work!
I agree we need an environment that does run on something else than the local
machine, as we need more horse power. We worked on something similar, where we
have a cluster of KVM controlled by CloudStack in our Employee Cloud and spin
large VMs running CentOS 7.1 (we use 3
Hi Ilya,
In short - to run ESX and other hypervisors (Xen, KVM, OVM3, HyperV etc) on KVM
you need to;
- use patched qemu (tested to work on both Ubuntu 14.04 and 15.04 x64, I’m
waiting for Fedora 22 to test it on F22 as well), you may install the pre-built
debs or build/install qemu from sourc
Rohit
Any headway on ESX 5.5? I've done this many times before using
cloudstack and esx, but i was using esx as parent hypervisor.
The challenge for me was being able to automatically deploy and
configure the vSphere + ESXi env. I managed to get the whole flow
working with bash script, puppe
undlichen Grüßen / With kind regards,
>
> Swen Brüseke
>
> -Ursprüngliche Nachricht-
> Von: Simon Weller [mailto:swel...@ena.com]
> Gesendet: Montag, 20. April 2015 15:24
> An: dev@cloudstack.apache.org
> Betreff: Re: [DISCUSS] 4.6 release management
>
>>
u fork on your own github, pushes to your own branch will run
through Travis as well.
> best,
> Raja
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Friday, April 17, 2015 1:14 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] 4
On Fri, Apr 24, 2015 at 4:53 PM, Rohit Yadav wrote:
> Daan,
>
>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland wrote:
>>
>> Rohit, the issues you mention are not as painful if we release in a
>> two week schedule as the period of creating a fix to seeing it in a
>> release will be shorter. Some relea
Daan,
> On 24-Apr-2015, at 3:53 pm, Daan Hoogland wrote:
>
> Rohit, the issues you mention are not as painful if we release in a
> two week schedule as the period of creating a fix to seeing it in a
> release will be shorter. Some releases will be broken for some people,
> I don't think we can pr
Rohit, the issues you mention are not as painful if we release in a
two week schedule as the period of creating a fix to seeing it in a
release will be shorter. Some releases will be broken for some people,
I don't think we can prevent this. The target we are aiming for is to
big to cover it comple
I think we need to have a faster release management to speed up process in
general, and for that I propose that we have at least two co-pilots for the
release manager who would support them with things like reviewing/merging
patches, creating RC candidates etc whenever necessary. Having only one
Marcus, I think we decided to take small steps in the direction of
something resambling git-workflow instead of adopting it as a
standard. merging branches for fixes and features was one of those
steps. We had a pre-vote discussion on git-flow and it was rejected as
such. That shouldn't stop us fro
Before I rough draft anything, I just wanted to ask if we had voted on
moving to git-workflow, and dropping the multiple release branch
design. This seems like a significant change, and while good in many
ways, it also seems that many users are seeking for point releases to
their pet version and I'
@gmail.com]
Sent: Friday, April 17, 2015 1:14 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] 4.6 release management
> On Apr 17, 2015, at 6:26 AM, Raja Pullela wrote:
>
> +1 for the "Some people (I'm part of them) are concerned on our current way
> of supp
]
Gesendet: Montag, 20. April 2015 15:24
An: dev@cloudstack.apache.org
Betreff: Re: [DISCUSS] 4.6 release management
>
>From: Sebastien Goasguen
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCU
>
>From: Sebastien Goasguen
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] 4.6 release management
> On Apr 18, 2015, at 8:36 AM, Marcus wrote:
>
> Have they diverged that much? Due to
> On Apr 18, 2015, at 8:36 AM, Marcus wrote:
>
> Have they diverged that much? Due to cherry-picking, I guess.
> Otherwise you should be able to do it cleanly.
>
> There's a good opportunity to do this next release. Instead of
> creating a release branch, we freeze master and start creating dev
Have they diverged that much? Due to cherry-picking, I guess.
Otherwise you should be able to do it cleanly.
There's a good opportunity to do this next release. Instead of
creating a release branch, we freeze master and start creating dev
branches.
On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland
We heavily invested in code now on master. Not looking forward to
backporting that.
mobile dev with bilingual spelling checker used (read at your own risk)
Op 17 apr. 2015 21:02 schreef "Marcus" :
> Well, would we just swap the last release branch with master? Master
> is the dev branch, and the
Well, would we just swap the last release branch with master? Master
is the dev branch, and the last release is really what we have as a
stable branch.
On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland wrote:
> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen wrote:
>>
>>> On Apr 17, 2015, at 12
On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen wrote:
>
>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion wrote:
>>
>> Today during the CloudStackdays we did a round table about Release
>> management targeting the next 4.6 releases.
>>
>>
>> Quick bullet point discussions:
>>
>> ideas to cha
; From: Marcus [mailto:shadow...@gmail.com]
> Sent: Friday, April 17, 2015 4:35 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] 4.6 release management
>
> "storage plugin involve changes on Hypervisor code"
>
> I know this is just an example, but at
> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion wrote:
>
> Today during the CloudStackdays we did a round table about Release
> management targeting the next 4.6 releases.
>
>
> Quick bullet point discussions:
>
> ideas to change release planning
>
> - Plugin contribution is complicated b
easing test/BVT coverage, that will be super!
Thanks,
Raja
-Original Message-
From: Marcus [mailto:shadow...@gmail.com]
Sent: Friday, April 17, 2015 4:35 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] 4.6 release management
"storage plugin involve changes on Hypervisor code&q
"storage plugin involve changes on Hypervisor code"
I know this is just an example, but at least on KVM side this is no
longer true. Previously you had to implement a KVM-specific
'StorageAdaptor' that would run on the hypervisor, and register that
with the agent code, but Mike and I added some re
Today during the CloudStackdays we did a round table about Release
management targeting the next 4.6 releases.
Quick bullet point discussions:
ideas to change release planning
- Plugin contribution is complicated because often a new plugin involve
change on the core:
- ex: storage
50 matches
Mail list logo
