[openstack-dev] [TripleO] tripleo-common bugs, bug tracking and launchpad tags

Julie Pichon jpichon at redhat.com
Tue Aug 16 14:40:46 UTC 2016


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 [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.

Following up on this and related conversations (e.g. on today's TripleO
meeting), the tripleo-ui team would like to migrate to the main TripleO
tracker as well. It totally makes sense to me, seeing as the UI is just
as dependent on the other TripleO projects. It's a new language but we
already have multiple code bases so what's one more :-) That way the UI
can be more integrated with TripleO during the cycle and related issues
and features will show up during the weekly meeting.

I think there's some Launchpad magic we can use to migrate the bugs,
but I'm not sure if it's possible to move the blueprints themselves. To
avoid distractions when we're so close to Feature Freeze, in my opinion
it might be better to migrate the blueprints after Newton-3 anyway.

If there's no objections, I'll add the 'ui' tag to the bug tagging
policy at [1]. We can start filing new bugs into the TripleO
tracker [2], and blueprint authors can move their outstanding blueprints
when they have a chance.

Thanks,

Julie

[1] https://review.openstack.org/#/c/352852/
[2] https://bugs.launchpad.net/tripleo

> 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



More information about the OpenStack-dev mailing list