On Tue, Jul 19, 2016 at 5:20 PM, Steven Hardy <sha...@redhat.com> wrote: > On Mon, Jul 18, 2016 at 12:28:10PM +0100, Julie Pichon wrote: >> Hi, >> >> On Friday Dougal mentioned on IRC that he hadn't realised there was a >> separate project for tripleo-common bugs on Launchpad [1] and that he'd >> been using the TripleO main tracker [2] instead. >> >> Since the TripleO tracker is also used for client bugs (as far as I can >> tell?), and there doesn't seem to be a huge amount of tripleo-common >> bugs perhaps it would make sense to also track those in the main >> tracker? If there is a previous conversation or document about bug >> triaging beyond [3] I apologise for missing it (and would love a >> URL!). At the moment it's a bit confusing. > > Thanks for raising this, yes there is a bit of a proliferation of LP > projects, but FWIW the only one I'm using to track coordinated milestone > releases for Newton is this one: > > https://launchpad.net/tripleo/ > >> If we do encourage using the same bug tracker for multiple components, >> I think it would be useful to curate a list of official tags [4]. The >> main advantage of doing that is that the tags will auto-complete so >> it'd be easier to keep them consistent (and thus actually useful). > > +1 I'm fine with adding tags, but I would prefer that we stopped adding > more LP projects unless the associated repos aren't planned to be part of > the coordinated release (e.g I don't have to track them ;) > >> Personally, I wanted to look through open bugs against >> python-tripleoclient but people use different ways of marking them at >> the moment - e.g. [tripleoclient] or [python-tripleoclient] or >> tripleoclient (or nothing?) in the bug name. I tried my luck at adding >> a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe >> something shorter like 'cli', 'common' would make more sense. If there >> are other tags that come back regularly it'd probably be helpful to >> list them explicitly as well. > > Sure, well I know that many python-*clients do have separate LP projects, > but in the case of TripleO our client is quite highly coupled to the the > other TripleO pieces, in particular tripleo-common. So my vote is to > create some tags in the main tripleo project and use that to filter bugs as > needed. > > There are two projects we might consider removing, tripleo-common, which > looks pretty much unused and tripleo-validations which was recently added > by the sub-team working on validations. > > If folks find either useful then they can stay, but it's going to be easier > to get a clear view on when to cut a release if we track everything > considered part of the tripleo deliverable in one place IMHO.
The tripleo-validations issues on launchpad now live in the tripleo bug tracker with the 'validations' tag. I'm going to retire the tripleo-validation launchpad once I find how to do it. Here's the relevant tripleo-validations patch: https://review.openstack.org/347706 Thanks, Martin > Thanks, > > Steve > >> >> Julie >> >> [1] https://bugs.launchpad.net/tripleo-common >> [2] https://bugs.launchpad.net/tripleo >> [3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage >> [4] https://wiki.openstack.org/wiki/Bug_Tags >> [5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient >> >> __________________________________________________________________________ >> 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 > > -- > Steve Hardy > Red Hat Engineering, Cloud > > __________________________________________________________________________ > 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