<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-text-html" lang="x-unicode">Forgive the top posting.
      <br>
      <br>
      Thank you Jay for your clarification and apology.<br>
      <br>
      I wrote the piece below **before** you sent out your email this
      afternoon, so again this is nothing personal and not targeted at
      any **specific** person.<br>
      <br>
      With that said, I still think that what I have to say is still
      relevant (if I am raked over the coals for it, then so be it), and
      should be voiced here on both of these lists, and is quoted here
      below in full. <br>
      <br>
      ----<br>
      Hello all.<br>
      <br>
      I would like to bring to your attention the following log from
      last nights TC meeting [1] (if you have not already gone through
      it)<br>
      <br>
      Starting at <br>
      20:17:42 <ttx> #topic Discuss differences between Ops and TC
      "tags"<br>
      <br>
      Ending at <br>
      20:27:13 <ttx> #topic Add the Searchlight Project <br
        class="Apple-interchange-newline">
      <br>
      With some highlights<br>
      <br>
      <b>20:19:47 <-----> ---: they are also setting themselves up
        for failure, IMHO, and a situation where the data will be almost
        immediately stale and worse than in the openstack.org wiki. </b><b><br>
      </b> <b>20:21:37 <------> what ops want is not so much tags
        as more targeted analytics data (extension to
        bitergia/stackalytics) by the sounds of it </b><br>
      <b>20:22:45 <-----> I prefer 1/ really, but I'm more than
        happy to let their current strategy fail and then revisit. </b><b><br>
      </b> <b>20:24:42 <------> ------: I have *already* engaged
        with them. and their answer has been "f off, we'll do it our
        way". </b><b><br>
      </b> <b>20:25:46 * -------- looks forward to the
        ops:packaged:centos:call-me-maybe:ok-with-cern-this-week "tag"</b>
      <br>
      <br>
      (in order to not single out any single person from the meeting
      last night I have removed the names from the snippet - the
      originals are in the raw log).<br>
      <br class="Apple-interchange-newline">
      Personally I find some of the comments highly condescending, and
      in some cases blatantly a pure insult. <br>
      It could be that some of it was supposed to be humorous, was said
      in the 'spur of the moment', but I think it is appropriate to
      remind people that all of these things are logged, and available
      for eternity. <br>
      <br class="Apple-interchange-newline">
      If that is the way that certain members of the TC would like treat
      an initiative that was not born purely as a part of the developer
      community, but as part of the other side of the fence then I am
      sorry but this is destined to fail. Before it even starts.<br>
      <br>
      Yes some of the comments are true, there are things to fix, but
      instead of going down the route of "we know better, because we
      know OpenStack and we have been here for 10 cycles already, so let
      us let them stew in their own juice and not help them out", they
      could be more receptive and embrace change and live up to their
      motto of being more inclusive.<br>
      <br>
      If this attitude continues we will find ourselves after another
      cycle or two (or ten), and the community (and the TC) will still
      not have proper input from what they deem to be an 'important'
      factor in the community.<br>
      <br>
      It seems to me that the operations aspect of OpenStack is of no
      interest to them - unless it is done their way and their way only.<br>
      <br>
      To me this is classic case of typical OpenStack - That way is no
      good, I have a better way of doing it. <br>
      <br>
      A large number of bytes were spilled during the TC elections of
      why Operators feel excluded from the OpenStack community. <br>
      <br>
      For me, the interaction in the meeting above, is a perfect example
      of why.<br>
      <br>
      As was voiced already on the mailing list lately [2]<br>
      " Not cool .....! Not even a little bit."<br>
      <br>
      ***Again I would like to stress this is not a personal attack on
      any single member of the TC - but a general feeling *I have* of
      the wrong attitude that is coming across from the people that are
      supposed to be representing and leading the WHOLE OpenStack
      community.***<br>
      <br>
      I would appreciate your thoughts and comments.<br>
      <br>
      [1] <a class="moz-txt-link-freetext"
href="http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-06-09-20.01.log.txt">http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-06-09-20.01.log.txt</a><br>
      [2] <a class="moz-txt-link-freetext"
href="http://lists.openstack.org/pipermail/openstack-dev/2015-June/066031.html">http://lists.openstack.org/pipermail/openstack-dev/2015-June/066031.html</a><br>
      <div class="moz-signature">-- <br>
        <br>
      </div>
    </div>
    <div class="moz-cite-prefix">On 06/10/15 20:51, Jay Pipes wrote:<br>
    </div>
    <blockquote cite="mid:55787917.5080400@gmail.com" type="cite">Cross-posting
      to -operators and -dev because this involves *packagers* of
      OpenStack, as well as operators who use those packages.
      <br>
      <br>
      Hello Operators,
      <br>
      <br>
      First, let me start out by saying if you were offended by my
      snarky comments at yesterday's TC meeting [1] regarding the
      direction of the Ops Tags Team, I apologize. Sometimes I am snarky
      and/or moody, especially when I feel strongly about something, as
      is the case here. Please accept my apologies. Let's move on.
      <br>
      <br>
      = tl;dr =
      <br>
      <br>
      * The proposed things are not tags
      <br>
      * Operators should not be curating packaging tags (packagers
      should)
      <br>
      * Tags should not have a "value" component
      <br>
      * Packaging tags should be release-specific, or they will be wrong
      <br>
      <br>
      = The details =
      <br>
      <br>
      OK, that said, here are the issues I have with the proposed
      ops:packaging tags [2].
      <br>
      <br>
      = The proposed things are not "tags" =
      <br>
      <br>
      The things being proposed by the Ops Tags Team are in fact not
      "tags", which are simple strings of binary information that have a
      well-defined and singular meaning.
      <br>
      <br>
      What the Ops Tags Team has proposed is structured, schema-full
      data objects. There is nothing wrong with having a structured
      object for purposes of generating useful information. But please
      don't call these things "tags", because they aren't.
      <br>
      <br>
      Before I move on to other issues, I'd like to point out that the
      more you go down the route of adding more and more attributes,
      most of which would be optional, to these structured documents,
      the more you will run into a problem of having stale and
      misleading data contained in these JSON files. And that will lead
      to a worse user experience for operators than the current wiki,
      which, like all wikis, is notoriously out-of-date in many places.
      <br>
      <br>
      A tag should mean one thing, and one thing only, to encourage
      clarity. The definition of the tag should be decisive regarding
      why a particular project has been tagged with that tag.
      <br>
      <br>
      = Operators should not be curating packaging tags =
      <br>
      <br>
      *Packagers* should be curating tags that correspond to whether or
      not packages exist for particular projects in OpenStack. Operators
      consume these packages, for sure, but the packagers in the
      upstream operating system communities are the ones that know the
      most accurate information about the state of packaging for a
      particular project and a particular release.
      <br>
      <br>
      I strongly believe that these ops:packaged tags should really just
      be tags in the openstack/governance repository (i.e. regular TC
      tags) and be curated by the packaging community, which means they
      would not have the "ops:" prefix on them.
      <br>
      <br>
      = Remove "value" component from the "tag" =
      <br>
      <br>
      The current proposal for both ops:packaged and ops:production-use
      [3] tag definitions include a "value" component. For example, the
      ops:packaged tags must include one of the following "values":
      <br>
      <br>
       - good
      <br>
       - beginning
      <br>
       - warning
      <br>
       - no
      <br>
      <br>
      With each of the above values attempting to indicate to the
      audience that the packages for a particular project are in varying
      states of repair and "bug-freeness". There are a number of
      problems with including this "value" in the tag:
      <br>
      <br>
      1) This value judgement about the packaging quality is ripe for
      getting out-of-date VERY quickly. Who is going to continually
      update the value parts for the different projects? Things change
      very quickly in packaging-land. Bugs are fixed, new packages built
      and published. Who in the ops community is going to track this?
      Please see point above about "Operators should not be curating
      packaging tags".
      <br>
      <br>
      2) All software, including packages, has bugs. This is something
      that the Ops community just needs to accept and get over.
      Quabbling with each other about what constitutes a "major" bug in
      packaging and how many "major" bugs bugs constitute a "warning"
      value is less than useful to the audience here. Instead, the ops
      community should focus on providing useful documentation and links
      to the audience, in the form of long-form release notes or
      opinions about packages and documentation on the OpenStack wiki.
      <br>
      <br>
      = Packaging tags should be release-specific, or they will be wrong
      =
      <br>
      <br>
      For these packaging tags, the release must be part of the tag
      itself, otherwise the information it denotes would be
      indeterminate.
      <br>
      <br>
      As an example, suppose you have a tag that looks like this:
      <br>
      <br>
       ops:packaged:centos:good
      <br>
      <br>
      And in the tag definition you say that the tag is applied to
      projects that have CentOS RPM packages available "within the last
      6 months". Well, as you all know, packages are published for a
      *particular release of OpenStack*. So, if Nova is tagged with
      ops:packaged:centos:good in, say, August 2015, the tag would
      ostensibly be saying that packages exist for Nova in Kilo.
      However, once November rolls around, and packages for Liberty
      don't (yet) exist, are you going to remove this
      "ops:packaged:centos:good" tag from Nova or (worse) change it to
      "ops:pacakged:centos:no"?
      <br>
      <br>
      Instead, have the tag be specific to a release of OpenStack:
      <br>
      <br>
      packaged:centos:kilo
      <br>
      <br>
      = In summary =
      <br>
      <br>
      In short, I would love it if the Ops Tags team would stick with
      binary tag definitions -- a tag should mean one thing and one
      thing only.
      <br>
      <br>
      I don't believe the Ops Tags team should be curating the packaging
      tags -- the packaging community should do that, and do that under
      the main openstack/governance repository.
      <br>
      <br>
      Packagers, I would love it if you would curate a set of tags that
      looks kind of like this:
      <br>
      <br>
       - packaged:centos:kilo
      <br>
       - packaged:ubuntu:liberty
      <br>
       - packaged:sles:juno
      <br>
      <br>
      I will be proposing the above tag definition to the
      openstack/governance repository this week.
      <br>
      <br>
      Thanks for listening,
      <br>
      -jay
      <br>
      <br>
      [1]
<a class="moz-txt-link-freetext" href="http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2015-06-09.log.html#t2015-06-09T20:18:00">http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2015-06-09.log.html#t2015-06-09T20:18:00</a><br>
      [2] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/186633">https://review.openstack.org/#/c/186633</a>
      <br>
      [3] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/189168">https://review.openstack.org/#/c/189168</a>
      <br>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      Maish Saidel-Keesing</div>
  </body>
</html>