Open Stack

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-request at 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