Open Stack

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160727/bb9f996f/attachment.html>