On 5.4.2018 21:04, Alex Schultz wrote:
On Thu, Apr 5, 2018 at 12:55 PM, Wesley Hayutin <whayu...@redhat.com> wrote:
FYI...
This is news to me so thanks to Emilien for pointing it out [1].
There are official tags for tripleo launchpad bugs. Personally, I like what
I've seen recently with some extra tags as they could be helpful in finding
the history of particular issues.
So hypothetically would it be "wrong" to create an official tag for each
featureset config number upstream. I ask because that is adding a lot of
tags but also serves as a good test case for what is good/bad use of tags.
We list official tags over in the specs repo[0]. That being said as
we investigate switching over to storyboard, we'll probably want to
revisit tags as they will have to be used more to replace some of the
functionality we had with launchpad (e.g. milestones). You could
always add the tags without being an official tag. I'm not sure I
would really want all the featuresets as tags. I'd rather see us
actually figure out what component is actually failing than relying on
a featureset (and the Rosetta stone for decoding featuresets to
functionality[1]).
We could also use both alongside. Component-based tags better relate to
the actual root cause of the bug, while featureset-based tags are useful
in relation to CI.
E.g. "I see fs037 failing, i wonder if anyone already reported a bug for
it" -- if the reporter tagged the bug, it would be really easy to figure
out the answer.
This might also again bring up the question of better job names to allow
easier mapping to featuresets. IMO:
tripleo-ci-centos-7-containers-multinode -- not great
tripleo-ci-centos-7-featureset010 -- not great
tripleo-ci-centos-7-containers-mn-fs010 -- *happy face*
Jirka
Thanks,
-Alex
[0]
http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/policy/bug-tagging.rst#n30
[1]
https://git.openstack.org/cgit/openstack/tripleo-quickstart/tree/doc/source/feature-configuration.rst#n21
Thanks
[1] https://bugs.launchpad.net/tripleo/+manage-official-tags
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
