Open Stack

On 3 August 2015 at 20:44, Jesse Cook <jesse.cook at rackspace.com> wrote:
> On 7/29/15, 2:13 PM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com> wrote:
>>We talked a bit about this at the nova mid-cycle last week but I can't
>>say I completely remember all of the points made, since I feel like we
>>talked ourselves into a circle that got us back to more or less 'the
>>current specs and freeze process is the least of all evils so let's not
>>change it'.
>>
>>Tomorrow is the feature freeze for nova but there is interest from a few
>>people in getting rbd snapshot support into liberty.  The code is up for
>>review [1] but the spec is not approved [2].
>>
>>With the process we have in place we can basically -2 this and say
>>re-propose it for mitaka.
>>
>>One thing mentioned at the mid-cycle was what if people reviewed the
>>spec and approved it, but marked the blueprint for 'next' so it's not
>>actually tracked for liberty, but if the blueprint is approved and
>>people are willing to review the code, it could land in liberty.
>>
>>The obvious downside here is the review burden, we have freeze deadlines
>>in place to avoid a continual demand for feature review when we have
>>bugs to fix before we release.  And it's not fair to the other people
>
> Feel free to throw things at me, but is the primary responsibility of a
> core reviewer to review things or fix things?

I think matt was talking about having time to review all the bug fixes
that are currently waiting for review.

The problem at hand, is getting reviews on the bug fixes and priority
features, its not trying to give core reviewers time to write code.

> Horizontal scaling requires more reviewing.

+1

I really think we need to see more reviews from those outside nova-core.
Without that, its really hard to find the people to grow the nova-core team.

Please see my reasons for that approach:
* https://wiki.openstack.org/wiki/Nova/Mentoring#Why_do_code_reviews_if_I_am_not_in_nova-core.3F
* https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_can_I_get_my_code_merged_faster.3F

> I like to imagine a world where core reviewers mentor and
> review and the rest community writes most of the code.
> I assumed that was part of the implicit contract of becoming
> a core reviewer.

I would prefer a world were most of the code and reviews come from
people outside of nova-core. It should be normal for a code to ready
when a core reviewer gets to do a final check. It just doesn't feel
that way right now. Some subteams are starting to do that, but I would
like to see them all step up to review each others code more (in
public, in gerrit), as a starting point.

Personally I find a mix of coding and reviewing good to keep a decent
level of empathy and sanity. I don't have time for any coding this
release (only a bit of documenting), and its not something I can
honestly recommend as a best practice. If people don't maintain a good
level of reviews, we do tend to drop those folks from nova-core.

I know ttx has been pushing for dedicated reviewers. It would be nice
to find folks that can do that, but we just haven't found any of those
people to date.

> One alternative solution is to make core reviewers for specs a different set
> (intersection is acceptable) of people that spend even less time writing code.

Thats what we have today, nova-specs-core.

The problem we are facing right now, is having enough folks to review
all the code for all the specs and blueprints we have already approved
(I think it was just over 100 blueprints for liberty, at its peak),
with out affecting merging high priority bug fixes and all the
priority features. I am trying to ignore the around 100 pending specs
we haven't managed to get merged for liberty, but there is a very
similar problem there.

Thanks,
John