Open Stack

2014-09-03 20:31 GMT+09:00 Gary Kotton <gkotton at vmware.com>:
>
> 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.

That is important point.
I also have the similar feeling to many people said.
I have a patch series which has started since 2013-03-22, and some patches
were not merged in Juno-3 again because of the review bandwidth.
When I started this work as one new contributor, I could not imagine I needed
much time for it.

After that, through code reviews, sometimes I feel unbalance between each patch.
Some patches are very easy like "fixing typo", "removing unused method".
On the other hand, some patches are very difficult like some frameworks
which affect long-living features. However, we are requiring two +2s for all
patches. Then, easy patches also need much time for reviewing.
I think most new contributors post easy patches as the first step, but they
might feel frustrations now. I think the number of the merged good
patches is more
important than the number of code reviews.
Cannot we consider a single +2 for merging patches case by case?

Thanks
IKen'ichi Ohmichi