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 <[email protected]> wrote: > On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday <[email protected]> > wrote: > > On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery <[email protected]> > 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] https://blueprints.launchpad.net/neutron/+spec/rootwrap-daemon-mode > > > > -- > > > > Kind regards, Yuriy. > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
