Open Stack

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 [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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ryan Brady
Cloud Engineering
rbrady at redhat.com
919.890.8925
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160809/9c1dec28/attachment.html>