Open Stack

On 4 August 2015 at 21:23, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
>
>
> 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.
>

So this push towards a kanban/runways style is going to be a big effort.

Please do reach out if you are happy to help make that happen, I
really do need help to make this happen quickly!

It would be great to move over to runways like system sometime in
Mitaka. I have hoped to do it in kilo-3, but its just not worked out
that way :(

Thanks,
John