[openstack-dev] [TripleO] tripleo-common bugs, bug tracking and launchpad tags
rbrady at redhat.com
Tue Aug 9 13:08:42 UTC 2016
On Wed, Jul 27, 2016 at 9:06 AM, Dougal Matthews <dougal at redhat.com> wrote:
> On 19 July 2016 at 16:20, Steven Hardy <shardy at 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  and that he'd
>> > been using the TripleO main tracker  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  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:
>> > 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 . 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  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
>> 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
> list for consideration, it has been created but hasn't yet been used as
> 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
> 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.
>> > Julie
>> >  https://bugs.launchpad.net/tripleo-common
>> >  https://bugs.launchpad.net/tripleo
>> >  https://wiki.openstack.org/wiki/TripleO#Bug_Triage
>> >  https://wiki.openstack.org/wiki/Bug_Tags
>> >  https://bugs.launchpad.net/tripleo?field.tag=tripleoclient
>> > ____________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
>> > 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-request at lists.openstack.org?subject:
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
rbrady at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev