Open Stack

On 9/3/14, 12:50 PM, "Nikola Đipanov" <ndipanov at redhat.com> wrote:

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

+1

Sadly what you have written above is true. The current process does not
encourage new developers in Nova. I really think that we need to work on
improving our community. I really think that maybe we should sit as a
community at the summit and talk about this.



>
>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
>> 
>> 
>> 
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev