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