Open Stack

On 09/03/2014 07:31 AM, Gary Kotton wrote:
>
> 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.
+2
>> 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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140903/b6100a78/attachment.bin>