Open Stack

On 09/04/2014 02:07 AM, Joe Gordon wrote:
> 
> 
> 
> On Wed, Sep 3, 2014 at 2:50 AM, Nikola Đipanov <ndipanov at redhat.com
> <mailto: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 <mailto: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:
> 
> 
> 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.
> 

This is of course taking my words completely out of context - I was
making a point of how arbitrary changing the number of reviewers needed
is, and how it completely misses the real issues IMHO.

I have no interest in continuing this particular debate further, and
would appreciate if people could refraining from resorting to such
straw-man type arguments, as it can be very damaging to the overall
level of conversation we need to maintain.

> [0] http://lists.openstack.org/pipermail/openstack-dev/2013-July/012073.html
> 
>  
> 
> 
>     * 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.
> 
> 
> 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.
> 
> 
> [1] https://review.openstack.org/#/c/112733/
> 

Yes - I was thinking along similar lines as what you propose on that
patch, too bad if the above sentence came across as implying I had some
kind of cowboy one-man crusade in mind :) it is totally not what I meant.

We need strong consensus on what is important for the project, and we
need hands behind that (both hackers and reviewers). Having a good chunk
of core devs not actually writing critical bits of code is a bad sign IMHO.

I have some additions to your list of priorities which I will add as
comments on the review above (with some other comments of my own), and
we can discuss from there - sorry I missed this! I will likely do that
instead of spamming further with another email as the baseline seems
sufficiently similar to where I stand.

> 
> 
>     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!
> 
> 
> Yes, I can agree with you on this part, things in nova land are not good.
>  
> 

Thanks! Appreciated.

N.