Open Stack

On Tue, Aug 16, 2016 at 10:40 AM, Julie Pichon <jpichon 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 [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.

I think you can go ahead and update the spec. People will vote in
Gerrit, but I'm pretty confident it's fine for everyone.

Thanks!

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi