Open Stack

On 09/02/2014 09:23 PM, Michael Still wrote:
> On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov <ndipanov at redhat.com> wrote:
>> On 09/02/2014 08:16 PM, Michael Still wrote:
>>> Hi.
>>>
>>> We're soon to hit feature freeze, as discussed in Thierry's recent
>>> email. I'd like to outline the process for requesting a freeze
>>> exception:
>>>
>>>     * your code must already be up for review
>>>     * your blueprint must have an approved spec
>>>     * you need three (3) sponsoring cores for an exception to be granted
>>
>> Can core reviewers who have features up for review have this number
>> lowered to two (2) sponsoring cores, as they in reality then need four
>> (4) cores (since they themselves are one (1) core but cannot really
>> vote) making it an order of magnitude more difficult for them to hit
>> this checkbox?
> 
> That's a lot of numbers in that there paragraph.
> 
> Let me re-phrase your question... Can a core sponsor an exception they
> themselves propose? I don't have a problem with someone doing that,
> but you need to remember that does reduce the number of people who
> have agreed to review the code for that exception.
> 

Michael has correctly picked up on a hint of snark in my email, so let
me explain where I was going with that:

The reason many features including my own may not make the FF is not
because there was not enough buy in from the core team (let's be
completely honest - I have 3+ other core members working for the same
company that are by nature of things easier to convince), but because of
any of the following:

* Crippling technical debt in some of the key parts of the code
* that we have not been acknowledging as such for a long time
* which leads to proposed code being arbitrarily delayed once it makes
the glaring flaws in the underlying infra apparent
* and that specs process has been completely and utterly useless in
helping uncover (not that process itself is useless, it is very useful
for other things)

I am almost positive we can turn this rather dire situation around
easily in a matter of months, but we need to start doing it! It will not
happen through pinning arbitrary numbers to arbitrary processes.

I will follow up with a more detailed email about what I believe we are
missing, once the FF settles and I have applied some soothing creme to
my burnout wounds, but currently my sentiment is:

Contributing features to Nova nowadays SUCKS!!1 (even as a core
reviewer) We _have_ to change that!

N.

> Michael
> 
>>>     * exceptions must be granted before midnight, Friday this week
>>> (September 5) UTC
>>>     * the exception is valid until midnight Friday next week
>>> (September 12) UTC when all exceptions expire
>>>
>>> For reference, our rc1 drops on approximately 25 September, so the
>>> exception period needs to be short to maximise stabilization time.
>>>
>>> John Garbutt and I will both be granting exceptions, to maximise our
>>> timezone coverage. We will grant exceptions as they come in and gather
>>> the required number of cores, although I have also carved some time
>>> out in the nova IRC meeting this week for people to discuss specific
>>> exception requests.
>>>
>>> Michael
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
>