Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project
Hi all – I think this might’ve gotten buried a bit in the pre-summit and summit madness. I just wanted to kick the thread – I think this is a really good idea. Dogpiling all plugins into a single LP project makes it really difficult to pick out which bugs affect which plugins – and the ecosystem is only getting bigger. Irina, please add this to the SDK as a best practice when you have time. I’ll talk to plugin teams I’m working with to make sure they know about this, as well. Sheena *From:* Irina Povolotskaya [mailto:ipovolotsk...@mirantis.com] *Sent:* Tuesday, April 19, 2016 9:49 AM *To:* openstack-dev@lists.openstack.org *Subject:* [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project Hi to everyone, as you possibly know (at least, those dev. teams working on their Fuel plugins) we have a fuel-plugins Launchpad project [1] which serves as all-in-one entry point for filing bugs, related to plugin-specific problems. nevertheless, this single project is a bad idea in terms of providing granularity and visibility for each plugin: - it's not possible to make up milestones, unique for every plugin that would coincide with the plugin's version (which is specified in metadata.yaml file) - it's not possible to provide every dev. team with exclusive rights on managing importance, milestones etc. therefore, I would like to propose the following: - if you have your own fuel plugin, create a separate LP project for it e.g.[2] [3]and make up all corresponding groups for managing release cycle of your plugin - if you have some issues with fuel plugin framework itself, please consider filing bugs in fuel project [4] as usual. I would appreciate getting feedback on this idea. if it seems fine, then I'll follow-up with adding instructions into our SDK [5] and the list of already existing LP projects. thanks. [1] https://launchpad.net/fuel-plugins [2] https://launchpad.net/lma-toolchain [3] https://launchpad.net/fuel-plugin-nsxv [4] https://launchpad.net/fuel [5] https://wiki.openstack.org/wiki/Fuel/Plugins -- Best regards, Irina Povolotskaya __ 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
Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project
Hi Irina, I fully support the idea of creating separate launchpad project for each plugin, because plugins have different release cycles and different teams who support them. Fuel Plugin documentation [2] has to be updated with information for plugin developers (how to setup new project) and for users (how to create a bug). Good information on how to create and setup new project can be found here [1]. Thanks, [1] http://docs.openstack.org/infra/manual/creators.html [2] https://wiki.openstack.org/wiki/Fuel/Plugins On Tue, Apr 19, 2016 at 6:49 PM, Irina Povolotskaya < ipovolotsk...@mirantis.com> wrote: > Hi to everyone, > > as you possibly know (at least, those dev. teams working on their Fuel > plugins) we have a fuel-plugins Launchpad project [1] which serves as > all-in-one entry point for filing bugs, related > to plugin-specific problems. > > nevertheless, this single project is a bad idea in terms of providing > granularity and visibility for each plugin: > - it's not possible to make up milestones, unique for every plugin that > would coincide with the plugin's version (which is specified in > metadata.yaml file) > - it's not possible to provide every dev. team with exclusive rights on > managing importance, milestones etc. > > therefore, I would like to propose the following: > - if you have your own fuel plugin, create a separate LP project for it > e.g.[2] [3]and make up all corresponding groups for managing release cycle > of your plugin > - if you have some issues with fuel plugin framework itself, please > consider filing bugs in fuel project [4] as usual. > > I would appreciate getting feedback on this idea. > if it seems fine, then I'll follow-up with adding instructions into our > SDK [5] and the list of already existing LP projects. > > thanks. > > > [1] https://launchpad.net/fuel-plugins > [2] https://launchpad.net/lma-toolchain > [3] https://launchpad.net/fuel-plugin-nsxv > [4] https://launchpad.net/fuel > [5] https://wiki.openstack.org/wiki/Fuel/Plugins > > > -- > Best regards, > > Irina Povolotskaya > > > > > > > > > > > > __ > 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
Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project
On 19/04/16 16:52, Irina Povolotskaya wrote: > Hi to everyone, > > as you possibly know (at least, those dev. teams working on their Fuel > plugins) we have a fuel-plugins Launchpad project [1] which serves as > all-in-one entry point for filing bugs, related > to plugin-specific problems. > > nevertheless, this single project is a bad idea in terms of providing > granularity and visibility for each plugin: > - it's not possible to make up milestones, unique for every plugin that > would coincide with the plugin's version (which is specified in > metadata.yaml file) > - it's not possible to provide every dev. team with exclusive rights on > managing importance, milestones etc. > > therefore, I would like to propose the following: > - if you have your own fuel plugin, create a separate LP project for it > e.g.[2] [3]and make up all corresponding groups for managing release > cycle of your plugin > - if you have some issues with fuel plugin framework itself, please > consider filing bugs in fuel project [4] as usual. > > I would appreciate getting feedback on this idea. > if it seems fine, then I'll follow-up with adding instructions into our > SDK [5] and the list of already existing LP projects. I agree that it is better to have a project for each plugin. For the Calico plugin, we actually already have this [1]. Thanks, Neil [1] https://launchpad.net/fuel-plugin-calico __ 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-dev] [Fuel][Plugins] One plugin - one Launchpad project
Hi to everyone, as you possibly know (at least, those dev. teams working on their Fuel plugins) we have a fuel-plugins Launchpad project [1] which serves as all-in-one entry point for filing bugs, related to plugin-specific problems. nevertheless, this single project is a bad idea in terms of providing granularity and visibility for each plugin: - it's not possible to make up milestones, unique for every plugin that would coincide with the plugin's version (which is specified in metadata.yaml file) - it's not possible to provide every dev. team with exclusive rights on managing importance, milestones etc. therefore, I would like to propose the following: - if you have your own fuel plugin, create a separate LP project for it e.g.[2] [3]and make up all corresponding groups for managing release cycle of your plugin - if you have some issues with fuel plugin framework itself, please consider filing bugs in fuel project [4] as usual. I would appreciate getting feedback on this idea. if it seems fine, then I'll follow-up with adding instructions into our SDK [5] and the list of already existing LP projects. thanks. [1] https://launchpad.net/fuel-plugins [2] https://launchpad.net/lma-toolchain [3] https://launchpad.net/fuel-plugin-nsxv [4] https://launchpad.net/fuel [5] https://wiki.openstack.org/wiki/Fuel/Plugins -- Best regards, Irina Povolotskaya __ 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
