<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 2:50 AM, Nikola Đipanov <span dir="ltr"><<a href="mailto:ndipanov@redhat.com" target="_blank">ndipanov@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 09/02/2014 09:23 PM, Michael Still wrote:<br>
> On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov <<a href="mailto:ndipanov@redhat.com">ndipanov@redhat.com</a>> wrote:<br>
>> On 09/02/2014 08:16 PM, Michael Still wrote:<br>
>>> Hi.<br>
>>><br>
>>> We're soon to hit feature freeze, as discussed in Thierry's recent<br>
>>> email. I'd like to outline the process for requesting a freeze<br>
>>> exception:<br>
>>><br>
>>> * your code must already be up for review<br>
>>> * your blueprint must have an approved spec<br>
>>> * you need three (3) sponsoring cores for an exception to be granted<br>
>><br>
>> Can core reviewers who have features up for review have this number<br>
>> lowered to two (2) sponsoring cores, as they in reality then need four<br>
>> (4) cores (since they themselves are one (1) core but cannot really<br>
>> vote) making it an order of magnitude more difficult for them to hit<br>
>> this checkbox?<br>
><br>
> That's a lot of numbers in that there paragraph.<br>
><br>
> Let me re-phrase your question... Can a core sponsor an exception they<br>
> themselves propose? I don't have a problem with someone doing that,<br>
> but you need to remember that does reduce the number of people who<br>
> have agreed to review the code for that exception.<br>
><br>
<br>
</div>Michael has correctly picked up on a hint of snark in my email, so let<br>
me explain where I was going with that:<br>
<br>
The reason many features including my own may not make the FF is not<br>
because there was not enough buy in from the core team (let's be<br>
completely honest - I have 3+ other core members working for the same<br>
company that are by nature of things easier to convince), but because of<br>
any of the following:<br></blockquote><div><br></div><div>I find the statement about having multiple cores at the same company very concerning. To quote Mark McLoughlin, "It is assumed that all core team members are wearing their "upstream hat" and aren't there merely to represent their employers interests" [0]. Your statement appears to be in direct conflict with Mark's idea of what core reviewer is, and idea that IMHO is one of the basic tenants of OpenStack development.</div>
<div><br></div><div>[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-July/012073.html">http://lists.openstack.org/pipermail/openstack-dev/2013-July/012073.html</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
* Crippling technical debt in some of the key parts of the code<br>
* that we have not been acknowledging as such for a long time<br>
* which leads to proposed code being arbitrarily delayed once it makes<br>
the glaring flaws in the underlying infra apparent<br>
* and that specs process has been completely and utterly useless in<br>
helping uncover (not that process itself is useless, it is very useful<br>
for other things)<br>
<br>
I am almost positive we can turn this rather dire situation around<br>
easily in a matter of months, but we need to start doing it! It will not<br>
happen through pinning arbitrary numbers to arbitrary processes.<br></blockquote><div><br></div><div>Nova is big and complex enough that I don't think any one person is able to identify what we need to work on to make things better. That is one of the reasons why I have the project priorities patch [1] up. I would like to see nova as a team discuss and come up with what we think we need to focus on to get us back on track.</div>
<div><br></div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/112733/">https://review.openstack.org/#/c/112733/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I will follow up with a more detailed email about what I believe we are<br>
missing, once the FF settles and I have applied some soothing creme to<br>
my burnout wounds, but currently my sentiment is:<br>
<br>
Contributing features to Nova nowadays SUCKS!!1 (even as a core<br>
reviewer) We _have_ to change that!<br></blockquote><div><br></div><div>Yes, I can agree with you on this part, things in nova land are not good.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
N.<br>
<br>
> Michael<br>
><br>
>>> * exceptions must be granted before midnight, Friday this week<br>
>>> (September 5) UTC<br>
>>> * the exception is valid until midnight Friday next week<br>
>>> (September 12) UTC when all exceptions expire<br>
>>><br>
>>> For reference, our rc1 drops on approximately 25 September, so the<br>
>>> exception period needs to be short to maximise stabilization time.<br>
>>><br>
>>> John Garbutt and I will both be granting exceptions, to maximise our<br>
>>> timezone coverage. We will grant exceptions as they come in and gather<br>
>>> the required number of cores, although I have also carved some time<br>
>>> out in the nova IRC meeting this week for people to discuss specific<br>
>>> exception requests.<br>
>>><br>
>>> Michael<br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>