<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 July 2016 at 16:20, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jul 18, 2016 at 12:28:10PM +0100, Julie Pichon wrote:<br>
> Hi,<br>
><br>
> On Friday Dougal mentioned on IRC that he hadn't realised there was a<br>
> separate project for tripleo-common bugs on Launchpad [1] and that he'd<br>
> been using the TripleO main tracker [2] instead.<br>
><br>
> Since the TripleO tracker is also used for client bugs (as far as I can<br>
> tell?), and there doesn't seem to be a huge amount of tripleo-common<br>
> bugs perhaps it would make sense to also track those in the main<br>
> tracker? If there is a previous conversation or document about bug<br>
> triaging beyond [3] I apologise for missing it (and would love a<br>
> URL!). At the moment it's a bit confusing.<br>
<br>
</span>Thanks for raising this, yes there is a bit of a proliferation of LP<br>
projects, but FWIW the only one I'm using to track coordinated milestone<br>
releases for Newton is this one:<br>
<br>
<a href="https://launchpad.net/tripleo/" rel="noreferrer" target="_blank">https://launchpad.net/tripleo/</a><br>
<span class=""><br>
> If we do encourage using the same bug tracker for multiple components,<br>
> I think it would be useful to curate a list of official tags [4]. The<br>
> main advantage of doing that is that the tags will auto-complete so<br>
> it'd be easier to keep them consistent (and thus actually useful).<br>
<br>
</span>+1 I'm fine with adding tags, but I would prefer that we stopped adding<br>
more LP projects unless the associated repos aren't planned to be part of<br>
the coordinated release (e.g I don't have to track them ;)<br>
<span class=""><br>
> Personally, I wanted to look through open bugs against<br>
> python-tripleoclient but people use different ways of marking them at<br>
> the moment - e.g. [tripleoclient] or [python-tripleoclient] or<br>
> tripleoclient (or nothing?) in the bug name. I tried my luck at adding<br>
> a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe<br>
> something shorter like 'cli', 'common' would make more sense. If there<br>
> are other tags that come back regularly it'd probably be helpful to<br>
> list them explicitly as well.<br>
<br>
</span>Sure, well I know that many python-*clients do have separate LP projects,<br>
but in the case of TripleO our client is quite highly coupled to the the<br>
other TripleO pieces, in particular tripleo-common.  So my vote is to<br>
create some tags in the main tripleo project and use that to filter bugs as<br>
needed.<br>
<br>
There are two projects we might consider removing, tripleo-common, which<br>
looks pretty much unused and tripleo-validations which was recently added<br>
by the sub-team working on validations.<br></blockquote><div><br></div><div>I agree with retiring these and I'd also like to add tripleo-workflows to the <br>list for consideration, it has been created but hasn't yet been used as far <br>as I can tell.<br><br></div><div>Sorry the the late reply. I'm glad this was brought up, it was on my mental<br>todo list. It should make things clearer internally and also for users less <br>familiar with the project that want to report bugs.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If folks find either useful then they can stay, but it's going to be easier<br>
to get a clear view on when to cut a release if we track everything<br>
considered part of the tripleo deliverable in one place IMHO.<br>
<br>
Thanks,<br>
<br>
Steve<br>
<span class="im HOEnZb"><br>
><br>
> Julie<br>
><br>
> [1] <a href="https://bugs.launchpad.net/tripleo-common" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tripleo-common</a><br>
> [2] <a href="https://bugs.launchpad.net/tripleo" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tripleo</a><br>
> [3] <a href="https://wiki.openstack.org/wiki/TripleO#Bug_Triage" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/TripleO#Bug_Triage</a><br>
> [4] <a href="https://wiki.openstack.org/wiki/Bug_Tags" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Bug_Tags</a><br>
> [5] <a href="https://bugs.launchpad.net/tripleo?field.tag=tripleoclient" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tripleo?field.tag=tripleoclient</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Steve Hardy<br>
Red Hat Engineering, Cloud<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>