25.06.2015 14:58, Sergey Nikitin пишет:
I've repeatedly stated that the fact that we created an
even smaller
clique of people to approve specs (nova-drivers which is a
tiny subset
of the already faaaar too small nova-core) is madness, as
it creates
an even worse review burden on them, and thus worsens the
bottleneck
than we already have.
I agree that the number of people who can approve specs is too
small at the moment. But relatively few people are actually
reviewing specs so building trust here is difficult.
I agree that the number of people who can approve specs is too small
at the moment too. But I disagree that we have few people who actually
reviews specs.
For example I had a spec (approved for Juno and Kilo, but not approved
for Liberty) https://review.openstack.org/#/c/177112/ which has nine
+1 and zero +2. I implemented this spec a long time ago but I spent
about 2 months to reaprove spec in Liberty. And it's not reapproved yet.
I think it is a good example of improper approach to specs repository
structure. Since specs are tied to release cycle, one should create
specs for a new release cycle from scratch loosing all the history of
considerations and discussion that happened in the past. It would be
much better if corresponding to specs blueprints were responsible for
tagging specs to particular release cycle, while unimplemented specs
remained unmerged until their blueprints get status implemented. This
would make it possible to reflect any differences that appear during
code review in comparison with original spec.
Especially strange for me is that not all nova cores have core status
in nova-specs repository. Now we have 14 nova cores and only 7
nova-spec cores. I think if a contributor worked hard to become a nova
core, he or she is competent to get a nova-spec core status.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
