On 09/02/2014 09:23 PM, Michael Still wrote: > On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov <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: * 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! 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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev