Forgive the top posting.
Thank you Jay for your clarification and apology.
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.
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.
----
Hello all.
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)
Starting at
20:17:42 <ttx> #topic Discuss differences between Ops and TC "tags"
Ending at
20:27:13 <ttx> #topic Add the Searchlight Project
With some highlights
*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. **
* *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 *
*20:22:45 <-----> I prefer 1/ really, but I'm more than happy to let
their current strategy fail and then revisit. **
* *20:24:42 <------> ------: I have *already* engaged with them. and
their answer has been "f off, we'll do it our way". **
* *20:25:46 * -------- looks forward to the
ops:packaged:centos:call-me-maybe:ok-with-cern-this-week "tag"*
(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).
Personally I find some of the comments highly condescending, and in some
cases blatantly a pure insult.
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.
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.
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.
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.
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.
To me this is classic case of typical OpenStack - That way is no good, I
have a better way of doing it.
A large number of bytes were spilled during the TC elections of why
Operators feel excluded from the OpenStack community.
For me, the interaction in the meeting above, is a perfect example of why.
As was voiced already on the mailing list lately [2]
" Not cool .....! Not even a little bit."
***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.***
I would appreciate your thoughts and comments.
[1]
http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-06-09-20.01.log.txt
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066031.html
--
On 06/10/15 20:51, Jay Pipes wrote:
Cross-posting to -operators and -dev because this involves *packagers*
of OpenStack, as well as operators who use those packages.
Hello Operators,
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.
= tl;dr =
* The proposed things are not tags
* Operators should not be curating packaging tags (packagers should)
* Tags should not have a "value" component
* Packaging tags should be release-specific, or they will be wrong
= The details =
OK, that said, here are the issues I have with the proposed
ops:packaging tags [2].
= The proposed things are not "tags" =
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.
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.
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.
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.
= Operators should not be curating packaging tags =
*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.
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.
= Remove "value" component from the "tag" =
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":
- good
- beginning
- warning
- no
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:
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".
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.
= Packaging tags should be release-specific, or they will be wrong =
For these packaging tags, the release must be part of the tag itself,
otherwise the information it denotes would be indeterminate.
As an example, suppose you have a tag that looks like this:
ops:packaged:centos:good
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"?
Instead, have the tag be specific to a release of OpenStack:
packaged:centos:kilo
= In summary =
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.
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.
Packagers, I would love it if you would curate a set of tags that
looks kind of like this:
- packaged:centos:kilo
- packaged:ubuntu:liberty
- packaged:sles:juno
I will be proposing the above tag definition to the
openstack/governance repository this week.
Thanks for listening,
-jay
[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2015-06-09.log.html#t2015-06-09T20:18:00
[2] https://review.openstack.org/#/c/186633
[3] https://review.openstack.org/#/c/189168
--
Maish Saidel-Keesing
__________________________________________________________________________
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