Open Stack

Thierry,

People will starting calling "tc this" and "uc that" only if we present two
sets of data. I think the right question to ask is why not present one
unified set, which was my original understanding when I read your proposal
last year.

Subbu

On Mon, Jun 29, 2015 at 1:14 AM, Thierry Carrez <thierry at openstack.org>
wrote:

> Subbu Allamaraju wrote:
> > Pardon me for being blunt, but I’m still confused why cycles are being
> spent on semantic wrangling. As you rightly point out, the term is
> subjective, and that’s the point.
> >
> > Is there a fear a single set of tags that include both dev and
> operational aspects confuse consumers of OpenStack? Please clarify.
>
> No, the fear is that if we provide two types of data (a binary and a
> dictionary) and call both of them "tags", then people will start calling
> them "TC tags" (the binary things) and "Ops tags" (the dictionary
> things), and that confusion will follow.
>
> Confusion will be even deeper once the TC starts to define "TC tags"
> based on data from "Ops tags". At that point "tag" won't mean anything
> anymore.
>
> Let me reverse the question: Pardon me for being blunt, but I'm still
> confused why you insist on calling "tags" data that cannot be
> represented as a label and therefore doesn't meet the general usage of
> the "tag" word in our industry ? Why not use another word (data,
> information, dictionary, documentation...) ?
>
> I totally get that you want to define operational information under your
> own terms and don't want to limit yourself to the framework the TC
> proposed. I just don't get why you want to reuse the exact same word for
> it.
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150629/a12dfb1d/attachment.html>