Open Stack

Le 04/09/2014 15:36, Gary Kotton a écrit :
> Hi,
> I do not think that Nova is in a death spiral. I just think that the
> current way of working at the moment is strangling the project. I do not
> understand why we need to split drivers out of the core project. Why not
> have the ability to provide Œcore review¹ status to people for reviewing
> those parts of the code? We have enough talented people in OpenStack to be
> able to write a driver above gerrit to enable that.
> Fragmenting the project will be very unhealthy.
> For what it is worth having a release date at the end of a vacation is
> really bad. Look at the numbers:
> http://stackalytics.com/report/contribution/nova-group/30
> Thanks
> Gary

 From my perspective, the raw number of reviews should not be the only 
metric for saying if someone good for being a core. Indeed, that's quite 
easy to provide some comments on cosmetic but if you see why the patches 
are getting a -1 from a core, that's mostly because of a more important 
design issue or going reverse from another current effort.


Also, I can note that Stackanalytics metrics are *really* different from 
other tools like 
http://russellbryant.net/openstack-stats/nova-reviewers-30.txt

As a non-core people, I can just say that a core people must be at least 
there during Nova meetings and voice his opinions, provide some help 
with the gate status, look at bugs, give feedback to newcomers etc. and 
not just click on -1 or +1


Here, the problem is that the core team is not scalable : I don't want 
to provide examples of governments but just adding more people is often 
not the solution. Instead, providing delegations to subteams seems maybe 
the intermediate solution for helping this as it could help the core 
team to only approve and leave the subteam's half-cores reviewing the 
iterations until they consider the patch enough good for being merged.

Of course, nova cores could still bypass half-cores as they know the 
whole knowledge of Nova, or they could disapprove what the halfcores 
agreed, but that would free a lot of time for cores without giving them 
more bureaucracy.


I really like Dan's proposal of splitting code into different repos with 
separate teams and a single PTL (that's exactly the difference in 
between a Program and a Project) but as it requires some prework, I'm 
just thinking of allocating halfcores as a short-term solution until all 
the bits are sorted out.

And yes, there is urgency, I also felt the pain.

-Sylvain

>
> On 9/4/14, 3:59 PM, "Thierry Carrez" <thierry at openstack.org> wrote:
>
>> Like I mentioned before, I think the only way out of the Nova death
>> spiral is to split code and give control over it to smaller dedicated
>> review teams. This is one way to do it. Thanks Dan for pulling this
>> together :)
>>
>> A couple comments inline:
>>
>> Daniel P. Berrange wrote:
>>> [...]
>>> This is a crisis. A large crisis. In fact, if you got a moment, it's
>>> a twelve-storey crisis with a magnificent entrance hall, carpeting
>>> throughout, 24-hour portage, and an enormous sign on the roof,
>>> saying 'This Is a Large Crisis'. A large crisis requires a large
>>> plan.
>>> [...]
>> I totally agree. We need a plan now, because we can't go through another
>> cycle without a solution in sight.
>>
>>> [...]
>>> This has quite a few implications for the way development would
>>> operate.
>>>
>>>   - The Nova core team at least, would be voluntarily giving up a big
>>>     amount of responsibility over the evolution of virt drivers. Due
>>>     to human nature, people are not good at giving up power, so this
>>>     may be painful to swallow. Realistically current nova core are
>>>     not experts in most of the virt drivers to start with, and more
>>>     important we clearly do not have sufficient time to do a good job
>>>     of review with everything submitted. Much of the current need
>>>     for core review of virt drivers is to prevent the mis-use of a
>>>     poorly defined virt driver API...which can be mitigated - See
>>>     later point(s)
>>>
>>>   - Nova core would/should not have automatic +2 over the virt driver
>>>     repositories since it is unreasonable to assume they have the
>>>     suitable domain knowledge for all virt drivers out there. People
>>>     would of course be able to be members of multiple core teams. For
>>>     example John G would naturally be nova-core and nova-xen-core. I
>>>     would aim for nova-core and nova-libvirt-core, and so on. I do not
>>>     want any +2 responsibility over VMWare/HyperV/Docker drivers since
>>>     they're not my area of expertize - I only look at them today because
>>>     they have no other nova-core representation.
>>>
>>>   - Not sure if it implies the Nova PTL would be solely focused on
>>>     Nova common. eg would there continue to be one PTL over all virt
>>>     driver implementation projects, or would each project have its
>>>     own PTL. Maybe this is irrelevant if a Czars approach is chosen
>>>     by virt driver projects for their work. I'd be inclined to say
>>>     that a single PTL should stay as a figurehead to represent all
>>>     the virt driver projects, acting as a point of contact to ensure
>>>     we keep communication / co-operation between the drivers in sync.
>>> [...]
>> At this point it may look like our current structure (programs, one PTL,
>> single core teams...) prevents us from implementing that solution. I
>> just want to say that in OpenStack, organizational structure reflects
>> how we work, not the other way around. If we need to reorganize
>> "official" project structure to work in smarter and long-term healthy
>> ways, that's a really small price to pay.
>>
>> -- 
>> Thierry Carrez (ttx)
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev