On 9/3/14, 12:50 PM, "Nikola Đipanov" <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> >>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. > >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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev