On Wed, Jul 27, 2016 at 9:06 AM, Dougal Matthews <dou...@redhat.com> wrote:
> > > On 19 July 2016 at 16:20, 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. >> > > I agree with retiring these and I'd also like to add tripleo-workflows to > the > list for consideration, it has been created but hasn't yet been used as > far > as I can tell. > Shortly after I started creating this, you were very vocal about being -1 to this and so we did not use it. I haven't had time to delete it yet, but it's on my task list after the N-3 items. > > Sorry the the late reply. I'm glad this was brought up, it was on my mental > todo list. It should make things clearer internally and also for users > less > familiar with the project that want to report bugs. > > > 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. >> >> 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 > > -- Ryan Brady Cloud Engineering rbr...@redhat.com 919.890.8925
__________________________________________________________________________ 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
