Re: [openstack-dev] [puppet] Release management and bug triage
On 03/31/2015 11:47 AM, Mathieu Gagné wrote: > On 2015-03-26 1:08 PM, Sebastien Badia wrote: >> >> About lp script, a short search on github (bug mgmt, merged changes): >> >> - https://github.com/openstack-infra/release-tools >> - https://github.com/markmc/openstack-lp-scripts >> - https://github.com/dolph/launchpad >> >> But we wait the publishing of Mathieu scripts :) >> > > Those are great tools. I mainly invested time in the ability to > massively create/update series and milestones (which is a pain) from a > projects.yaml file. > > https://github.com/mgagne/openstack-puppet-release-tools This tool is awesome, we may want to contribute/share to it with other projects. Maybe we could move it to stackforge? Other solution is to keep github pull-request module (something I don't like). Thanks a lot for sharing. -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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] [puppet] Release management and bug triage
On 2015-03-26 1:08 PM, Sebastien Badia wrote: > > About lp script, a short search on github (bug mgmt, merged changes): > > - https://github.com/openstack-infra/release-tools > - https://github.com/markmc/openstack-lp-scripts > - https://github.com/dolph/launchpad > > But we wait the publishing of Mathieu scripts :) > Those are great tools. I mainly invested time in the ability to massively create/update series and milestones (which is a pain) from a projects.yaml file. https://github.com/mgagne/openstack-puppet-release-tools -- Mathieu __ 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] [puppet] Release management and bug triage
On Tue, Mar 17, 2015 at 01:46:06PM (-0700), Colleen Murphy wrote: 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. * 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. I don't think this is that big a hurdle, and it doesn't happen often. "Having everything in a single project" Pro: * Release management could be simpler What would be simpler? We'd still need to track releases of each module, as not all of them always get released at the same time. * A single view for all the bugs in Puppet modules You can view all the bugs in the openstack-puppet-modules top-level project 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) Con: * The solution does not scale much, it depends again at how we decide to make bug triage and release management; Also, feel free to add more concerns or feedback to this discussion. I don't have strong feelings either way, but I'm not sure I see the current way as broken enough to change. There is a top-level project for these subprojects (https://launchpad.net/openstack-puppet-modules). You can create a bug for one project and then add other projects to the bug, so having one ticket that links to multiple modules is possible. Completely agree, the actual layout is almost flexible to ensure that everyone can find the way to subscribe about what he wants. About lp script, a short search on github (bug mgmt, merged changes): - https://github.com/openstack-infra/release-tools - https://github.com/markmc/openstack-lp-scripts - https://github.com/dolph/launchpad But we wait the publishing of Mathieu scripts :) Seb -- Sebastien Badia signature.asc Description: Digital signature __ 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] [puppet] Release management and bug triage
On 2015-03-18 12:26 PM, Emilien Macchi wrote: >> >> 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. > > Are you willing to share it? > Sure. I'll make it a priority to publish it before the end of the week. It needs a bit of cleanup though. =) -- Mathieu __ 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] [puppet] Release management and bug triage
On 03/18/2015 12:23 PM, Mathieu Gagné wrote: > 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. Are you willing to share it? > > >> "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. Big +1. > > -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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] [puppet] Release management and bug triage
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 __ 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] [puppet] Release management and bug triage
Comments inline. On Tue, Mar 17, 2015 at 12:22 PM, Emilien Macchi wrote: > Hi, > > I wanted to start the discussion here about our bug/release management > system with Launchpad. > > 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. > > 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. > * 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. > I don't think this is that big a hurdle, and it doesn't happen often. > > > "Having everything in a single project" > Pro: > * Release management could be simpler > What would be simpler? We'd still need to track releases of each module, as not all of them always get released at the same time. > * A single view for all the bugs in Puppet modules > You can view all the bugs in the openstack-puppet-modules top-level project 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) > > Con: > * The solution does not scale much, it depends again at how we decide to > make bug triage and release management; > > Also, feel free to add more concerns or feedback to this discussion. > I don't have strong feelings either way, but I'm not sure I see the current way as broken enough to change. There is a top-level project for these subprojects (https://launchpad.net/openstack-puppet-modules). You can create a bug for one project and then add other projects to the bug, so having one ticket that links to multiple modules is possible. > Thanks, > -- > Emilien Macchi > > -- > > __ 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] [puppet] Release management and bug triage
Hi, I wanted to start the discussion here about our bug/release management system with Launchpad. 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. 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. * 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. "Having everything in a single project" Pro: * Release management could be simpler * A single view for all the bugs in Puppet modules * Maybe a bad idea, but we can use tags to track puppet modules issues (ie: puppet-openstacklib whould be openstacklib) Con: * The solution does not scale much, it depends again at how we decide to make bug triage and release management; Also, feel free to add more concerns or feedback to this discussion. Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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
