Open Stack

On 02/23/2015 10:09 AM, Daniel P. Berrange wrote:
> On Mon, Feb 23, 2015 at 03:47:20PM +0100, Nikola Đipanov wrote:
>> On 02/20/2015 11:33 PM, Sourabh Patwardhan (sopatwar) wrote:
>>> Nova core reviewers,
>>>
>>> May I request an FFE for Cisco VIF driver:
>>> https://review.openstack.org/#/c/157616/
>>>
>>> This is a small isolated change similar to the vhostuser / open contrail
>>> vif drivers for which FFE has been granted.
>>
>> Actually the FFEs get decided by a subset of the Nova core team called
>> the nova-drivers. You can see it briefly mentioned here [1]. (*)
>>
>> You can see an ethepad that hosts the minutes of the meeting where
>> nova-drivers were deciding on FFEs at [2] which may give you more
>> insight into why your BP did not make the cut.
>
> Unfortunately the Cisco VIF driver was not on the list of features
> considered in the first place, since (AFAICT) this FFE request was
> only made after the FFEs had all been decided for Kilo.
>
> Personally I think the Nova FFE process is too inflexible, and thus
> I would support inclusion of this (and any) VIF driver into Kilo
> regardless of FFE status for pragmatic reasons, but this appears to
> be a minority view right now.

Count me in on this minority view as well. I also think the FFE process 
is too inflexible at this time.

It's a pain in the arse, for sure, for both contributors and reviewers, 
and the blanket policy is really not having the effect intended, IMO. 
It's not like the features and patch series just go away if they don't 
get an FFE. Instead, the contributors (rightfully) hop on IRC and try to 
get ahold of cores to review code and sponsor things.

I know I am bad at saying no to people. I fully acknowledge that fault 
in myself.

That said, I feel we need to be better at considering each request 
separately from each other and acknowledging that some of the patch 
series truly are self-contained, smallish or low-risk, and can be merged 
quickly with the attention and effort from a concerted group of core 
reviewers.

If we, as the core team, are willing to make the effort to evaluate each 
of the requests individually -- as opposed to in a blanket fashion -- 
then perhaps when we say "I'm sorry, this feature is too big for us to 
handle at this point" or "I'm sorry, this feature is too risky for us to 
consider at this point" might not seem so arbitrary to our valued 
contributors.

Here's another thought: is the big-bang integrated 6-month fixed release 
cycle useful any more? Can we talk about using more of a moving train 
model that doesn't have these long freeze cycles? At least for some of 
the projects, I think that would ease some of the minds of folks who are 
dismayed at having to wait yet another 6-9 months to see their code in 
the Nova release.

Seriously, what is the point of 6-month releases again? We are a 
free-form open source set of projects, with a lot of intelligent 
engineers. Why are we stuck using an outdated release model?

Best,
-jay


>> (*) On a side note this is an example of us not making the process and
>> the players clear to our contributors, so we should probably try to
>> document the role of the nova-drivers better at the very least.
>
> As a member of Nova drivers, I personally think that the team should
> never have existed in the first place, and should cease to exist at
> the soonest opportunity. That it exists at all is just an accident
> of history due the use of launchpad for blueprint approval. IMHO it
> makes no sense to restrict which cores can participate in feature
> review & approval - any Nova core should be able to be choose to
> participate as their time allows, without needing to be granted
> access to yet another special group.
>
> Regards,
> Daniel
>