Chris Friesen wrote:
On 09/12/2014 04:59 PM, Joe Gordon wrote:
[...]
Can't you replace the word 'libvirt code' with 'nova code' and this
would still be true? Do you think landing virt driver code is harder
then landing non virt driver code? If so do you have any numbers to back
this up?
If
On Mon, Sep 15, 2014 at 11:00:15AM +0200, Thierry Carrez wrote:
Chris Friesen wrote:
On 09/12/2014 04:59 PM, Joe Gordon wrote:
[...]
Can't you replace the word 'libvirt code' with 'nova code' and this
would still be true? Do you think landing virt driver code is harder
then landing non
On Thu, Sep 11, 2014 at 2:18 AM, Daniel P. Berrange berra...@redhat.com
wrote:
On Thu, Sep 11, 2014 at 09:23:34AM +1000, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's
original
On Thu, Sep 11, 2014 at 09:23:34AM +1000, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's original
proposal -- it's a prerequisite for the split.
Its a big prerequisite though. I
On Wed, Sep 10, 2014 at 07:35:05PM -0700, Armando M. wrote:
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing cycle or so.
Likely, this effort is going to take
On 09/10/2014 06:11 PM, Jay Pipes wrote:
On 09/10/2014 05:55 PM, Chris Friesen wrote:
On 09/10/2014 02:44 AM, Daniel P. Berrange wrote:
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
I have the impression this idea has been circling around for a while
but
for some
On 09/11/2014 05:18 AM, Daniel P. Berrange wrote:
On Thu, Sep 11, 2014 at 09:23:34AM +1000, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's original
proposal -- it's a prerequisite for
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think there is any disagreement there. If it's
going to take a cycle, it's going to take a cycle anyway (it will
probably take 2 cycles, realistically, we always underestimate
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think there is any disagreement there. If it's
going to take a cycle, it's going to take a cycle anyway (it
On 09/10/2014 07:23 PM, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's original
proposal -- it's a prerequisite for the split.
Its a big prerequisite though. I think we're talking
On 09/11/2014 09:09 AM, Gary Kotton wrote:
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think there is any disagreement there. If it's
going to take a
On 09/11/2014 04:30 PM, Sean Dague wrote:
On 09/11/2014 09:09 AM, Gary Kotton wrote:
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think there is any
On 11 September 2014 12:36, Sean Dague s...@dague.net wrote:
I continue to not understand how N non overlapping teams makes this any
better. You have to pay the integration cost somewhere. Right now we're
trying to pay it 1 patch at a time. This model means the integration
units get much
Rados,
personally, i'd want a human to do the +W. Also the critieria would
include a 3) which is the CI for the driver if applicable.
On Thu, Sep 11, 2014 at 9:53 AM, Radoslav Gerganov rgerga...@vmware.com wrote:
On 09/11/2014 04:30 PM, Sean Dague wrote:
On 09/11/2014 09:09 AM, Gary Kotton
On Thu, 2014-09-11 at 07:36 -0400, Sean Dague wrote:
b) The conflict Dan is speaking of is around the current situation where
we
have a limited core review team bandwidth and we have to pick and choose
which virt driver-specific features we will review. This leads to bad
feelings and
On 9/11/14, 4:30 PM, Sean Dague s...@dague.net wrote:
On 09/11/2014 09:09 AM, Gary Kotton wrote:
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think
On 11 September 2014 15:35, James Bottomley
james.bottom...@hansenpartnership.com wrote:
OK, so look at a concrete example: in 2002, the Linux kernel went with
bitkeeper precisely because we'd reached the scaling limit of a single
integration point, so we took the kernel from a single
On Thu, 2014-09-11 at 16:20 +0100, Duncan Thomas wrote:
On 11 September 2014 15:35, James Bottomley
james.bottom...@hansenpartnership.com wrote:
OK, so look at a concrete example: in 2002, the Linux kernel went with
bitkeeper precisely because we'd reached the scaling limit of a single
On 09/11/2014 11:14 AM, Gary Kotton wrote:
On 9/11/14, 4:30 PM, Sean Dague s...@dague.net wrote:
On 09/11/2014 09:09 AM, Gary Kotton wrote:
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt
On 10 September 2014 22:23, Russell Bryant rbry...@redhat.com wrote:
On 09/10/2014 10:35 PM, Armando M. wrote:
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
To me, this means you don't really want a sin bin where you dump
drivers and tell them not to come out until they're fit to be
reviewed by the core; You want a trusted driver community which does
its own reviews and means
Le 10/09/2014 10:44, Daniel P. Berrange a écrit :
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
To me, this means you don't really want a sin bin where you dump
drivers and tell them not to come out until they're fit to be
reviewed by the core; You want a trusted driver
On Wed, Sep 10, 2014 at 3:44 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
To me, this means you don't really want a sin bin where you dump
drivers and tell them not to come out until they're fit to be
reviewed by the
On 09/10/2014 02:27 AM, Sylvain Bauza wrote:
Well, both proposals can be done : we can create subteams and the
Subteam-Approval Gerrit label right know before Kilo, and we could split
the virt repos by later once the interfaces and prereqs are done.
That's what I mean in fact: create sub team
On Wed, Sep 10, 2014 at 12:34 PM, Stefano Maffulli
stef...@openstack.org wrote:
On 09/10/2014 02:27 AM, Sylvain Bauza wrote:
Well, both proposals can be done : we can create subteams and the
Subteam-Approval Gerrit label right know before Kilo, and we could split
the virt repos by later once
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Wednesday, September 10, 2014 1:45 AM
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
To me, this means you don't really want a sin bin where you dump
drivers and tell them not to come
On 09/10/2014 02:44 AM, Daniel P. Berrange wrote:
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
I have the impression this idea has been circling around for a while but
for some reason or another (like lack of capabilities in gerrit and
other reasons) we never tried to
On 09/10/2014 05:55 PM, Chris Friesen wrote:
On 09/10/2014 02:44 AM, Daniel P. Berrange wrote:
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
I have the impression this idea has been circling around for a while but
for some reason or another (like lack of capabilities in
On 09/10/2014 04:11 PM, Jay Pipes wrote:
On 09/10/2014 05:55 PM, Chris Friesen wrote:
If each hypervisor team mostly only modifies their own code, why would
there be conflict?
As I see it, the only causes for conflict would be in the shared code,
and you'd still need to sort out the issues
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's original
proposal -- it's a prerequisite for the split.
Its a big prerequisite though. I think we're talking about a release
worth of work to get that right.
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing cycle or so.
Likely, this effort is going to take more than two cycles, and would
require a very focused team of people
On 09/10/2014 10:35 PM, Armando M. wrote:
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing cycle or so.
Likely, this effort is going to take more than two
On Mon, Sep 08, 2014 at 05:20:54PM -0700, Stefano Maffulli wrote:
On 09/05/2014 07:07 PM, James Bottomley wrote:
Actually, I don't think this analysis is accurate. Some people are
simply interested in small aspects of a project. It's the scratch your
own itch part of open source. The
On 09/09/14 01:20, Stefano Maffulli wrote:
From conversations with PTLs and core reviewers I get the impression
that lots of drivers contributions come with bad code. These require a
lot of time and reviewers energy to be cleaned up, causing burn out and
bad feelings on all sides. What if we
On Mon, 2014-09-08 at 17:20 -0700, Stefano Maffulli wrote:
On 09/05/2014 07:07 PM, James Bottomley wrote:
Actually, I don't think this analysis is accurate. Some people are
simply interested in small aspects of a project. It's the scratch your
own itch part of open source. The thing
On 09/09/2014 06:55 AM, James Bottomley wrote:
CLAs are a well known and documented barrier to casual contributions
I'm not convinced about this statement, at all. And since I think it's
secondary to what we're discussing, I'll leave it as is and go on.
I've done both ... I do prefer the patch
On 09/05/2014 07:07 PM, James Bottomley wrote:
Actually, I don't think this analysis is accurate. Some people are
simply interested in small aspects of a project. It's the scratch your
own itch part of open source. The thing which makes itch scratchers
not lone wolfs is the desire to go the
A somewhat self-serving way to start to solve this is to make training and
mentoring as the first steps to getting involved with contributions. We would
continue to gradually give more responsibilities as the experience and skills
increase. We do this last part already, but are missing the
On Thu, Sep 04, 2014 at 03:54:28PM -0700, Stefano Maffulli wrote:
Thanks Daniel for taking the time to write such deep message. Obviously
you have thought about this issue for a long time and your opinion comes
from deep personal understanding. I'm adding tags for neutron and
cinder, as I know
39 matches
Mail list logo
