Open Stack

On 2015-03-17 3:22 PM, Emilien Macchi wrote:
> 
> A first question that comes in my mind is: should we continue to manage
> every Puppet module in a different Launchpad project? Or should we
> migrate all modules to a single project.

I prefer multiple Launchpad projects due to the fact that each project
assume you manage one project for every aspect, especially milestones
management. (which is intrinsically linked to bug management)


> So far this is what I think about both solutions, feel free to comment:
> 
> "Having one project per module"
> Pros:
> * Really useful when having the right tools to manage Launchpad, and
> also to manage one module as a real project.
> * The solution scales to the number of modules we support.
> 
> Cons:
> * I think some people don't go on Launchpad because there is so many
> projects (one per module), so they did not subscribe emails or don't
> visit the page very often.

They can subscribe to the project group instead:
https://bugs.launchpad.net/openstack-puppet-modules


> * Each time we create a module (it's not every day, I would say each
> time a new OpenStack project is started), we have to repeat the process
> for a new launchpad project.

It takes me ~2 minutes to create a project. It's not a burden at all for me.

The challenge is with release management at scale. I have a bunch of
tools which I use to create new series, milestones and release them. So
it's not that big of a deal.


> "Having everything in a single project"
> Pro:
> * Release management could be simpler

It's not simpler, especially if you wish to associate bugs to
milestones. You would have to assume that EVERY projects will be part of
a very synchronized release cycle. (which isn't true)

> * A single view for all the bugs in Puppet modules

It exists already:
https://bugs.launchpad.net/openstack-puppet-modules

> * Maybe a bad idea, but we can use tags to track puppet modules issues
> (ie: puppet-openstacklib whould be openstacklib)

I already tried using tags to track issues. The challenge is with
versions and releases management. You cannot associate issues to
milestones unless you make the assume that we have one single version
for ALL our modules. So far, we had occasion where a single module was
released instead of all of them.


> Con:
> * The solution does not scale much, it depends again at how we decide to
> make bug triage and release management;

If we wish to be under the big tent, I think we have to have a strong
bug triage and release management. And having only one LP project is
going to make it difficult, not easier.


-- 
Mathieu