On 09/04/2014 02:07 AM, Joe Gordon wrote: > > > > On Wed, Sep 3, 2014 at 2:50 AM, Nikola Đipanov <ndipa...@redhat.com > <mailto:ndipa...@redhat.com>> wrote: > > On 09/02/2014 09:23 PM, Michael Still wrote: > > On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov > <ndipa...@redhat.com <mailto:ndipa...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
