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