[openstack-dev] [neutron][stadium] Query regarding procedure for inclusion in Neutron Stadium

Armando M. armamig at gmail.com
Thu Sep 22 19:20:33 UTC 2016


On 22 September 2016 at 00:46, reedip banerjee <reedip14 at gmail.com> wrote:

> Dear Neutron Core members,
>
> I have a query regarding the procedure for inclusion in the Neutron
> Stadium.
> I wanted to know if a project can apply for Big Tent and Neutron Stadium
> together ( means can a project be accepted in the Neutron Stadium and as a
> result into the Big Tent )
>
> I was checking out the checklist in  [1], and IMO , I think that we need
> to conform to the checklist to be added to the Neutron Stadium ( along with
> the other requirements  like keeping in sync with the core neutron concepts)
>
> But IIUC, certain items in the checklist would be completed if a project
> is already included in the Big Tent.
>

I would not worry about those, as these are rather trivial to implement in
conjunction with Stadium inclusion. I'd worry about the fork that the
project relies on, which is a big show stopper for Stadium inclusion.

[1] https://github.com/openstack/tap-as-a-service/blob/master/setup.cfg#L50


>
> So my doubt is ,should a project apply for the Big Tent first, and after
> inclusion, apply for Neutron Stadium ? Or can a project be integrated to
> Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical about
> this though)?
>

You are confusing the two things. A project either belongs to list [1] or
list [2], and you can't be in both at the same time. To be part of either
list a project must comply with a set of criteria. As for the latter, a
couple of steps may sound like a catch 22: for instance you can't make docs
available on docs.o.o unless you are in [2] and you can't be in [2]
unless...and here's the trick, unless you are a point where you can
successfully demonstrate that the project has substantial documentation (of
any sort, API included). The process of 'demonstrating'/application for
inclusion in list [2] follows the RFE submission process that we have
adopted for a while, and that means submitting a spec. Since the request
does not require a conventional design process, I was going to prepare an
ad-hoc template and make it available soon. So watch the neutron-specs repo
for updates.

In the meantime, I'd urge you to go over the checklist and make sure you
can address the hard parts.

If you ask me, if you go with [1], it makes no sense to go and apply to be
in [2].

HTH
Armando

[1] http://governance.openstack.org/reference/projects/
[2] http://governance.openstack.org/reference/projects/neutron.html


>
>
> [1] http://docs.openstack.org/developer/neutron/stadium/
> governance.html#checklist
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160922/c0c777a7/attachment.html>


More information about the OpenStack-dev mailing list