On Wed, Jun 24, 2015 at 11:42 AM, Kashyap Chamarthy <kcham...@redhat.com> wrote:
> On Wed, Jun 24, 2015 at 10:02:27AM -0500, Matt Riedemann wrote: > > > > > > On 6/24/2015 9:09 AM, Kashyap Chamarthy wrote: > > >On Wed, Jun 24, 2015 at 02:51:38PM +0100, Nikola Đipanov wrote: > > >>On 06/24/2015 02:33 PM, Matt Riedemann wrote: > > [. . .] > > > >This is one of the _baffling_ aspects -- that a so-called "super core" > > >has to approve specs with *no* obvious valid reasons. As Jay Pipes > > >mentioned once, this indeed seems like a vestigial remnant from old > > >times. > > > > > >FWIW, I agree with others on this thread, Nova should get rid of this > > >specific senseless non-process. At least a couple of cycles ago. > > > > Specs were only added a couple of cycles ago... :) And they were added > to > > fill a gap, which has already been pointed out in this thread. So if we > > remove them without a replacement for that gap, we regress. > > Oops, I didn't mean to say that "Specs" as a concept should be gone. > Sorr for poor phrasing. > > My question was answred by Joe Gordon with this review: > > https://review.openstack.org/#/c/184912/ > > A bit more context: We discussed the very issue of adjusting the review rules for nova-specs to give all cores +2 power. But in the end we decided not to in the end. As someone who does a lot of spec reviews, I take +1s from the right people (not always nova-cores) to mean a lot, so much that I regularly will simply skim the spec myself before +2ing it. If a subject matter expert who I trust +1s a spec, that is usually all I need. * +1/-1s from the right people have a lot of power on specs. So the review burden isn't just on the people with '+W' power. We may not have done a great job of making this point clear. * There are many subject matter experts outside nova-core who's vote means a lot. For example PTL's of other projects the spec impacts. > > -- > /kashyap > > __________________________________________________________________________ > 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