<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 12:24 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/23/2015 10:09 AM, Daniel P. Berrange wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Feb 23, 2015 at 03:47:20PM +0100, Nikola Đipanov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 02/20/2015 11:33 PM, Sourabh Patwardhan (sopatwar) wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nova core reviewers,<br>
<br>
May I request an FFE for Cisco VIF driver:<br>
<a href="https://review.openstack.org/#/c/157616/" target="_blank">https://review.openstack.org/#<u></u>/c/157616/</a><br>
<br>
This is a small isolated change similar to the vhostuser / open contrail<br>
vif drivers for which FFE has been granted.<br>
</blockquote>
<br>
Actually the FFEs get decided by a subset of the Nova core team called<br>
the nova-drivers. You can see it briefly mentioned here [1]. (*)<br>
<br>
You can see an ethepad that hosts the minutes of the meeting where<br>
nova-drivers were deciding on FFEs at [2] which may give you more<br>
insight into why your BP did not make the cut.<br>
</blockquote>
<br>
Unfortunately the Cisco VIF driver was not on the list of features<br>
considered in the first place, since (AFAICT) this FFE request was<br>
only made after the FFEs had all been decided for Kilo.<br>
<br>
Personally I think the Nova FFE process is too inflexible, and thus<br>
I would support inclusion of this (and any) VIF driver into Kilo<br>
regardless of FFE status for pragmatic reasons, but this appears to<br>
be a minority view right now.<br>
</blockquote>
<br></span>
Count me in on this minority view as well. I also think the FFE process is too inflexible at this time.<br>
<br>
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.<br>
<br>
I know I am bad at saying no to people. I fully acknowledge that fault in myself.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
-jay<span class="im HOEnZb"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(*) On a side note this is an example of us not making the process and<br>
the players clear to our contributors, so we should probably try to<br>
document the role of the nova-drivers better at the very least.<br>
</blockquote>
<br>
As a member of Nova drivers, I personally think that the team should<br>
never have existed in the first place, and should cease to exist at<br>
the soonest opportunity. That it exists at all is just an accident<br>
of history due the use of launchpad for blueprint approval. IMHO it<br>
makes no sense to restrict which cores can participate in feature<br>
review & approval - any Nova core should be able to be choose to<br>
participate as their time allows, without needing to be granted<br>
access to yet another special group.<br>
<br>
Regards,<br>
Daniel<br>
<br>
</blockquote>
<br></span><div class="HOEnZb"><div class="h5">
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>