On 09/05/2014 07:40 AM, Daniel P. Berrange wrote:
> On Fri, Sep 05, 2014 at 07:12:37AM -0400, Sean Dague wrote:
>> On 09/05/2014 06:40 AM, Nikola ─Éipanov wrote:
>>> A handy example of this I can think of is the currently granted FFE for
>>> serial consoles - consider how much of the code went into the common
>>> part vs. the libvirt specific part, I would say the ratio is very close
>>> to 1 if not even in favour of the common part (current 4 outstanding
>>> patches are all for core, and out of the 5 merged - only one of them was
>>> purely libvirt specific, assuming virt/ will live in nova-common).
>>>
>>> Joe asked a similar question elsewhere on the thread.
>>>
>>> Once again - I am not against doing it - what I am saying is that we
>>> need to look into this closer as it may not be as big of a win from the
>>> number of changes needed per feature as we may think.
>>>
>>> Just some things to think about with regards to the whole idea, by no
>>> means exhaustive.
>>
>> So maybe the better question is: what are the top sources of technical
>> debt in Nova that we need to address? And if we did, everyone would be
>> more sane, and feel less burnt.
>>
>> Maybe the drivers are the worst debt, and jettisoning them makes them
>> someone else's problem, so that helps some. I'm not entirely convinced
>> right now.
>>
>> I think Cells represents a lot of debt right now. It doesn't fully work
>> with the rest of Nova, and produces a ton of extra code paths special
>> cased for the cells path.
>>
>> The Scheduler has a ton of debt as has been pointed out by the efforts
>> in and around Gannt. The focus has been on the split, but realistically
>> I'm with Jay is that we should focus on the debt, and exposing a REST
>> interface in Nova.
>>
>> What about the Nova objects transition? That continues to be slow
>> because it's basically Dan (with a few other helpers from time to time).
>> Would it be helpful if we did an all hands on deck transition of the
>> rest of Nova for K1 and just get it done? Would be nice to have the bulk
>> of Nova core working on one thing like this and actually be in shared
>> context with everyone else for a while.
> 
> I think the idea that we can tell everyone in Nova what they should
> focus on for a cycle, or more generally, is doomed to failure. This
> isn't a closed source company controlled project where you can dictate
> what everyones priority must be. We must accept that rely on all our
> contributors good will in voluntarily giving their time & resource to
> the projct, to scratch whatever itch they have in the project. We have
> to encourage them to want to work nova and demonstrate that we value
> whatever form of contributor they choose to make. If we have technical
> debt that we think is important to address we need to illustrate /
> show people why they should care about helping. If they none the less
> decide that work isn't for them, we can't just cast them aside and/or
> ignore their contributions, while we get on with other things. This
> is why I think it is important that we split up nova to allow each
> are to self-organize around what they consider to be priorities in
> their area of interest / motivation. Not enabling that is going to
> to continue to kill our community

I'm getting tired of the reprieve that because we are an Open Source
project declaring priorities is pointless, because it's not. I would say
it's actually the exception that a developer wakes up in the morning and
says "I completely disregard what anyone else thinks is important in
this project, this is what I'm going to do today". Because if that's how
they felt they wouldn't choose to be part of a community, they would
just go do their own thing. Lone wolfs by definition don't form
communities.

And the FFE process is firm demonstration that when we pick a small
number of things to look at, they move a lot more quickly.

People are always free to work on whatever they want. But providing some
focus to debt clean up. FFE++ effectively, would be really nice.

        -Sean

-- 
Sean Dague
http://dague.net

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to