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
> >> the
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
>> thi
On 09/12/2014 04:59 PM, Joe Gordon wrote:
On Thu, Sep 11, 2014 at 2:18 AM, Daniel P. Berrange mailto:berra...@redhat.com>> wrote:
FYI, for Juno at least I really don't consider that even the libvirt
driver got acceptable review times in any sense. The pain of waiting
for reviews
On Thu, Sep 11, 2014 at 2: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 wrote:
> >
> > > a) Sorting out the common code is already accounted for in Dan B's
> original
> > > proposal -- it's a prere
On 10 September 2014 22:23, Russell Bryant 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 cycle or so.
On 09/11/2014 11:14 AM, Gary Kotton wrote:
>
>
> On 9/11/14, 4:30 PM, "Sean Dague" wrote:
>
>> On 09/11/2014 09:09 AM, Gary Kotton wrote:
>>>
>>>
>>> On 9/11/14, 2:55 PM, "Thierry Carrez" wrote:
>>>
Sean Dague wrote:
> [...]
> Why don't we start with "let's clean up the virt inter
On Thu, 2014-09-11 at 16:20 +0100, Duncan Thomas wrote:
> On 11 September 2014 15:35, James Bottomley
> 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
On 11 September 2014 15:35, James Bottomley
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 contributing team
> to a bunch of them. Th
On 9/11/14, 4:30 PM, "Sean Dague" wrote:
>On 09/11/2014 09:09 AM, Gary Kotton wrote:
>>
>>
>> On 9/11/14, 2:55 PM, "Thierry Carrez" 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
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
>
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 wrote:
> On 09/11/2014 04:30 PM, Sean Dague wrote:
>>
>> On 09/11/2014 09:09 AM, Gary Kotton wrote:
>>>
>>>
>>>
On 11 September 2014 12:36, Sean Dague 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 bigger, and wit
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" 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
On 09/11/2014 09:09 AM, Gary Kotton wrote:
>
>
> On 9/11/14, 2:55 PM, "Thierry Carrez" 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/10/2014 07:23 PM, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes 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
On 9/11/14, 2:55 PM, "Thierry Carrez" 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 will
>> pro
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 underesti
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 wrote:
>>
>>> a) Sorting out the common code is already accounted for in Dan B's original
>>> proposal -- it's a prerequisite for the spl
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
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 t
On Thu, Sep 11, 2014 at 09:23:34AM +1000, Michael Still wrote:
> On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes 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
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
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 Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes 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. I don't object to
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 wi
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 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 impl
-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 Wed, Sep 10, 2014 at 12:34 PM, Stefano Maffulli
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 the interfaces a
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 tea
On Wed, Sep 10, 2014 at 3:44 AM, Daniel P. Berrange 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 core; You wan
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 comm
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 m
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 patc
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 th
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 w
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.
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 suppo
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 g
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 k
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 they're having similar conversations.
I don't have a strong opinion o
41 matches
Mail list logo
