Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 09/04/2014 10:25 PM, Solly Ross wrote: Anyway, I think it would be useful to have some sort of page where people could say I'm an SME in X, ask me for reviews and then patch submitters could go and say, oh, I need an someone to review my patch about storage backends, let me ask sross. This is a good point - I've been thinking along similar lines that we really could have a huge win in terms of the review experience by building a tool (maybe a social network looking one :)) that relates reviews to people being able to do them, visualizes reviewer karma and other things that can help make the code submissions and reviews more human friendly. Dan seems to dismiss the idea of improved tooling as something that can get us only thus far, but I am not convinced. However - this will require even more manpower and we are already ridiculously short on that so... N. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
Michael Still wrote: 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 * 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. I'd like to add that every exception approved adds up to create moving parts at a moment where we want to slow down to let QA and Docs and other downstream stakeholders catch up. Obviously, things that are already approved and working their way through the gate should be in early enough to limit this disruption. But in general, targeting more than 25% of your juno-3 velocity to -rc1 is a bit unreasonable. For Nova, that means that more than 7 exceptions is starting to be a stability issue. Please keep that in mind every time you go to support a FFE. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
Le 05/09/2014 13:05, Nikola Đipanov a écrit : On 09/04/2014 10:25 PM, Solly Ross wrote: Anyway, I think it would be useful to have some sort of page where people could say I'm an SME in X, ask me for reviews and then patch submitters could go and say, oh, I need an someone to review my patch about storage backends, let me ask sross. This is a good point - I've been thinking along similar lines that we really could have a huge win in terms of the review experience by building a tool (maybe a social network looking one :)) that relates reviews to people being able to do them, visualizes reviewer karma and other things that can help make the code submissions and reviews more human friendly. Dan seems to dismiss the idea of improved tooling as something that can get us only thus far, but I am not convinced. However - this will require even more manpower and we are already ridiculously short on that so... Why can't we just create some nova groups in Gerrit and provide some docs about which group to be pinged from a file ? -Sylvain N. ___ 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On Fri, Sep 5, 2014 at 4:05 AM, Nikola Đipanov ndipa...@redhat.com wrote: On 09/04/2014 10:25 PM, Solly Ross wrote: Anyway, I think it would be useful to have some sort of page where people could say I'm an SME in X, ask me for reviews and then patch submitters could go and say, oh, I need an someone to review my patch about storage backends, let me ask sross. This is a good point - I've been thinking along similar lines that we really could have a huge win in terms of the review experience by building a tool (maybe a social network looking one :)) that relates reviews to people being able to do them, visualizes reviewer karma and other things that can help make the code submissions and reviews more human friendly. Dan seems to dismiss the idea of improved tooling as something that can get us only thus far, but I am not convinced. However - this will require even more manpower and we are already ridiculously short on that so... I have previously toyed with idea of making such a tool, and if someone else wants to work on it I would be happy to help. N. ___ 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
Well, I'm definitely down to do some work on something like that (especially since the original quote was from me ;-)). Perhaps we should split this off into a separate thread and have some design/feature discussions once the mad rush to get Juno out the door dies down? Best Regards, Solly - Original Message - From: Joe Gordon joe.gord...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Friday, September 5, 2014 4:30:57 PM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno On Fri, Sep 5, 2014 at 4:05 AM, Nikola Đipanov ndipa...@redhat.com wrote: On 09/04/2014 10:25 PM, Solly Ross wrote: Anyway, I think it would be useful to have some sort of page where people could say I'm an SME in X, ask me for reviews and then patch submitters could go and say, oh, I need an someone to review my patch about storage backends, let me ask sross. This is a good point - I've been thinking along similar lines that we really could have a huge win in terms of the review experience by building a tool (maybe a social network looking one :)) that relates reviews to people being able to do them, visualizes reviewer karma and other things that can help make the code submissions and reviews more human friendly. Dan seems to dismiss the idea of improved tooling as something that can get us only thus far, but I am not convinced. However - this will require even more manpower and we are already ridiculously short on that so... I have previously toyed with idea of making such a tool, and if someone else wants to work on it I would be happy to help. N. ___ 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 2 September 2014 19:16, Michael Still mi...@stillhq.com wrote: 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 * 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 Sorry to top post on this, need to clarify this point: your blueprint must have an approved spec I have unapproved the *blueprints* as part of removing things from juno-3. The reason for this is because drivers control the approved status, but not control the milestone. I have added a dated note at the base of each whiteboard, explaining what was happening to the blueprint. Yes, that all kinda sucks, but its what we have right now. This is independent of the spec having been approved, and merged into the specs repo. So we can tell if it got approved into juno still, from looking at the specs for juno here: http://specs.openstack.org/openstack/nova-specs/ Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 2 September 2014 21:36, Dan Genin daniel.ge...@jhuapl.edu wrote: Just out of curiosity, what is the rational behind upping the number of core sponsors for feature freeze exception to 3 if only two +2 are required to merge? In Icehouse, IIRC, two core sponsors was deemed sufficient. We tried having 2 cores in the past, and stuff still didn't get reviewed. Usually, as on of the sponsors had other things crop up that took priority, or just didn't get chance to review it. The idea of 3 being that we can loose one person, and still have enough people to merge the code. If that doesn't work out, then we will try something different next time. It was discussed in the nova-meeting around spec freeze time, and at the mid-cycle a tiny bit, unless I totally miss-remember that. Why do this at all? Well we want cores to focus on bug reviews, post FF. So they need to find extra time to review any of the exceptions, hence the opt in process. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
-Original Message- From: Nikola Đipanov [mailto:ndipa...@redhat.com] Sent: 03 September 2014 10:50 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno snip 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. While agreeing with your overall sentiment, what worries me a tad is implied perception that contributing as a core should somehow be easier that as a mortal.While I might expect cores to produce better initial code, I though the process and standards were intended to be a level playing field. Has anyone looked at the review bandwidth issue from the perspective of whether there has been a change in the amount of time cores now spend contributing vs reviewing ? Maybe there's an opportunity to get cores to mentor non-cores to do the code production, freeing up review cycles ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
One final note: the specs referenced above didn't get approved until Spec Freeze, which seemed to leave me with less time to implement things. In fact, it seemed that a lot of specs didn't get approved until spec freeze. Perhaps if we had more staggered approval of specs, we'd have more staggered submission of patches, and thus less of a sudden influx of patches in the couple weeks before feature proposal freeze. Yeah I think the specs were getting approved too late into the cycle, I was actually surprised at how far out the schedules were going in allowing things in and then allowing exceptions after that. Hopefully the ideas around priorities/slots/runways will help stagger some of this also. I think there is a problem with the pattern that seemed to emerge in June where the J.1 period was taken up with spec review (a lot of good reviews happened early in that period, but the approvals kind of came in a lump at the end) meaning that the implementation work itself only seemed to really kick in during J.2 - and not surprisingly given the complexity of some of the changes ran late into J.3. We also has previously noted didn’t do any prioritization between those specs that were approved - so it was always going to be a race to who managed to get code up for review first. It kind of feels to me as if the ideal model would be if we were doing spec review for K now (i.e during the FF / stabilization period) so that we hit Paris with a lot of the input already registered and a clear idea of the range of things folks want to do.We shouldn't really have to ask for session suggestions for the summit - they should be something that can be extracted from the proposed specs (maybe we do voting across the specs or something like that).In that way the summit would be able to confirm the list of specs for K and the priority order. With the current state of the review queue maybe we can’t quite hit this pattern for K, but would be worth aspiring to for I ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
Sorry for another top post, but I like how Nikola has pulled this problem apart, and wanted to respond directly to his response. On 3 September 2014 10:50, Nikola Đipanov ndipa...@redhat.com wrote: 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 +1 We have problems that need solving. One of the ideas behind the slots proposal is to encourage work on the urgent technical debt, before related features are even approved. * that we have not been acknowledging as such for a long time -1 We keep saying thats cool, but we have to fix/finish XXX first. But... we have been very bad at: * remembering that, and recording that * actually fixing those problems * which leads to proposed code being arbitrarily delayed once it makes the glaring flaws in the underlying infra apparent Sometimes we only spot this stuff in code reviews, where you throw up reading all the code around the change, and see all the extra complexity being added to a fragile bit of the code, and well, then you really don't want to be the person who clicks approve on that. We need to track this stuff better. Every time it happens, we should try make a not to go back there and do more tidy ups. * 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) Yeah, it hasn't helped for this. I don't think we should do this, but I keep thinking about making specs two step: * write generally direction doc * go write the code, maybe upload as WIP * write the documentation part of the spec * get docs merged before any code 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. +1 This is ongoing, but there are some major things, I feel we should stop and fix in kilo. ...and that will make getting features in much worse for a little while, but it will be much better on the other side. 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 Awesome, please catch up with jogo who was also trying to build this list. I would love to continue to contribute to that too. Might be working moving into here: https://etherpad.openstack.org/p/kilo-nova-summit-topics The idea was/is to use that list to decide what fills up the majority of code slots in Juno. but currently my sentiment is: Contributing features to Nova nowadays SUCKS!!1 (even as a core reviewer) We _have_ to change that! Agreed. In addition, our bug list would suggest our users are seeing the impact of this technical debt. My personal feeling is we also need to tidy up our testing debt too: * document major bits that are NOT tested, so users are clear * document what combinations and features we actually see tested up stream * support different levels of testing: on-demand+daily vs every commit * making it easier to interested parties to own and maintain some testing * plan for removing the untested code paths in L * allow for untested code to enter the tree, as experimental, with the expectation it gets removed in the following release if not tested, and architected so that is possible (note this means supporting experimental APIs that can be ripped out at a later date.) We have started doing some of the above work. But I think we need to hold ALL code to the same standard. It seems it will take time to agree on that standard, but the above is an attempt to compromise between speed of innovation and stability. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On Thu, Sep 04, 2014 at 09:05:57AM +, Day, Phil wrote: -Original Message- From: Nikola Đipanov [mailto:ndipa...@redhat.com] Sent: 03 September 2014 10:50 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno snip 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! [snip] Has anyone looked at the review bandwidth issue from the perspective of whether there has been a change in the amount of time cores now spend contributing vs reviewing ? I've certainly spent more time reviewing code in the last 2 dev cycles, not least because I need something todo while waiting for my own code submissions to get reviewed merged (which feels like it is taking longer longer). Despite the huge efforts in review we're barely denting the flow and are having to get ever better at saying no to proposed features to cope. Maybe there's an opportunity to get cores to mentor non-cores to do the code production, freeing up review cycles ? As a core dev I want to feel that I'm still able to do valuable code submission myself, while also doing the important code review work. IOW, I don't want to end up with core team job requiring 100% of time to be spent on review cycles, as from my POV that ends up with little to no job satisfaction. Core needs to be able to maintain a balance between doing review and being able to scratch the itch in their own areas of coding interest. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 09/04/2014 03:36 AM, Dean Troyer wrote: On Wed, Sep 3, 2014 at 7:07 PM, Joe Gordon joe.gord...@gmail.com mailto:joe.gord...@gmail.com wrote: On Wed, Sep 3, 2014 at 2:50 AM, Nikola Đipanov ndipa...@redhat.com mailto:ndipa...@redhat.com wrote: 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. FWIW I read Nikola's 'by nature of things' statement to be more of a representation of the higher-bandwith communication and relationships with co-workers rather than for the company. I hope my reading is not wrong. Thanks for not reading too much into that sentence - yes, this is quite close to what I meant, and used it to make a point of how I think we are focusing on the wrong thing (as already mentioned on the direct response to Joe). N. I know a while back some of the things I was trying to land in multiple projects really benefited from having both the relationships and high-bandwidth communication to 4 PTLs, three of whom were in the same room at the time. There is the perception problem, exactly what Mark also wrote about, when that happens off-line, and I think it is our responsibility (those advocating the reviews, and those responding to them) to note the outcome of those discussions on the record somewhere, IMO preferably in Gerrit. dt -- Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com ___ 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
2014-09-03 20:31 GMT+09:00 Gary Kotton gkot...@vmware.com: 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. 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 9/4/2014 4:21 AM, Day, Phil wrote: One final note: the specs referenced above didn't get approved until Spec Freeze, which seemed to leave me with less time to implement things. In fact, it seemed that a lot of specs didn't get approved until spec freeze. Perhaps if we had more staggered approval of specs, we'd have more staggered submission of patches, and thus less of a sudden influx of patches in the couple weeks before feature proposal freeze. Yeah I think the specs were getting approved too late into the cycle, I was actually surprised at how far out the schedules were going in allowing things in and then allowing exceptions after that. Hopefully the ideas around priorities/slots/runways will help stagger some of this also. I think there is a problem with the pattern that seemed to emerge in June where the J.1 period was taken up with spec review (a lot of good reviews happened early in that period, but the approvals kind of came in a lump at the end) meaning that the implementation work itself only seemed to really kick in during J.2 - and not surprisingly given the complexity of some of the changes ran late into J.3. We also has previously noted didn’t do any prioritization between those specs that were approved - so it was always going to be a race to who managed to get code up for review first. It kind of feels to me as if the ideal model would be if we were doing spec review for K now (i.e during the FF / stabilization period) so that we hit Paris with a lot of the input already registered and a clear idea of the range of things folks want to do.We shouldn't really have to ask for session suggestions for the summit - they should be something that can be extracted from the proposed specs (maybe we do voting across the specs or something like that).In that way the summit would be able to confirm the list of specs for K and the priority order. With the current state of the review queue maybe we can’t quite hit this pattern for K, but would be worth aspiring to for I ? Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I like the idea of having our ducks somewhat in a row for the summit so we can hash out details in design sessions on high-priority specs and reserve time for figuring out what the priorities are. I think that would go a long way in fixing some of the frustrations in the other thread about the mid-cycle meetups being the place where blueprint issues are hashed out rather than the summit, and the design sessions at the summit not feeling productive. But as noted, there is also a feeling right now of focusing on Juno to get that out the door before anyone starts getting distracted with reviewing Kilo specs. And I suppose once Juno is finished no one is going to want to talk about Kilo for awhile due to burnout. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 09/04/2014 11:23 AM, John Garbutt wrote: Sorry for another top post, but I like how Nikola has pulled this problem apart, and wanted to respond directly to his response. Thanks John - I'm glad this caught your eye. On 3 September 2014 10:50, Nikola Đipanov ndipa...@redhat.com wrote: 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 +1 We have problems that need solving. One of the ideas behind the slots proposal is to encourage work on the urgent technical debt, before related features are even approved. As I stated before, my issue with slots was more about the fact that they seem to me like needlessly elaborate process to communicate a simple list of important things we focus on, not what it was trying to accomplish, which I fully support. Not sure where I stand on it still, but if it will get us closer to fixing stuff we really need to fix, then I won't argue with it. * that we have not been acknowledging as such for a long time -1 We keep saying thats cool, but we have to fix/finish XXX first. But... we have been very bad at: * remembering that, and recording that * actually fixing those problems This seems to me ties in with prioritizing important work, like jog0 is proposing on [1]. I am not sure if just prioritizing it will work though, we've had blueprints before that we all agreed were high priority that got delayed and punted mostly because of lack of hands to do the work. I am not sure how to solve this problem. Even with what danpb is proposing on a parallel thread with the drivers - this is still work that needs to be done on the core. Objects is a good example of how this can work, but we must not forget that it had a strong backing and several highly skilled people working on it. This is the part prioritizing won't solve. [1] https://review.openstack.org/#/c/112733/ * which leads to proposed code being arbitrarily delayed once it makes the glaring flaws in the underlying infra apparent Sometimes we only spot this stuff in code reviews, where you throw up reading all the code around the change, and see all the extra complexity being added to a fragile bit of the code, and well, then you really don't want to be the person who clicks approve on that. We need to track this stuff better. Every time it happens, we should try make a not to go back there and do more tidy ups. +1 - absolutely - we definitely lack the grumpy developer who goes in and fixes stuff mentality! * 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) Yeah, it hasn't helped for this. I don't think we should do this, but I keep thinking about making specs two step: * write generally direction doc * go write the code, maybe upload as WIP * write the documentation part of the spec * get docs merged before any code I would say that we need to keep the spec approval as lightweight as possible so that we can make sure we get to the details (where devil resides), sooner rather than later... so maybe a 2-phase process along the lines of: * This feature makes sense for Nova and it is proposed in a reasonable manner (merge quickly in /tentative dir) * This now looks like a coherent whole with the POC code, move spec to a /approved dir, work on the details of the code OR we need to fix some issues, let's see how we can do that and still not make the life of feature proposer a living hell just for hitting a snag. 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. +1 This is ongoing, but there are some major things, I feel we should stop and fix in kilo. ...and that will make getting features in much worse for a little while, but it will be much better on the other side. I really do hope so because all things considered - I don't think Nova is in horrible state, but we need to work on it _now_. Many of these issues have been known for a long time and are just piling up. 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 Awesome, please catch up with jogo who was also trying to build this list. I would love to continue to contribute to that too. Yes - as already said on mu response to jog0 - I missed his proposal and will comment on there. Might be working moving into here: https://etherpad.openstack.org/p/kilo-nova-summit-topics The idea was/is to use
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On Thu, Sep 4, 2014 at 2:23 AM, John Garbutt j...@johngarbutt.com wrote: Sorry for another top post, but I like how Nikola has pulled this problem apart, and wanted to respond directly to his response. On 3 September 2014 10:50, Nikola Đipanov ndipa...@redhat.com wrote: 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 +1 We have problems that need solving. One of the ideas behind the slots proposal is to encourage work on the urgent technical debt, before related features are even approved. * that we have not been acknowledging as such for a long time -1 We keep saying thats cool, but we have to fix/finish XXX first. But... we have been very bad at: * remembering that, and recording that * actually fixing those problems * which leads to proposed code being arbitrarily delayed once it makes the glaring flaws in the underlying infra apparent Sometimes we only spot this stuff in code reviews, where you throw up reading all the code around the change, and see all the extra complexity being added to a fragile bit of the code, and well, then you really don't want to be the person who clicks approve on that. We need to track this stuff better. Every time it happens, we should try make a not to go back there and do more tidy ups. * 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) Yeah, it hasn't helped for this. I don't think we should do this, but I keep thinking about making specs two step: * write generally direction doc * go write the code, maybe upload as WIP * write the documentation part of the spec * get docs merged before any code 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. +1 This is ongoing, but there are some major things, I feel we should stop and fix in kilo. ...and that will make getting features in much worse for a little while, but it will be much better on the other side. 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 Awesome, please catch up with jogo who was also trying to build this list. I would love to continue to contribute to that too. I am not actually trying to build that list yet, right now I am trying to get consensus on the idea of having project priorities: https://review.openstack.org/#/c/112733/ Once that patch lands I was going to start iterating on a kilo priorities patch so we have something written down (in nova-specs) that we can go off for summit planning. Might be working moving into here: https://etherpad.openstack.org/p/kilo-nova-summit-topics The idea was/is to use that list to decide what fills up the majority of code slots in Juno. but currently my sentiment is: Contributing features to Nova nowadays SUCKS!!1 (even as a core reviewer) We _have_ to change that! Agreed. In addition, our bug list would suggest our users are seeing the impact of this technical debt. My personal feeling is we also need to tidy up our testing debt too: * document major bits that are NOT tested, so users are clear * document what combinations and features we actually see tested up stream * support different levels of testing: on-demand+daily vs every commit * making it easier to interested parties to own and maintain some testing * plan for removing the untested code paths in L * allow for untested code to enter the tree, as experimental, with the expectation it gets removed in the following release if not tested, and architected so that is possible (note this means supporting experimental APIs that can be ripped out at a later date.) We have started doing some of the above work. But I think we need to hold ALL code to the same standard. It seems it will take time to agree on that standard, but the above is an attempt to compromise between speed of innovation and stability. Thanks, John ___ 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
things. Best, -jay Best Regards, Solly Ross - Original Message - From: Nikola Đipanov ndipa...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, September 3, 2014 5:50:09 AM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno 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 ___ 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 09/03/2014 02:10 PM, Vladik Romanovsky wrote: +1 I had several pacthes in start lxc from block device series. The blueprint was waiting since Icehouse. In Juno it was approved, however, besides Daniel Berrange no one was looking at these patches. Now it's being pushed to Kilo, regadless of the fact that everything is +2ed. I've reviewed all the patches in this series. The last one had a couple things to address, but otherwise, +2s from me. As mentioned, I'll sponsor the FFE on this. Normally, I don't actively pursue people to get approvals, as I was getting angry pushback from cores, at the begining of my way with openstack. I don't understand what is the proper way to get work done. Don't pursue to get approvals. Persue to get reviews :) And don't worry about finding folks on IRC or email (not the ML) to ping about re-reviewing patches. It's common and expected. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 09/04/2014 08:08 AM, Daniel P. Berrange wrote: As a core dev I want to feel that I'm still able to do valuable code submission myself, while also doing the important code review work. IOW, I don't want to end up with core team job requiring 100% of time to be spent on review cycles, as from my POV that ends up with little to no job satisfaction. Core needs to be able to maintain a balance between doing review and being able to scratch the itch in their own areas of coding interest. Well said. This is something I personally struggle with. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
(see comments inline) - Original Message - From: Jay Pipes jaypi...@gmail.com To: openstack-dev@lists.openstack.org Sent: Thursday, September 4, 2014 2:34:28 PM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno On 09/03/2014 11:57 AM, Solly Ross wrote: 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! I think this is *very* important. rant For instance, I have/had two patch series up. One is of length 2 and is relatively small. It's basically sitting there with one +2 on each patch. I will now most likely have to apply for a FFE to get it merged, not because there's more changes to be made before it can get merged (there was one small nit posted yesterday) or because it's a huge patch that needs a lot of time to review, but because it just took a while to get reviewed by cores, and still only appears to have been looked at by one core. For the other patch series (which is admittedly much bigger), it was hard just to get reviews (and it was something where I actually *really* wanted several opinions, because the patch series touched a couple of things in a very significant way). Now, this is not my first contribution to OpenStack, or to Nova, for that matter. I know things don't always get in. It's frustrating, however, when it seems like the reason something didn't get in wasn't because it was fundamentally flawed, but instead because it didn't get reviews until it was too late to actually take that feedback into account, or because it just didn't get much attention review-wise at all. If I were a new contributor to Nova who had successfully gotten a major blueprint approved and the implemented, only to see it get rejected like this, I might get turned off of Nova, and go to work on one of the other OpenStack projects that seemed to move a bit faster. /rant I see that you have done 7 reviews in the past 90 days. Doing reviews on other people's code goes a long way towards getting some core karma. So, I've tried to get in to reviewing, but my experience tends to be that, even with tools, I spend most of my time trying to find something to review. I've found a few tags that I feel comfortable reviewing (because I know the code paths well enough to give good feedback and not just nits). However, I often find myself on a thread where a couple of cores have already commented, in which case I likely have very little to say. This is not particularly an excuse, just an explanation. The other thing, of course, is that I get/got zoned in writing a large patch series, and didn't stop much to review. For me at least, I would love to be able to put my name into some sort of pool, and said ping me if you need a review of X subjects. If someone actually asked me for a review, I would gladly put down my work for a bit and do a review, but I need to get better and stopping on my own and proactively seeking out reviews. Anyway, I think it would be useful to have some sort of page where people could say I'm an SME in X, ask me for reviews and then patch submitters could go and say, oh, I need an someone to review my patch about storage backends, let me ask sross. So, it's silly to rant without actually providing any ideas on how to fix it. One suggestion would be, for each approved blueprint, to have one or two cores explicitly marked as being responsible for providing at least some feedback on that patch. This proposal has issues, since we have a lot of blueprints and only twenty cores, who also have their own stuff to work on. However, I think the general idea of having guaranteed reviewers is not unsound by itself. Perhaps we should have a loose tier of reviewers between core and everybody else. These reviewers would be known good reviewers who would follow the implementation of particular blueprints if a core did not have the time. Then, when those reviewers gave the +1 to all the patches in a series, they could ping a core, who could feel more comfortable giving a +2 without doing a deep inspection of the code. This is exactly the reason I believe there are so many places in Nova that we have such an astonishing amount of technical debt. Core reviewers are so swamped with the review load that they see +1s from folks that they perceive to be SMEs on certain parts of the code and give a less-than-needed-quality review of the patch and end up +2'ing it too early. It is *precisely* the holistic understanding of multiple parts of the Nova codebase that is the critical piece that having 2 core reviewers sign-off on the patch. Cores are supposed to have a good grasp
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 09/03/2014 07:31 AM, Gary Kotton wrote: 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. +2 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 smime.p7s Description: S/MIME Cryptographic Signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
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! I think this is *very* important. rant For instance, I have/had two patch series up. One is of length 2 and is relatively small. It's basically sitting there with one +2 on each patch. I will now most likely have to apply for a FFE to get it merged, not because there's more changes to be made before it can get merged (there was one small nit posted yesterday) or because it's a huge patch that needs a lot of time to review, but because it just took a while to get reviewed by cores, and still only appears to have been looked at by one core. For the other patch series (which is admittedly much bigger), it was hard just to get reviews (and it was something where I actually *really* wanted several opinions, because the patch series touched a couple of things in a very significant way). Now, this is not my first contribution to OpenStack, or to Nova, for that matter. I know things don't always get in. It's frustrating, however, when it seems like the reason something didn't get in wasn't because it was fundamentally flawed, but instead because it didn't get reviews until it was too late to actually take that feedback into account, or because it just didn't get much attention review-wise at all. If I were a new contributor to Nova who had successfully gotten a major blueprint approved and the implemented, only to see it get rejected like this, I might get turned off of Nova, and go to work on one of the other OpenStack projects that seemed to move a bit faster. /rant So, it's silly to rant without actually providing any ideas on how to fix it. One suggestion would be, for each approved blueprint, to have one or two cores explicitly marked as being responsible for providing at least some feedback on that patch. This proposal has issues, since we have a lot of blueprints and only twenty cores, who also have their own stuff to work on. However, I think the general idea of having guaranteed reviewers is not unsound by itself. Perhaps we should have a loose tier of reviewers between core and everybody else. These reviewers would be known good reviewers who would follow the implementation of particular blueprints if a core did not have the time. Then, when those reviewers gave the +1 to all the patches in a series, they could ping a core, who could feel more comfortable giving a +2 without doing a deep inspection of the code. That's just one suggestion, though. Whatever the solution may be, this is a problem that we need to fix. While I enjoyed going through the blueprint process this cycle (not sarcastic -- I actually enjoyed the whole structured feedback thing), the follow up to that was not the most pleasant. One final note: the specs referenced above didn't get approved until Spec Freeze, which seemed to leave me with less time to implement things. In fact, it seemed that a lot of specs didn't get approved until spec freeze. Perhaps if we had more staggered approval of specs, we'd have more staggered submission of patches, and thus less of a sudden influx of patches in the couple weeks before feature proposal freeze. Best Regards, Solly Ross - Original Message - From: Nikola Đipanov ndipa...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, September 3, 2014 5:50:09 AM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
+1 I had several pacthes in start lxc from block device series. The blueprint was waiting since Icehouse. In Juno it was approved, however, besides Daniel Berrange no one was looking at these patches. Now it's being pushed to Kilo, regadless of the fact that everything is +2ed. Normally, I don't actively pursue people to get approvals, as I was getting angry pushback from cores, at the begining of my way with openstack. I don't understand what is the proper way to get work done. Vladik - Original Message - From: Solly Ross sr...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, September 3, 2014 11:57:29 AM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno 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! I think this is *very* important. rant For instance, I have/had two patch series up. One is of length 2 and is relatively small. It's basically sitting there with one +2 on each patch. I will now most likely have to apply for a FFE to get it merged, not because there's more changes to be made before it can get merged (there was one small nit posted yesterday) or because it's a huge patch that needs a lot of time to review, but because it just took a while to get reviewed by cores, and still only appears to have been looked at by one core. For the other patch series (which is admittedly much bigger), it was hard just to get reviews (and it was something where I actually *really* wanted several opinions, because the patch series touched a couple of things in a very significant way). Now, this is not my first contribution to OpenStack, or to Nova, for that matter. I know things don't always get in. It's frustrating, however, when it seems like the reason something didn't get in wasn't because it was fundamentally flawed, but instead because it didn't get reviews until it was too late to actually take that feedback into account, or because it just didn't get much attention review-wise at all. If I were a new contributor to Nova who had successfully gotten a major blueprint approved and the implemented, only to see it get rejected like this, I might get turned off of Nova, and go to work on one of the other OpenStack projects that seemed to move a bit faster. /rant So, it's silly to rant without actually providing any ideas on how to fix it. One suggestion would be, for each approved blueprint, to have one or two cores explicitly marked as being responsible for providing at least some feedback on that patch. This proposal has issues, since we have a lot of blueprints and only twenty cores, who also have their own stuff to work on. However, I think the general idea of having guaranteed reviewers is not unsound by itself. Perhaps we should have a loose tier of reviewers between core and everybody else. These reviewers would be known good reviewers who would follow the implementation of particular blueprints if a core did not have the time. Then, when those reviewers gave the +1 to all the patches in a series, they could ping a core, who could feel more comfortable giving a +2 without doing a deep inspection of the code. That's just one suggestion, though. Whatever the solution may be, this is a problem that we need to fix. While I enjoyed going through the blueprint process this cycle (not sarcastic -- I actually enjoyed the whole structured feedback thing), the follow up to that was not the most pleasant. One final note: the specs referenced above didn't get approved until Spec Freeze, which seemed to leave me with less time to implement things. In fact, it seemed that a lot of specs didn't get approved until spec freeze. Perhaps if we had more staggered approval of specs, we'd have more staggered submission of patches, and thus less of a sudden influx of patches in the couple weeks before feature proposal freeze. Best Regards, Solly Ross - Original Message - From: Nikola Đipanov ndipa...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, September 3, 2014 5:50:09 AM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On Wed, Sep 3, 2014 at 2:50 AM, 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: 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. [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/ 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. 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On Wed, Sep 3, 2014 at 8:57 AM, Solly Ross sr...@redhat.com wrote: 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! I think this is *very* important. rant For instance, I have/had two patch series up. One is of length 2 and is relatively small. It's basically sitting there with one +2 on each patch. I will now most likely have to apply for a FFE to get it merged, not because there's more changes to be made before it can get merged (there was one small nit posted yesterday) or because it's a huge patch that needs a lot of time to review, but because it just took a while to get reviewed by cores, and still only appears to have been looked at by one core. For the other patch series (which is admittedly much bigger), it was hard just to get reviews (and it was something where I actually *really* wanted several opinions, because the patch series touched a couple of things in a very significant way). Now, this is not my first contribution to OpenStack, or to Nova, for that matter. I know things don't always get in. It's frustrating, however, when it seems like the reason something didn't get in wasn't because it was fundamentally flawed, but instead because it didn't get reviews until it was too late to actually take that feedback into account, or because it just didn't get much attention review-wise at all. If I were a new contributor to Nova who had successfully gotten a major blueprint approved and the implemented, only to see it get rejected like this, I might get turned off of Nova, and go to work on one of the other OpenStack projects that seemed to move a bit faster. /rant So, it's silly to rant without actually providing any ideas on how to fix it. One suggestion would be, for each approved blueprint, to have one or two cores explicitly marked as being responsible for providing at least some feedback on that patch. This proposal has issues, since we have a lot of blueprints and only twenty cores, who also have their own stuff to work on. However, I think the general idea of having guaranteed reviewers is not unsound by itself. Perhaps we should have a loose tier of reviewers between core and everybody else. These reviewers would be known good reviewers who would follow the implementation of particular blueprints if a core did not have the time. Then, when those reviewers gave the +1 to all the patches in a series, they could ping a core, who could feel more comfortable giving a +2 without doing a deep inspection of the code. That's just one suggestion, though. Whatever the solution may be, this is a problem that we need to fix. While I enjoyed going through the blueprint process this cycle (not sarcastic -- I actually enjoyed the whole structured feedback thing), the follow up to that was not the most pleasant. One final note: the specs referenced above didn't get approved until Spec Freeze, which seemed to leave me with less time to implement things. In fact, it seemed that a lot of specs didn't get approved until spec freeze. Perhaps if we had more staggered approval of specs, we'd have more staggered submission of patches, and thus less of a sudden influx of patches in the couple weeks before feature proposal freeze. While you raise some good points, albeit not new ones just long standing issues that we really need to address, Nikola appears to not be commenting on the shortage of reviews but rather on the amount of technical debt Nova has. Best Regards, Solly Ross - Original Message - From: Nikola Đipanov ndipa...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, September 3, 2014 5:50:09 AM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
Joe, 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. Oh this is really bad.., if there is no person that understand what is happening in project and where it should move... IMHO Project can't evolve without straight direction .. So probably it's time to think how to make Nova simpler? (refactoring and so on?) Best regards, Boris Pavlovic On Thu, Sep 4, 2014 at 4:16 AM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Sep 3, 2014 at 8:57 AM, Solly Ross sr...@redhat.com wrote: 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! I think this is *very* important. rant For instance, I have/had two patch series up. One is of length 2 and is relatively small. It's basically sitting there with one +2 on each patch. I will now most likely have to apply for a FFE to get it merged, not because there's more changes to be made before it can get merged (there was one small nit posted yesterday) or because it's a huge patch that needs a lot of time to review, but because it just took a while to get reviewed by cores, and still only appears to have been looked at by one core. For the other patch series (which is admittedly much bigger), it was hard just to get reviews (and it was something where I actually *really* wanted several opinions, because the patch series touched a couple of things in a very significant way). Now, this is not my first contribution to OpenStack, or to Nova, for that matter. I know things don't always get in. It's frustrating, however, when it seems like the reason something didn't get in wasn't because it was fundamentally flawed, but instead because it didn't get reviews until it was too late to actually take that feedback into account, or because it just didn't get much attention review-wise at all. If I were a new contributor to Nova who had successfully gotten a major blueprint approved and the implemented, only to see it get rejected like this, I might get turned off of Nova, and go to work on one of the other OpenStack projects that seemed to move a bit faster. /rant So, it's silly to rant without actually providing any ideas on how to fix it. One suggestion would be, for each approved blueprint, to have one or two cores explicitly marked as being responsible for providing at least some feedback on that patch. This proposal has issues, since we have a lot of blueprints and only twenty cores, who also have their own stuff to work on. However, I think the general idea of having guaranteed reviewers is not unsound by itself. Perhaps we should have a loose tier of reviewers between core and everybody else. These reviewers would be known good reviewers who would follow the implementation of particular blueprints if a core did not have the time. Then, when those reviewers gave the +1 to all the patches in a series, they could ping a core, who could feel more comfortable giving a +2 without doing a deep inspection of the code. That's just one suggestion, though. Whatever the solution may be, this is a problem that we need to fix. While I enjoyed going through the blueprint process this cycle (not sarcastic -- I actually enjoyed the whole structured feedback thing), the follow up to that was not the most pleasant. One final note: the specs referenced above didn't get approved until Spec Freeze, which seemed to leave me with less time to implement things. In fact, it seemed that a lot of specs didn't get approved until spec freeze. Perhaps if we had more staggered approval of specs, we'd have more staggered submission of patches, and thus less of a sudden influx of patches in the couple weeks before feature proposal freeze. While you raise some good points, albeit not new ones just long standing issues that we really need to address, Nikola appears to not be commenting on the shortage of reviews but rather on the amount of technical debt Nova has. Best Regards, Solly Ross - Original Message - From: Nikola Đipanov ndipa...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, September 3, 2014 5:50:09 AM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On 9/3/2014 10:57 AM, Solly Ross wrote: 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! I think this is *very* important. rant For instance, I have/had two patch series up. One is of length 2 and is relatively small. It's basically sitting there with one +2 on each patch. I will now most likely have to apply for a FFE to get it merged, not because there's more changes to be made before it can get merged (there was one small nit posted yesterday) or because it's a huge patch that needs a lot of time to review, but because it just took a while to get reviewed by cores, and still only appears to have been looked at by one core. For the other patch series (which is admittedly much bigger), it was hard just to get reviews (and it was something where I actually *really* wanted several opinions, because the patch series touched a couple of things in a very significant way). Now, this is not my first contribution to OpenStack, or to Nova, for that matter. I know things don't always get in. It's frustrating, however, when it seems like the reason something didn't get in wasn't because it was fundamentally flawed, but instead because it didn't get reviews until it was too late to actually take that feedback into account, or because it just didn't get much attention review-wise at all. If I were a new contributor to Nova who had successfully gotten a major blueprint approved and the implemented, only to see it get rejected like this, I might get turned off of Nova, and go to work on one of the other OpenStack projects that seemed to move a bit faster. /rant So, it's silly to rant without actually providing any ideas on how to fix it. One suggestion would be, for each approved blueprint, to have one or two cores explicitly marked as being responsible for providing at least some feedback on that patch. This proposal has issues, since we have a lot of blueprints and only twenty cores, who also have their own stuff to work on. However, I think the general idea of having guaranteed reviewers is not unsound by itself. Perhaps we should have a loose tier of reviewers between core and everybody else. These reviewers would be known good reviewers who would follow the implementation of particular blueprints if a core did not have the time. Then, when those reviewers gave the +1 to all the patches in a series, they could ping a core, who could feel more comfortable giving a +2 without doing a deep inspection of the code. That's just one suggestion, though. Whatever the solution may be, this is a problem that we need to fix. While I enjoyed going through the blueprint process this cycle (not sarcastic -- I actually enjoyed the whole structured feedback thing), the follow up to that was not the most pleasant. One final note: the specs referenced above didn't get approved until Spec Freeze, which seemed to leave me with less time to implement things. In fact, it seemed that a lot of specs didn't get approved until spec freeze. Perhaps if we had more staggered approval of specs, we'd have more staggered submission of patches, and thus less of a sudden influx of patches in the couple weeks before feature proposal freeze. Yeah I think the specs were getting approved too late into the cycle, I was actually surprised at how far out the schedules were going in allowing things in and then allowing exceptions after that. Hopefully the ideas around priorities/slots/runways will help stagger some of this also. Best Regards, Solly Ross - Original Message - From: Nikola Đipanov ndipa...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, September 3, 2014 5:50:09 AM Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
On Wed, Sep 3, 2014 at 7:07 PM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Sep 3, 2014 at 2:50 AM, Nikola Đipanov ndipa...@redhat.com wrote: 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. FWIW I read Nikola's 'by nature of things' statement to be more of a representation of the higher-bandwith communication and relationships with co-workers rather than for the company. I hope my reading is not wrong. I know a while back some of the things I was trying to land in multiple projects really benefited from having both the relationships and high-bandwidth communication to 4 PTLs, three of whom were in the same room at the time. There is the perception problem, exactly what Mark also wrote about, when that happens off-line, and I think it is our responsibility (those advocating the reviews, and those responding to them) to note the outcome of those discussions on the record somewhere, IMO preferably in Gerrit. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
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? Thanks, N. * 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
Needing 3 out of 19 instead of 3 out of 20 isn't an order of magnatude according to my calculator. Its much closer/fairer than making it 2/19 vs 3/20. If a change is borderline in that it can only get 2 other cores maybe it doesn't have a strong enough case for an exception. Phil Sent from Samsung Mobile Original message From: Nikola Đipanov Date:02/09/2014 19:41 (GMT+00:00) To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno 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? Thanks, N. * 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
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
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 * 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 -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno
Just out of curiosity, what is the rational behind upping the number of core sponsors for feature freeze exception to 3 if only two +2 are required to merge? In Icehouse, IIRC, two core sponsors was deemed sufficient. Dan On 09/02/2014 02: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 * 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 smime.p7s Description: S/MIME Cryptographic Signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
