hi, On Fri, Sep 23, 2016 at 4:20 AM, Armando M. <[email protected]> wrote: > > > On 22 September 2016 at 00:46, reedip banerjee <[email protected]> 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: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
