Open Stack

On Mon, Feb 23, 2015 at 12:24 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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?
>

I don't think are release cadence needs to be coupled with our development
cadence. And I don't think the 6 month development cadence is helping, its
making things worse. But that is a topic for a separate thread.


>
> 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
>>
>>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150223/9a255229/attachment.html>