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" <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
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
