Open Stack

On Thu, Jun 25, 2015 at 1:39 AM, Nikola Đipanov <ndipanov at redhat.com> wrote:

> On 06/24/2015 10:17 PM, Joe Gordon wrote:
> >
> >
> > On Wed, Jun 24, 2015 at 11:42 AM, Kashyap Chamarthy <kchamart at redhat.com
> > <mailto:kchamart at 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.
>

The why is below. But I think its definitely worth revisiting (I am
personally for the patch).


>
> > 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.
>
>
This goes back to the point(s) that was brought up over and over again in
this thread. I guess we have to agree to disagree.

I think saying 'code' is what ultimately matters is misleading.  'Code' is
the implementation of an idea. If an idea is bad, so what if the code is
good?

I wouldn't ask the PTL of say Keystone to review the implementation of some
idea in nova, but I do want their opinion on an idea that impacts how nova
and keystone interact. Why make someone write a bunch of code, only to find
out that the design itself was fundamentally flawed and they have to go
back to the drawing board and throw everything out. On top of that now the
reviewers has to mentally decouple the idea and the code (unless the
feature has good documentation explaining that -- sort of like a spec).

That being said, I do think there is definitely room for improvement.


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


So what are you proposing ultimately?  It sounds like the broad consensus
here is: specs have made things better, but there is room for improvement
(this is my opinion as well). Are you saying just drop specs all together?
Because based on the discussion here, there isn't anything near consensus
for doing that. So if we aren't going to just revert to how things were
before specs, what do you think we should do?


>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150625/38565043/attachment.html>