Le 04/09/2014 15:36, Gary Kotton a écrit :
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:

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.


On 9/4/14, 3:59 PM, "Thierry Carrez" <thie...@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
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

  - 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 mailing list

OpenStack-dev mailing list

Reply via email to