On 8/4/2015 8:47 AM, Sahid Orentino Ferdjaoui wrote:
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.
__________________________________________________________________________
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
Yeah so this thread is starting to devolve into scaling the core team
again, which is what I didn't want to happen. The goal was to talk
about how we can line up things in a backlog to still allow review and
possible inclusion to a release after the spec freeze cutoff, but not
necessarily target something for inclusion (like that rbd snapshot
example), and not detract from what has been approved before the spec
freeze cutoff or other priorities.
I think I got the answer from John which is the path forward is starting
to kick the tires on some new tooling like phabricator and then doing
some things with runways / kanban boards so we don't have as rigid a
process, we just queue up things as they come.
So I'm satisfied for now.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
