Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Carl Baldwin wrote: Armando's point #2 is a good one. I see that we should have raised awareness of this more than we did. The bulk of the discussion and the development work moved over to the oslo team and I focused energy on other things. What I didn't realize was that the importance of this work to Neutron did not transfer along with it and that simply delivering the new functionality in oslo by Juno was not sufficient as Neutron would need time to incorporate it. I am at a point now where I have some time to work on this. If reconsideration for Juno is still an option at this time then I think what we need to do is to resolve the concerns that are still outstanding. I'll admit that I really don't understand what the concerns are. I believe that the security concerns have been addressed. If you still have concerns around the design of this feature please bring them up specifically. At this point I think it's just timing issues. There are 85 Neutron blueprints targeted to juno-3, which is a considerable amount, especially when compared to the 10 merged in juno-2 and the 8 merged in juno-1). Most of that work is already proposed for review, ready to test and merge and still won't make it purely due to reviewers bandwidth. Establishing a review queue and excluding noise (reviews that have less chance of making it) from it is critical to optimize the quantity of features we'll end up merging. The daemon work hasn't merged in oslo.rootwrap yet, the last details are still being ironed out. I take my share of responsibility for some of the delays in reviews there, but the fact is we had to take the time to do it right. The neutron-side code has been ready for some time, but until oslo.rootwrap includes the feature, you can't really review/test that -- which means the daemon stuff is not anywhere near the top of the review pile: it's not even in the pile at this point. I'm not totally convinced it should jump the queue just because that code was written a long time ago. So we can certainly /try/ to include it in Juno, if it's seen as a critical performance-enhancing feature: hope that we can get it in oslo.rootwrap very soon and then propose the neutron code for review and have fast turnaround on it. But I wouldn't bet my money on it -- I think it might make sense to focus on reviewing stuff that is more likely to make it (stuff that is already proposed for review) and have general adoption of a Juno-released rootwrap daemon mode throughout all projects during Kilo. -- 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] [neutron] Spec exceptions are closed, FPF is August 21
+1 I think your suggestions are admirable and would be good if this is taken on board, having a timeframe around items would definitely help focus and ensure reviews in a timely manner. /Alan From: Rudra Rugge [mailto:ru...@contrailsystems.com] Sent: July-31-14 6:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21 Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.commailto:dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.commailto:yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception; Jul, 31 - I'm getting final decision as follows: Your BP will extremely unlikely get to Juno. Do you see what I see? Code and spec is mostly finished in May (!) where the mostly part is lack of reviewers because of that Mark's -2. And 1 month later when all bureaucratic reasons fall off nothing happens. Don't think I didn't try to approach Mark. Don't think I didn't approach Kyle on this issue. Because I did. But nothing happens and another month passes by and I get You know, may be later general response. Noone (but those who knew about it originally) even looks at my code for 2 months already because Mark doesn't think (I hope he did think) he should lift -2 and I'm getting why not wait another 3 months? What the hell is that? You don't want to land features that doesn't have code 2 weeks before Juno-3, I get
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Hi Armando: If a core-reviewer puts a -2, there must be a good reason for it I agree. The problem is that after the initial issue identified in the initial -2 review has been fixed, and the patch updated, it (sometimes) happens that we can not get the original reviewer to re-review that update for weeks - creating the type of issues identified in this thread. I would agree that if this was a one-off scenarios, we should handling this as a specific case as you suggest. Unfortunately, this is not a one-off instance, and hence my request for clearer guidelines from PTL for such cases. Regards, Mandeep On Thu, Jul 31, 2014 at 3:54 PM, Armando M. arma...@gmail.com wrote: It is not my intention debating, pointing fingers and finding culprits, these issues can be addressed in some other context. I am gonna say three things: 1) If a core-reviewer puts a -2, there must be a good reason for it. If other reviewers blindly move on as some people seem to imply here, then those reviewers should probably not review the code at all! My policy is to review all the code I am interested in/I can, regardless of the score. My -1 may be someone's +1 (or vice versa), so 'trusting' someone else's vote is the wrong way to go about this. 2) If we all feel that this feature is important (which I am not sure it was being marked as 'low' in oslo, not sure how it was tracked in Neutron), there is the weekly IRC Neutron meeting to raise awareness, since all cores participate; to the best of my knowledge we never spoke (or barely) of the rootwrap work. 3) If people do want this work in Juno (Carl being one of them), we can figure out how to make one final push, and assess potential regression. We 'rushed' other features late in cycle in the past (like nova/neutron event notifications) and if we keep this disabled by default in Juno, I don't think it's really that risky. I can work with Carl to give the patches some more love. Armando On 31 July 2014 15:40, Rudra Rugge ru...@contrailsystems.com wrote: Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Armando's point #2 is a good one. I see that we should have raised awareness of this more than we did. The bulk of the discussion and the development work moved over to the oslo team and I focused energy on other things. What I didn't realize was that the importance of this work to Neutron did not transfer along with it and that simply delivering the new functionality in oslo by Juno was not sufficient as Neutron would need time to incorporate it. I am at a point now where I have some time to work on this. If reconsideration for Juno is still an option at this time then I think what we need to do is to resolve the concerns that are still outstanding. I'll admit that I really don't understand what the concerns are. I believe that the security concerns have been addressed. If you still have concerns around the design of this feature please bring them up specifically. Thanks, Carl On Thu, Jul 31, 2014 at 4:54 PM, Armando M. arma...@gmail.com wrote: It is not my intention debating, pointing fingers and finding culprits, these issues can be addressed in some other context. I am gonna say three things: 1) If a core-reviewer puts a -2, there must be a good reason for it. If other reviewers blindly move on as some people seem to imply here, then those reviewers should probably not review the code at all! My policy is to review all the code I am interested in/I can, regardless of the score. My -1 may be someone's +1 (or vice versa), so 'trusting' someone else's vote is the wrong way to go about this. 2) If we all feel that this feature is important (which I am not sure it was being marked as 'low' in oslo, not sure how it was tracked in Neutron), there is the weekly IRC Neutron meeting to raise awareness, since all cores participate; to the best of my knowledge we never spoke (or barely) of the rootwrap work. 3) If people do want this work in Juno (Carl being one of them), we can figure out how to make one final push, and assess potential regression. We 'rushed' other features late in cycle in the past (like nova/neutron event notifications) and if we keep this disabled by default in Juno, I don't think it's really that risky. I can work with Carl to give the patches some more love. Armando On 31 July 2014 15:40, Rudra Rugge ru...@contrailsystems.com wrote: Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Hi All: There is no doubt the cores are quite stretched and it does take a finite amount of time to absorb the context and the content of the multitude of patches on any given core reviewer¹s queue. Life happens for everyone and things slip thru the cracks, but this suggestion on a timeline for reassessing the sticky -2 after a response from the patch owner seems very reasonable to adopt. It certainly helps the submitter to make forward progress rather than exit the project in frustration (I know of at least one instance with a contributor expressing this as a reason to move on) and establishes a process so that cores can rely on a automatic throttle mechanism if they suddenly find themselves dealing with other things that are a higher priority for them. Thanks Sridar From: Mandeep Dhami dh...@noironetworks.commailto:dh...@noironetworks.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, August 1, 2014 at 4:53 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21 Hi Armando: If a core-reviewer puts a -2, there must be a good reason for it I agree. The problem is that after the initial issue identified in the initial -2 review has been fixed, and the patch updated, it (sometimes) happens that we can not get the original reviewer to re-review that update for weeks - creating the type of issues identified in this thread. I would agree that if this was a one-off scenarios, we should handling this as a specific case as you suggest. Unfortunately, this is not a one-off instance, and hence my request for clearer guidelines from PTL for such cases. Regards, Mandeep On Thu, Jul 31, 2014 at 3:54 PM, Armando M. arma...@gmail.commailto:arma...@gmail.com wrote: It is not my intention debating, pointing fingers and finding culprits, these issues can be addressed in some other context. I am gonna say three things: 1) If a core-reviewer puts a -2, there must be a good reason for it. If other reviewers blindly move on as some people seem to imply here, then those reviewers should probably not review the code at all! My policy is to review all the code I am interested in/I can, regardless of the score. My -1 may be someone's +1 (or vice versa), so 'trusting' someone else's vote is the wrong way to go about this. 2) If we all feel that this feature is important (which I am not sure it was being marked as 'low' in oslo, not sure how it was tracked in Neutron), there is the weekly IRC Neutron meeting to raise awareness, since all cores participate; to the best of my knowledge we never spoke (or barely) of the rootwrap work. 3) If people do want this work in Juno (Carl being one of them), we can figure out how to make one final push, and assess potential regression. We 'rushed' other features late in cycle in the past (like nova/neutron event notifications) and if we keep this disabled by default in Juno, I don't think it's really that risky. I can work with Carl to give the patches some more love. Armando On 31 July 2014 15:40, Rudra Rugge ru...@contrailsystems.commailto:ru...@contrailsystems.com wrote: Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.commailto:dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Carl Baldwin wrote: Let me know if I can help resolve the concerns around rootwrap. I think in this case, the return on investment could be high with a relatively low investment. I agree the daemon work around oslo.rootwrap is very promising, but this is a bit sensitive so we can't rush it. I'm pretty confident oslo.rootwrap 1.3 (or 2.0) will be available by the Juno release, but realistically I expect most projects to switch to using it during the kilo cycle, rather than in the very last weeks of Juno... -- 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] [neutron] Spec exceptions are closed, FPF is August 21
On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception; Jul, 31 - I'm getting final decision as follows: Your BP will extremely unlikely get to Juno. Do you see what I see? Code and spec is mostly finished in May (!) where the mostly part is lack of reviewers because of that Mark's -2. And 1 month later when all bureaucratic reasons fall off nothing happens. Don't think I didn't try to approach Mark. Don't think I didn't approach Kyle on this issue. Because I did. But nothing happens and another month passes by and I get You know, may be later general response. Noone (but those who knew about it originally) even looks at my code for 2 months already because Mark doesn't think (I hope he did think) he should lift -2 and I'm getting why not wait another 3 months? What the hell is that? You don't want to land features that doesn't have code 2 weeks before Juno-3, I get that. My code has almost finished code by 3.5 months before that! And you're considering to throw it to Kilo because of some mystical issues that must've been covered in Oslo spec [4] and if you like it they can be covered in Neutron spec [1] but you have to let reviewers see it! I don't think that Mark's actions (lack of them, actually) are what's expected from core reviewer. No reaction to requests from developer whose code got frozen by his -2. No reaction (at least no visible one) to PTL's requests (and Kyle assured me he made those). Should we consider Mark uncontrollable and unreachable? Why does he have -2 right in the first place then? So how should I overcome his inaction? I can recreate new change requests and hope he won't just -2 them with no comment at all. But that would be just a sign of total failure of our shiny bureaucracy. [1] https://review.openstack.org/93889 - Neutron spec [2] https://review.openstack.org/82787 - first part of Neutron code [3] https://review.openstack.org/84667 - second part of Neutron code [4] https://review.openstack.org/94613 - Oslo spec [5] https://blueprints.launchpad.net/oslo/+spec/rootwrap-daemon-mode [6] https://blueprints.launchpad.net/neutron/+spec/rootwrap-daemon-mode -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
On Thu, Jul 31, 2014 at 12:30 PM, Thierry Carrez thie...@openstack.org wrote: Carl Baldwin wrote: Let me know if I can help resolve the concerns around rootwrap. I think in this case, the return on investment could be high with a relatively low investment. I agree the daemon work around oslo.rootwrap is very promising, but this is a bit sensitive so we can't rush it. I'm pretty confident oslo.rootwrap 1.3 (or 2.0) will be available by the Juno release, but realistically I expect most projects to switch to using it during the kilo cycle, rather than in the very last weeks of Juno... Neutron has always been considered to be the first adopter of daemon mode. Given all the code on the Neutron side is mostly finished I think we can safely switch Neutron first in Juno and wait for Kilo to switch other projects. -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception; Jul, 31 - I'm getting final decision as follows: Your BP will extremely unlikely get to Juno. Do you see what I see? Code and spec is mostly finished in May (!) where the mostly part is lack of reviewers because of that Mark's -2. And 1 month later when all bureaucratic reasons fall off nothing happens. Don't think I didn't try to approach Mark. Don't think I didn't approach Kyle on this issue. Because I did. But nothing happens and another month passes by and I get You know, may be later general response. Noone (but those who knew about it originally) even looks at my code for 2 months already because Mark doesn't think (I hope he did think) he should lift -2 and I'm getting why not wait another 3 months? What the hell is that? You don't want to land features that doesn't have code 2 weeks before Juno-3, I get that. My code has almost finished code by 3.5 months before that! And you're considering to throw it to Kilo because of some mystical issues that must've been covered in Oslo spec [4] and if you like it they can be covered in Neutron spec [1] but you have to let reviewers see it! I don't think that Mark's actions (lack of them, actually) are what's expected from core reviewer. No reaction to requests from developer whose code got frozen by his -2. No reaction (at least no visible one) to PTL's requests (and Kyle assured me he made those). Should we consider Mark uncontrollable and unreachable? Why does he have -2 right in the first place then? So how should I overcome his inaction? I can recreate new change requests and hope he won't just -2 them with no comment at all. But that would be just a sign of total failure of our shiny bureaucracy. I have reached out a few times to Mark, and I'm not going to put words in his mouth here, but what I can say is that the Neutron Core team tries it's best to read all BPs and code which are submitted. In this particular case, there was some dropping of the balls in how we handled this. Carl has reached out to me a few times on this, and I've reached out to Mark as well to remove the -2 here. Sometimes, even with best intentions, things go awry. To move forward, there is interest in getting this feature upstream, maybe even in Juno. But given some concerns I've heard from Mark and now Thierry, maybe this does make sense to move to Kilo. I'll wait for Mark to reply on this thread and chime in here, as well as Thierry if he has more to say. Outside that, if Carl is willing to shepherd this and we can get Mark to reply, it's still possible we can get this into Juno. Thanks, Kyle [1] https://review.openstack.org/93889 - Neutron spec [2] https://review.openstack.org/82787 - first part of Neutron code [3] https://review.openstack.org/84667 - second part of Neutron code [4] https://review.openstack.org/94613 - Oslo spec [5] https://blueprints.launchpad.net/oslo/+spec/rootwrap-daemon-mode [6]
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception; Jul, 31 - I'm getting final decision as follows: Your BP will extremely unlikely get to Juno. Do you see what I see? Code and spec is mostly finished in May (!) where the mostly part is lack of reviewers because of that Mark's -2. And 1 month later when all bureaucratic reasons fall off nothing happens. Don't think I didn't try to approach Mark. Don't think I didn't approach Kyle on this issue. Because I did. But nothing happens and another month passes by and I get You know, may be later general response. Noone (but those who knew about it originally) even looks at my code for 2 months already because Mark doesn't think (I hope he did think) he should lift -2 and I'm getting why not wait another 3 months? What the hell is that? You don't want to land features that doesn't have code 2 weeks before Juno-3, I get that. My code has almost finished code by 3.5 months before that! And you're considering to throw it to Kilo because of some mystical issues that must've been covered in Oslo spec [4] and if you like it they can be covered in Neutron spec [1] but you have to let reviewers see it! I don't think that Mark's actions (lack of them, actually) are what's expected from core reviewer. No reaction to requests from developer whose code got frozen by his -2. No reaction (at least no visible one) to PTL's requests (and Kyle assured me he made those). Should we consider Mark uncontrollable and unreachable? Why does he have -2 right in the first place then? So how should I overcome his inaction? I can recreate new change requests and hope he won't just -2 them with no comment at all. But that would be just a sign of total failure of our shiny bureaucracy. I have reached out a few times to
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception; Jul, 31 - I'm getting final decision as follows: Your BP will extremely unlikely get to Juno. Do you see what I see? Code and spec is mostly finished in May (!) where the mostly part is lack of reviewers because of that Mark's -2. And 1 month later when all bureaucratic reasons fall off nothing happens. Don't think I didn't try to approach Mark. Don't think I didn't approach Kyle on this issue. Because I did. But nothing happens and another month passes by and I get You know, may be later general response. Noone (but those who knew about it originally) even looks at my code for 2 months already because Mark doesn't think (I hope he did think) he should lift -2 and I'm getting why not wait another 3 months? What the hell is that? You don't want to land features that doesn't have code 2 weeks before Juno-3, I get that. My code has almost finished code by 3.5 months before that! And you're considering to throw it to Kilo because of some mystical issues that must've been covered in Oslo spec [4] and if you like it they can be covered in Neutron spec [1] but you have to let reviewers see it! I don't think that Mark's actions (lack of them, actually) are what's expected from core reviewer. No reaction to requests from developer whose code got
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
It is not my intention debating, pointing fingers and finding culprits, these issues can be addressed in some other context. I am gonna say three things: 1) If a core-reviewer puts a -2, there must be a good reason for it. If other reviewers blindly move on as some people seem to imply here, then those reviewers should probably not review the code at all! My policy is to review all the code I am interested in/I can, regardless of the score. My -1 may be someone's +1 (or vice versa), so 'trusting' someone else's vote is the wrong way to go about this. 2) If we all feel that this feature is important (which I am not sure it was being marked as 'low' in oslo, not sure how it was tracked in Neutron), there is the weekly IRC Neutron meeting to raise awareness, since all cores participate; to the best of my knowledge we never spoke (or barely) of the rootwrap work. 3) If people do want this work in Juno (Carl being one of them), we can figure out how to make one final push, and assess potential regression. We 'rushed' other features late in cycle in the past (like nova/neutron event notifications) and if we keep this disabled by default in Juno, I don't think it's really that risky. I can work with Carl to give the patches some more love. Armando On 31 July 2014 15:40, Rudra Rugge ru...@contrailsystems.com wrote: Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's
[openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
I wanted to send an email to let everyone know where we're at in the Juno cycle. We're hitting our stride in Juno-3 development now, and we have a lot of BPs targeted [1]. Due to this, I'm not going to approve any more spec exceptions other than possibly flavors [2] and even less possibly rootwrap [3] if the security implications can be worked out. The reality is, we're severely oversubscribed as it is, and we won't land even half of the approved BPs in Juno-3. Also, for people with BPs approved for Juno-3, remember Neutron is observing the Feature Proposal Freeze [4], which is August 21. Any BP without code proposed by then will be deferred to Kilo. As always, the dates for the Juno release can be found on the wiki here [5]. Thanks! Kyle [1] https://launchpad.net/neutron/+milestone/juno-3 [2] https://review.openstack.org/#/c/102723/ [3] https://review.openstack.org/#/c/93889/ [4] https://wiki.openstack.org/wiki/FeatureProposalFreeze [5] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Also, can I recommend that to avoid last minute rush of all the code in Juno-3 (and then clogging up the gate at that time), we work as a team to re-review patches that have addressed all previously identified issues? For example, the for the GBP plugin, the first series of patches have been updated to address all issues that were identified, and doing re-review/merge now would reduce the load near the end of the cycle. Regards, Mandeep - On Wed, Jul 30, 2014 at 10:52 AM, Kyle Mestery mest...@mestery.com wrote: I wanted to send an email to let everyone know where we're at in the Juno cycle. We're hitting our stride in Juno-3 development now, and we have a lot of BPs targeted [1]. Due to this, I'm not going to approve any more spec exceptions other than possibly flavors [2] and even less possibly rootwrap [3] if the security implications can be worked out. The reality is, we're severely oversubscribed as it is, and we won't land even half of the approved BPs in Juno-3. Also, for people with BPs approved for Juno-3, remember Neutron is observing the Feature Proposal Freeze [4], which is August 21. Any BP without code proposed by then will be deferred to Kilo. As always, the dates for the Juno release can be found on the wiki here [5]. Thanks! Kyle [1] https://launchpad.net/neutron/+milestone/juno-3 [2] https://review.openstack.org/#/c/102723/ [3] https://review.openstack.org/#/c/93889/ [4] https://wiki.openstack.org/wiki/FeatureProposalFreeze [5] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan ___ 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] [neutron] Spec exceptions are closed, FPF is August 21
Kyle, Let me know if I can help resolve the concerns around rootwrap. I think in this case, the return on investment could be high with a relatively low investment. Carl On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: I wanted to send an email to let everyone know where we're at in the Juno cycle. We're hitting our stride in Juno-3 development now, and we have a lot of BPs targeted [1]. Due to this, I'm not going to approve any more spec exceptions other than possibly flavors [2] and even less possibly rootwrap [3] if the security implications can be worked out. The reality is, we're severely oversubscribed as it is, and we won't land even half of the approved BPs in Juno-3. Also, for people with BPs approved for Juno-3, remember Neutron is observing the Feature Proposal Freeze [4], which is August 21. Any BP without code proposed by then will be deferred to Kilo. As always, the dates for the Juno release can be found on the wiki here [5]. Thanks! Kyle [1] https://launchpad.net/neutron/+milestone/juno-3 [2] https://review.openstack.org/#/c/102723/ [3] https://review.openstack.org/#/c/93889/ [4] https://wiki.openstack.org/wiki/FeatureProposalFreeze [5] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan ___ 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
