hi,

On Fri, Sep 23, 2016 at 4:20 AM, Armando M. <arma...@gmail.com> wrote:
>
>
> On 22 September 2016 at 00:46, reedip banerjee <reedi...@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

just a clarification; this is not a fork of ovs-agent. it's a separate agent.

>
>>
>>
>> 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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to