<div dir="ltr">Hi Kyle,<div><br></div><div>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.</div>
<div><br></div><div>Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review.</div><div><br></div><div>Regards,</div><div>Rudra</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami <span dir="ltr"><<a href="mailto:dhami@noironetworks.com" target="_blank">dhami@noironetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Kyle:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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")? </div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Salvatore had a good guidance in a related thread [0], do you agree with something like that?</div><div class="gmail_default" style="font-size:small">
<div style="font-family:arial,sans-serif;font-size:13px"><pre style="white-space:pre-wrap;margin-top:1.5em;margin-bottom:1.5em;padding:0px;border:0px;font-size:12px;font-family:'andale mono','lucida console',monospace;vertical-align:baseline;line-height:18.001798629760742px;color:rgb(83,83,83)">
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.</pre></div><div style="font-family:arial,sans-serif;font-size:13px">[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html</a></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><div class="gmail_default" style="font-family:arial;font-size:small"><br></div><div class="gmail_default" style="font-family:arial;font-size:small">
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?</div>
</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday <<a href="mailto:yorik.sar@gmail.com" target="_blank">yorik.sar@gmail.com</a>> wrote:<br>
> On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery <<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>> wrote:<br>
>> and even less<br>
>> possibly rootwrap [3] if the security implications can be worked out.<br>
><br>
> Can you please provide some input on those security implications that are<br>
> not worked out yet?<br>
> I'm really surprised to see such comments in some ML thread not directly<br>
> related to the BP. Why is my spec blocked? Neither spec [1] nor code (which<br>
> is available for a really long time now [2] [3]) can get enough reviewers'<br>
> attention because of those groundless -2's. Should I abandon these change<br>
> requests and file new ones to get some eyes on my code and proposals? It's<br>
> just getting ridiculous. Let's take a look at timeline, shall we?<br>
><br>
</div>I share your concerns here as well, and I'm sorry you've had a bad<br>
experience working with the community here.<br>
<div><div><br>
> Mar, 25 - first version of the first part of Neutron code is published at<br>
> [2]<br>
> Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of<br>
> BP (thankful it wasn't -2 yet, so reviews continued)<br>
> Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created;<br>
> Apr, 2 - first version of the second part of Neutron code is published at<br>
> [3];<br>
> May, 16 - first version of Neutron spec is published at [1];<br>
> May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not<br>
> approved yet);<br>
> May, 21 - first part of Neutron code [2] is found generally OK by reviewers;<br>
> May, 21 - first version of Oslo spec is published at [4];<br>
> May, 29 - a version of the second part of Neutron code [3] is published that<br>
> later raises only minor comments by reviewers;<br>
> Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark<br>
> because BP isn't approved yet;<br>
> Jun, 23 - Oslo spec [4] is mostly ironed out;<br>
> Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2;<br>
> Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change<br>
> requests;<br>
> Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception;<br>
> Jul, 31 - I'm getting final "decision" as follows: "Your BP will extremely<br>
> unlikely get to Juno".<br>
><br>
> Do you see what I see? Code and spec is mostly finished in May (!) where the<br>
> "mostly" part is lack of reviewers because of that Mark's -2. And 1 month<br>
> later when all bureaucratic reasons fall off nothing happens. Don't think I<br>
> didn't try to approach Mark. Don't think I didn't approach Kyle on this<br>
> issue. Because I did. But nothing happens and another month passes by and I<br>
> get "You know, may be later" general response. Noone (but those who knew<br>
> about it originally) even looks at my code for 2 months already because Mark<br>
> doesn't think (I hope he did think) he should lift -2 and I'm getting "why<br>
> not wait another 3 months?"<br>
><br>
> What the hell is that? You don't want to land features that doesn't have<br>
> code 2 weeks before Juno-3, I get that. My code has almost finished code by<br>
> 3.5 months before that! And you're considering to throw it to Kilo because<br>
> of some mystical issues that must've been covered in Oslo spec [4] and if<br>
> you like it they can be covered in Neutron spec [1] but you have to let<br>
> reviewers see it!<br>
><br>
> I don't think that Mark's actions (lack of them, actually) are what's<br>
> expected from core reviewer. No reaction to requests from developer whose<br>
> code got frozen by his -2. No reaction (at least no visible one) to PTL's<br>
> requests (and Kyle assured me he made those). Should we consider Mark<br>
> uncontrollable and unreachable? Why does he have -2 right in the first place<br>
> then? So how should I overcome his inaction? I can recreate new change<br>
> requests and hope he won't just -2 them with no comment at all. But that<br>
> would be just a sign of total failure of our shiny bureaucracy.<br>
><br>
</div></div>I have reached out a few times to Mark, and I'm not going to put words<br>
in his mouth here, but what I can say is that the Neutron Core team<br>
tries it's best to read all BPs and code which are submitted. In this<br>
particular case, there was some dropping of the balls in how we<br>
handled this. Carl has reached out to me a few times on this, and I've<br>
reached out to Mark as well to remove the -2 here. Sometimes, even<br>
with best intentions, things go awry.<br>
<br>
To move forward, there is interest in getting this feature upstream,<br>
maybe even in Juno. But given some concerns I've heard from Mark and<br>
now Thierry, maybe this does make sense to move to Kilo. I'll wait for<br>
Mark to reply on this thread and chime in here, as well as Thierry if<br>
he has more to say. Outside that, if Carl is willing to shepherd this<br>
and we can get Mark to reply, it's still possible we can get this into<br>
Juno.<br>
<br>
Thanks,<br>
Kyle<br>
<div><br>
> [1] <a href="https://review.openstack.org/93889" target="_blank">https://review.openstack.org/93889</a> - Neutron spec<br>
> [2] <a href="https://review.openstack.org/82787" target="_blank">https://review.openstack.org/82787</a> - first part of Neutron code<br>
> [3] <a href="https://review.openstack.org/84667" target="_blank">https://review.openstack.org/84667</a> - second part of Neutron code<br>
> [4] <a href="https://review.openstack.org/94613" target="_blank">https://review.openstack.org/94613</a> - Oslo spec<br>
> [5] <a href="https://blueprints.launchpad.net/oslo/+spec/rootwrap-daemon-mode" target="_blank">https://blueprints.launchpad.net/oslo/+spec/rootwrap-daemon-mode</a><br>
> [6] <a href="https://blueprints.launchpad.net/neutron/+spec/rootwrap-daemon-mode" target="_blank">https://blueprints.launchpad.net/neutron/+spec/rootwrap-daemon-mode</a><br>
><br>
> --<br>
><br>
> Kind regards, Yuriy.<br>
><br>
</div><div><div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>