[openstack-dev] [nova] Thoughts on things that don't make freeze cutoffs

Sahid Orentino Ferdjaoui sahid.ferdjaoui at redhat.com
Tue Aug 4 13:47:24 UTC 2015


On Tue, Aug 04, 2015 at 12:54:34PM +0200, Thierry Carrez wrote:
> John Garbutt wrote:
> > [...]
> > 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.
> 
> Hell no! I'd hate dedicated reviewers.
>
> [...]
> This is why I advocate dividing code / reviewers / expertise along
> smaller areas within Nova, so that new people can focus and become a
> master again. What I'm pushing for is creating Nova subteams with their
> own core reviewers, which would be experts and trusted to +2 on a
> defined subset of code.

Yep this makes a lot of sense and unfortunately we bring this idea
every time but nothing seems to move in that way.

Contributors working in Nova feel more and more frustrated.

So specs got approved June 23-25 then about 15 working days to push
all of the code and 12 working days to make it merged. From my
experience working on Nova it's not possible. For instance on libvirt
driver we have one core who does most of the reviews, but we have
problem to find the +2/+W and without to mention problem when he
is author of the fix [1].

We delay good features (with code pushed and waiting reviews) we can
bring to users. I guess users are happy to hear that we are working
hard to improve our code base but perhaps they also want features
without to wait a year (3.1, 95, 98, me, xp...).

And I know that because I'm working every days in Nova since more than
2 years - We have really skilled people who can help.

[1] https://review.openstack.org/#/c/176360/

s.



More information about the OpenStack-dev mailing list