On 06/24/2015 10:17 PM, Joe Gordon wrote: > > > On Wed, Jun 24, 2015 at 11:42 AM, Kashyap Chamarthy <kcham...@redhat.com > <mailto: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. >
I was expecting to also read a "why" here, since I was not at the summit. > 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. > This is exactly the kind of cognitive dissonance I find hard to not get upset about :) Code is what matters ultimately - the devil _is_ in the details, and I can bet you that it is extremely unlikely that a PTL of any other project is also going to go and do a detailed review of a feature branch in Nova, and have the understanding of the state of the surrounding codebase needed to do it properly. That's what's up to the nova reviewers to deal with. I too wish Nova code was in a place where it was possible to just do "architecture", but I think we all agree it's nowhere near that. With all due respect to you Joe (and I do have a lot of respect for you) - I can't get behind how Nova specs puts process and documents over working and maintainable code. I will never be able to get behind that! I honestly think Nova is today worse off then it could have been, just because of that mindset. You can't "process" away the hard things in coding, sorry. N. __________________________________________________________________________ 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
