On 06/02/2015 10:29 AM, Tom Fifield wrote:
On 02/06/15 22:18, Jay Pipes wrote:
On 06/01/2015 04:07 AM, Tom Fifield wrote:
Hi all,
Thank you very much for officially kicking off the Ops Tags Team at the
Vancouver summit!
Based on our discussions, I've made a bit of progress. We now have a
* wiki page: https://wiki.openstack.org/wiki/Operations/Tags
* repository: https://github.com/stackforge/ops-tags-team
... and ... a first attempt at writing up those tags we discussed at the
meeting:
* Ops:docs:install-guide: https://review.openstack.org/#/c/186638/
* Ops:Packaged: https://review.openstack.org/#/c/186633/
Please jump on the code review system and add your comments!
Hi Tom,
I have some serious concerns about how the OpsTags team is defining what
a tag is.
From the wiki page above, you write:
When applied to a project, Tags are comprised of a name (eg
"Ops:Deployment-Widespread", "Ops:Config-Recipes-Available",
"Ops:Packaged"), a value (eg "92%", "yes", "Ubuntu, Redhat and SUSE")
and if applicable a description of why the project has that value.
This isn't at all what tags are supposed to be. Tags are not intended to
contain a "value", nor should a tag contain "a description of why the
project has that value".
Tags are simple strings.
They do not have a schema to them. They do not have a value part. They
do not have any caveats or exceptions.
To use an example of a tag that already exists... let's take the
team:diverse-affiliation tag [1]. This tag's definition tells the
audience that the project's contributor team has a certain level of
diversity to it -- in review and commit % over the last release cycle.
The tag itself does not indicate the % of reviews or commits from the
highest contributor -- in other words, the tag doesn't look like this:
team:diverse-affiliation:42%
That's encoding a value in a tag and that's not what tags are about. Tag
definitions inform the reader that if a tag is applied to a project,
then that project meets the conditions laid out in the tag definition.
That's it. Nothing more, nothing less.
Let's please try to keep the Ops Tags bound to the same definition of a
tag. Do not have a value portion of a tag. The tag definition file
should clearly explain what conditions were met if a project has that
tag applied to it. No caveats or exceptions needed.
Hi Jay,
Thanks for sharing your concerns.
I think providing information to operators is the aim and the way the
ops tags team has agreed to do this is reasonable in achieving it. I'm
not worried if the ops tags end up looking quite a bit different to the
ones under TC governance provided we meet this aim.
Please, no. We should not have ops tags that are different than other
tags for no good reason.
It might help to look at some of the examples being discussed in the
code review system or on the etherpad to get an idea of the kind of
stuff the team's looking into. The text on the wiki was put together in
rather a hurry and will be evolving as we work stuff out.
Sure, I plan on reviewing all of them.
Best,
-jay
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
