Open Stack

On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery <mestery at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140731/9e0580d8/attachment.html>