14:03:32 <fifieldt> #startmeeting ops-tags
14:03:33 <openstack> Meeting started Thu Jun 18 14:03:32 2015 UTC and is due to finish in 60 minutes.  The chair is fifieldt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:37 <openstack> The meeting name has been set to 'ops_tags'
14:03:46 <fifieldt> How is everyone?
14:04:19 * maishsk is in sunny Jerusalem - how bad can it be? :)
14:04:25 <fifieldt> perfect, perfect :)
14:04:39 <fifieldt> so, kicking off:
14:04:40 <fifieldt> #topic announcements
14:04:46 <fifieldt> Hello Ops Tags Team! It's great to see you again.
14:04:47 <fifieldt> We've made some good progress since our last meeting.
14:04:49 <fifieldt> In case you're fresh in, here are the highlights:
14:04:52 <fifieldt> #info We're now on the wiki at https://wiki.openstack.org/wiki/Operations/Tags
14:04:55 <ttx> fifieldt: is there an agenda somewhere ?
14:04:56 <fifieldt> #info  and have a repository at: https://github.com/stackforge/ops-tags-team
14:04:59 <fifieldt> #info  There are 4 patches under review: https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z
14:05:02 <fifieldt> #info  We've agreed to use the ops ML with [tags] in the subject line to communicate
14:05:08 <fifieldt> #info  We've agreed to use IRC for our monthly meeting. You can see interesting IRC meeting commands here: http://meetbot.debian.net/Manual.html#user-reference
14:05:13 <fifieldt> On meetings, it looks like we have a fairly full agenda today:
14:05:14 <fifieldt> #link https://etherpad.openstack.org/p/ops-tags-June-2015
14:05:23 <fifieldt> and I think there's a chance we may not get through all of it. We have a hard stop in an hour, when the Ceilometer team arrives, so if we don't, we might meet again within a couple of weeks.
14:05:32 <fifieldt> Though, let's keep discussion of mundane matters like meeting time toward the end, as they can in theory be done on the mailing list, too :)
14:06:00 <fifieldt> Is everyone comfortable with those announcements and the agenda?
14:06:21 <jaypipes> sure
14:06:28 <jproulx> yup
14:06:39 <fifieldt> Brilliant
14:06:49 <fifieldt> With that, on to our first content topic:
14:06:55 <fifieldt> #topic Binary -vs- StructuredData tags
14:07:00 <fifieldt> We have the ability to offer rich, easily maintainable data about projects - and our mission is indeed "allowing users to make better decisions by providing useful information about OpenStack software projects."
14:07:07 <fifieldt> Based on prior discussions with the UC, our team-forming discussions at the summit, and best efforts subsequently, we've come up with some initial tags for review. These turned out to be a little different to what the Technical Committee (TC) is doing, but we do have scope for that, being an activity not under TC governance. Having said that, it is nice to see the level of interest from TC members, and particularly the open
14:07:07 <fifieldt> minded approach the majority appear to take - genuinely curious to see what we can come up with :)
14:07:08 <maishsk> the only thing is that the frequency of the IRC meeting cannot be monthly - so I have currently scheduled a meeting every two weeks.
14:07:20 <jaypipes> a little different? :)
14:07:20 <fifieldt> One valid point is that we do need to keep an eye on the complexity of the structure to ensure the ease of eventual display on the web (we don't want to have to update a website layout every time we update a tag), but this doesn't directly equate to a need for binary tags.
14:07:26 <fifieldt> Initial impressions are that trying to fit something like ops:packaged or ops:production-use into a binary label removes useful information, or decreases maintainability if we want to try and retain all of the information.
14:07:27 <maishsk> jaypipes: :)
14:07:33 <fifieldt> So, personally, after working through our initial tags under review, I just don't see the value in us moving to a binary-based system. Therefore, I would be interested to hear from those that do what the value proposition is. Who would like to kick us off?
14:07:48 <jaypipes> I can.
14:07:59 <fifieldt> floor is yours :)
14:08:02 <ttx> So... my take on that is that it's different type of data -- useful, but different from the tags framework.
14:08:19 <ttx> so I think we should use another name for it
14:08:25 <jaypipes> The value of a simple string tag is that a tag means one thing and one thing only. The defintion file of the tag lists the requirements for a project to be tagged with that string.
14:08:27 <ttx> to avoid confusion between the two frameworks
14:08:54 <fifieldt> and how does that apply to our mission, jaypipes?
14:08:58 <jaypipes> ttx: agreed completely. I don't think structured data is not useful, it'sjust that it isn't tags.
14:09:00 <ttx> I don't really mind the new name -- ops-data ops-feedback-on-project operational-info... just not "tag"
14:09:22 <ttx> because that dilutes the concept and makes things confusing
14:09:37 <fifieldt> ttx, this may be the case - and I'll take that up with the user committee, but I don't think naming is  something that we can solve in this meeting today.  I think it would take up a lot of time when we have other items on the agenda.
14:09:38 <jaypipes> fifieldt: the mission is to provide *accurate*, *useful* information in a consumable way, to the audience of operators.
14:09:54 <fifieldt> and how is the current system not consumable?
14:09:55 <lsell> so who would be consuming or looking at tags vs ops data? would they be two different types of people?
14:10:19 <jaypipes> fifieldt: anything that inhibits the accuracy (via the impossibiliy of tracking some non-objective or constantly-changing data) is antithetical to that mission.
14:10:33 <fifieldt> for example?
14:10:44 <maishsk> ttx: were tags ever defined as being a single simple string?
14:10:45 <jaypipes> fifieldt: see my email about the ops:packaged "tags".
14:10:45 <fifieldt> perhaps using one of the under review tags as ane xample
14:10:46 <ttx> lsell: both could be made available. Or we could build tags on top of ops-data
14:11:02 <fifieldt> jaypipes, for the benefit of those in the meeting, perhaps you could pull an example from that email
14:11:03 <ttx> maishsk: a "tag" is a label.
14:11:11 <ttx> not a dictionary.
14:11:12 <jproulx> Do we expect humans to look directly at either type of data or do we expect to provide some query or search interface?  I think the latter mostly
14:11:21 <fifieldt> latter, for sure
14:11:23 <maishsk> ttx: and a label can have many things on it.
14:11:40 <maishsk> jproulx: agree
14:11:42 <lsell> i understand that both could be made available, but i'm trying to understand how we would explain the difference to people. we're trying to better communicate around the projects, and i don't want this to end up being more confusing
14:11:43 <jaypipes> fifieldt: the information in the proposed schema would a) be inaccurate in short time windows, b) isn't determined by the people doing packaging (the packagers...), and introduces a value part of the tag that doesn't correspond to something that can be easily tracked in an objective way.
14:12:03 <fifieldt> jaypipes, I see you are talking about ops:packaged
14:12:07 <jaypipes> yes.
14:12:11 <fifieldt> how would it be innacurate in short time windows?
14:12:40 <jproulx> qualitative judgements are required by operators (will this work not does this exisist) and the people making a thing (doc or packages) are diased
14:12:45 <ttx> maishsk: sure, but then it hardly qualifies as a simple label.
14:13:01 <jaypipes> fifieldt: from my email: http://paste.openstack.org/show/301705/
14:13:16 <jproulx> s/diased/biased/;
14:13:37 <fifieldt> jaypipes, you appear to misunderstand ops:packaged
14:13:44 <fifieldt> I suggest you take a look at the review
14:13:46 <ttx> I'm fine with the ops group providing structured operational information about projects -- it's just not fitting in the "tag" framework we defined, so we'd prefer if you used your own name for your framework
14:13:55 <jaypipes> fifieldt: I've reviewed it three times already.
14:13:59 <ttx> for the sake of avoiding confusion to the rest of our community
14:13:59 <maishsk> ttx: trying to make this as simple as I can for myself, take a simple label I would put on my kids school books.
14:14:05 <fifieldt> yet somehow you use " ops:packaged:centos:good" as an example :)
14:14:10 <fifieldt> which isn't something that would occur
14:14:33 <maishsk> It would have - name: + Class: + phone_number:
14:14:57 <maishsk> all three of those would be useful for me to find information about the owner of the book
14:15:22 <fifieldt> jaypipes, you appear to also misunderstand how ops tags deal with releases
14:15:54 <jaypipes> fifieldt: please enlighten me, Tom.
14:16:10 <fifieldt> https://review.openstack.org/#/c/186633/4/descriptions/ops-packaged.rst
14:16:20 <jaypipes> I've read it.
14:16:21 <fifieldt> perhaps have a read of the "tag updates and timing" section
14:16:31 <fifieldt> you may not have read that bit yet
14:16:33 <fifieldt> since it's new this week
14:16:35 <jaypipes> I sis.
14:16:37 <jaypipes> did.
14:16:54 <fifieldt> you also note something about "centos" in your paste
14:17:01 <fifieldt> yet, that appears to be non-present in the tag?
14:17:07 <fifieldt> having removed pkgtype
14:17:33 <jaypipes> fifieldt: so what does the tag tell the audience about its availability in say, CentOS?
14:17:40 <fifieldt> it doesn't
14:17:46 <jaypipes> then what use is it?
14:18:33 <fifieldt> to you, probably nothing :)
14:18:35 <fifieldt> anyway
14:18:42 <fifieldt> to get back to the question at hand
14:18:49 <fifieldt> what is the value proposition for binary tags?
14:18:56 <fifieldt> so far I haven't seen that answered
14:18:58 <jaypipes> fifieldt: seriously, man, I'm asking a legitimate question.
14:19:07 <maishsk> jaypipes: I think it will depend on how that information is mined and presented
14:19:13 <fifieldt> jaypipes, see rationale in the tag :)
14:19:22 <jaypipes> this is backwards.
14:19:26 <fifieldt> not at all
14:19:32 <jproulx> for me it is part of 'breadth of support'
14:19:34 <maishsk> jaypipes: mind explaining why?
14:19:48 <jproulx> If I want to know if it's packaged for me then I'd 'apt-cache search'
14:19:55 <jaypipes> maishsk: because ops don't use "packages". they use packages of a particular OS distribution.
14:20:13 <fifieldt> and when we do - as jproulx notes - we run apt-cache search
14:20:23 <ttx> fifieldt: binary tags are simpler to display, browse, compare. On the TC side, we don't need to provide more structured data.
14:20:24 <fifieldt> we don't need somewhere else to be the exhaustive list of every single package in every distro version
14:20:29 <jaypipes> if the tag doesn't indicate something for their particular distribution of choice, they won't get any use from the tag.
14:20:36 <fifieldt> what is useful is the general assessment
14:20:39 <ttx> fifieldt: Note, I'm not asking that you use binary tags
14:20:44 <jproulx> but if only my disto and version is packaging it then support is thin in some ways
14:20:46 <fifieldt> appreciated, ttx :)
14:20:50 <jaypipes> fifieldt: that is less than uyseful. that's my point.
14:20:55 <ttx> just that we avoid calling them with the same name :)
14:20:57 <fifieldt> not at all
14:21:03 <fifieldt> if 2/3 distros are doing a crap job with packaging, that's good to know
14:21:11 <fifieldt> since even if the package exists in the repo
14:21:17 <jaypipes> jproulx: if I deploy CEntos, I don't give a hoot about Ubuntu packages being available or "good".
14:21:22 <fifieldt> I can find out that gee, maybe there's some larger issue here
14:21:38 <jaypipes> fifieldt: it is not good to know. it's irrelevant to the person not using those distos.
14:21:52 <fifieldt> but you do care about major bugs in centos, jaypipes
14:21:55 <fifieldt> and this tag has that
14:22:06 <fifieldt> it absolutely is good to know jaypipes
14:22:39 <jaypipes> fifieldt: in what way does this tag tell me (not the tag information, but the *tag itself*) anything about the state of CentOS packaging for Nova in Kilo?
14:23:09 <fifieldt> "overall"-level crap packaging tends to be related, so a general assessment is fine for this. For specific-badness - this tag does provide that in terms of the caveats
14:23:25 <fifieldt> we get good results with minimal effort in terms of maintenance
14:23:42 <jproulx> jaypipes I deploy Ubuntu but I do care if packages are available for RHEL or Centos or Debian, it in formsme how locked in I am to that distro and if there are other distros that may better fit my needs which are two important pieces of information
14:23:43 <maishsk> Mind if I raise a strange question - do we have operators have any specific reason to call these ‘tags’
14:23:45 <jaypipes> fifieldt: I don't want to go read the caveats for every tag in every project in opeNStack. If I did, I'd just read the release notes.
14:24:00 <maishsk> and not something else?
14:24:12 <fifieldt> jaypipes, this gets into display :)
14:24:27 <jaypipes> jproulx: sorry, but I've never ever met an operator that cared about the state of packaging other than their particular preference.
14:24:41 <jbryce> jproulx: that matches up to what i’ve seen where quite a few operators switch distros at least once in their openstack journey
14:24:51 <maishsk> would it matter if they were called ops-tags instead of tags - I mean seriously - what is the difference?
14:24:51 <fifieldt> +1
14:24:55 <jproulx> perhaps my world is atypically complex, can't answer that but it's my case
14:25:04 <jaypipes> jbryce: name one.
14:25:09 <jbryce> jpl
14:25:11 <jbryce> wells fargo
14:25:14 <jbryce> b of a
14:25:19 <jbryce> disney
14:25:21 <fifieldt> NCI
14:25:27 <jbryce> almost every user we’ve put up for a keynote
14:25:30 <jbryce> bmw
14:25:35 <jaypipes> changed from RPM to DEB?
14:25:36 <fifieldt> MediaTek
14:25:39 <jaypipes> or DEB to RPM?
14:25:40 <lsell> maishk: i don't think the naming is honestly that important, i think what's important is if the data produced by tc and uc will be displayed together, basically two groups contributing information to a single program, or if they will just be separate programs
14:25:44 <fifieldt> I've seen both jaypipes
14:25:50 <ttx> maishsk: good question, thx
14:25:53 <lsell> and where each would live, and how we would explain why you would look at one or the other
14:26:04 <jbryce> changed from ubuntu to red hat to mirantis to metacloud or various other directions
14:26:06 <jaypipes> never seen it and never seen it asked for (and 80% of the companies you linked above are Mirantis customers.)
14:26:26 <maishsk> lsell - do you think they are a single program at the moment (I am finding it difficult to see it that way)
14:26:39 <ttx> maishsk: :)
14:26:44 <jaypipes> in any case, having binary tag information would inform this magical user that likes to change distros.
14:26:52 <lsell> that was my original understanding, we would have a tags program and have different groups in the community contribute information based on their expertise/experience
14:27:06 <lsell> but it's sounding more and more like two separate programs, which is disappointing
14:27:08 <jbryce> jaypipes: it seems you’re either calling us all liars or being really stubborn....
14:27:31 <ttx> lsell: there are only 3 solutions
14:27:32 <maishsk> lsell: so if that was the case - then the tags should be accomodating to all - not just one program.
14:27:39 <jaypipes> jbryce: it seems the ops tags team is being really stubborn to me, not wanting to follow the TC's lead and definitino of a tag just in order to be different.
14:27:50 <fifieldt> not at all jaypipes
14:27:55 <fifieldt> we basically came up with this from first principl;es
14:28:03 <fifieldt> and genuinely think it's a good solution
14:28:20 <jaypipes> just call it "not tags" then.
14:28:21 <ttx> lsell: the trick is the ops usage of the tag framework is substantially different fom the TC one. So one has to converge with the other, or the two must co-exist separately
14:28:24 <maishsk> jaypipes: unfortunately the UC does not fall under the TC - that is something that I think should be clear
14:28:32 <jbryce> this has been the idea that i’ve heard at the ops meetups since paris. at that point, some on the TC were still arguing to not have any kind of tagging at all
14:28:36 <jaypipes> maishsk: this isnt' the UC.
14:28:51 <lsell> ttx: yes, i completely understand / agree
14:29:14 <jaypipes> jbryce: http://www.joinfu.com/2014/09/so-what-is-the-core-of-openstack/ <--- LONG before Paris.
14:29:21 <jproulx> they way then
14:29:30 <maishsk> jaypipes: the Ops-tags is a UC initiative (AFAIK)
14:29:41 <jaypipes> maishsk: since when?
14:29:46 <fifieldt> from beginning
14:30:02 <fifieldt> this is why there is a bit more freedom to investigate the best solution
14:30:13 <maishsk> fifieldt: +1
14:30:23 <jproulx> the way they would need to coexist is is at the presentation layer, at that level different structures would be a technical issue,
14:30:29 <ttx> both groups are pretty happy with what they came up with apparently, but that's different types of info
14:30:31 <jaypipes> OK, I'll just drop out of the ops tags team then and focus on tagging in the openstack/governance repo.
14:30:39 <jaypipes> Feel free to remove me.
14:30:48 <fifieldt> jaypipes, you have had some good insights :)
14:31:04 <fifieldt> dropping pkgtype was inspired by you!
14:31:21 <fifieldt> it was a timely reminder about simplicity
14:31:35 <fifieldt> we're not ignoring you at all - just seeking the best solution
14:31:50 <fifieldt> which is why my question is about why binary things are the best solution
14:32:17 <fifieldt> so far we've talked at length
14:32:18 <ttx> fifieldt: write-once website to display them, whatever tag we come up with in the future ?
14:32:27 <fifieldt> I have some ideas here ttx
14:32:39 <fifieldt> hoping to get someone with a design brain to run through them soon :)
14:32:49 <ttx> I know, but they involve custom code for every ops-data type of info
14:32:53 <jaypipes> because they are the solution that the TC has adopted and unless there's a compelling reason not to follow the lead, you should. I've expressed a number of failures that are possible with the structured data strategy. I don't think I've been unclear about it.
14:33:06 <jaypipes> either that, or don't call them tags.
14:33:25 <fifieldt> I believe we did follow quite a bit of the TCs lead
14:33:42 <ttx> Also I think tags convey more actionable pieces of info.
14:34:04 <ttx> i.e. we define what a diverse affiliation of contributors is.
14:34:20 <ttx> you have projects with it and projects without it.
14:34:24 <jaypipes> exactly.
14:34:28 <maishsk> fifieldt: agreed. repo in stackforge, irc meeting, etc..
14:34:41 <fifieldt> I don't think I can see any remaining failures as noted by jaypipes that I'm uncomfortable with - can anyone else?
14:34:41 <jproulx> ttx that's the first actual reason for bianry tagging I've heard that wasn't just definitional
14:35:14 <ttx> if we just try to ddescribe diversity in a YAML dictionary, we let the exercise to the reader
14:35:32 <ttx> to determine if we consider this is diverse or not enough diverse
14:35:37 <ttx> tags are opinionated basically
14:35:37 <jaypipes> jproulx: http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg55338.html listed 4 of them.
14:35:43 <ttx> ops-data is documentation, not opinionated
14:35:47 <jproulx> I don't think conveying actionable items is the primary goal of ops-tags, but it is a usefull side effect
14:35:59 <fifieldt> a comparison to diversity tag is https://review.openstack.org/#/c/189168/
14:36:14 <fifieldt> which uses a percentage rather than the declaration of in or out
14:36:28 <ttx> jproulx: I'm totally fine with structured documentation about projects. I just think it's a different g oal that tags are after
14:36:33 <fifieldt> as ttx says - leaving the excercise to the reader
14:36:36 <jaypipes> fifieldt: and that percentage will be IMMEDIATELY invalid/inaccurate.
14:36:46 <ttx> I'm also fine defining tags on top of ops-data
14:36:59 <ttx> I just want us to acknowledge those are different things
14:37:02 <ttx> both valuable
14:37:16 <fifieldt> jaypipes, I think it remains valuable information
14:37:51 <fifieldt> certainly, we've had some good feedback about providing this information in the user survey
14:37:52 <ttx> I'm not as strongly convinced as Jay that ops-data approach is bad. I think you should definitely try
14:37:55 <jproulx> I'm not opposed to deriving binary tags from ops-data, I'm just unconvinced the extra layer is really needed
14:37:59 <fifieldt> despite its, as you say, inaccuracy :)
14:38:35 <jproulx> my concern with trying binary first is that simplifying from strutured to binary seem much simpler than going the other way should our initial choice be wrong.
14:38:41 <ttx> jproulx: it's fine if you don't define tags on top of ops-data. I plan to use ops-data in some of our tags definition for sure
14:38:42 <maishsk> and as always - (as we all should be agile) get something working - and improve / re-iterate
14:38:49 <ttx> maishsk: ++
14:38:52 <maishsk> so if it does not work out - it cshould / can be changed
14:39:12 <ttx> jproulx: I don't think you need to do tag first. I agree that raw data is a prerequisute
14:39:24 <fifieldt> indeed maishsk
14:39:31 <fifieldt> these are our very beginnings
14:39:37 <fifieldt> and I think we should have a go
14:39:41 <fifieldt> and see what we can do :)
14:39:42 <lsell> ultimately, i'd love to see the tc and uc cooperate on this. i think we just need to put some cycles into how the display would work to see if the ops vision is viable...or if the binary approach is ultimately better, and then we can further discuss implementation and naming
14:39:48 <maishsk> fifieldt: +1
14:40:00 <ttx> But then I don't want to spend the whole meeting discussing naming. I just want you to consider those are different pieces of data wiuth different goals, and therefore would suggest you pick a different name to describe yours
14:40:01 <fifieldt> lsell +1
14:40:05 <maishsk> lsell: that sounds like a plan
14:40:11 <ttx> for the sake of avoiding confusion to our users
14:40:13 <fifieldt> I think a lot of it will fall out in the wash when we start talking about display
14:40:26 <jproulx> fifieldt: +1
14:40:50 <fifieldt> random question - with the JSON stuff, I kinda feel like it's editing a config file, and therefore quite comfortable for me from an ops background - did anyone else feel that?
14:41:09 <maishsk> fifieldt: json is fine
14:41:39 <maishsk> ttx: I am fine with a different name - the only thing is it is not one voice - but I am not sure it has to be
14:41:53 <ttx> fifieldt: <maishsk> Mind if I raise a strange question - do we have operators have any specific reason to call these �tags�
14:42:09 <jaypipes> fifieldt: can you guys at least consume the openstack/governance projects listing so you don't have typos and inconsistencies in the project names?
14:42:30 <maishsk> jaypipes: For sure - I will take that one up personally.
14:42:35 <jaypipes> ty
14:43:40 <ttx> the reason the TC ones are called "tags" fits with https://en.wikipedia.org/wiki/Tag_%28metadata%29
14:43:56 <ttx> i.e. keywords
14:44:15 <ttx> which is essentially a binary field: there or not there
14:44:20 * maishsk has just been volunteered as the typo/inconsistency Czar
14:44:26 <fifieldt> :D
14:44:35 <fifieldt> indeed, ttx though I think a naming discussion should probably be moved to another forum
14:44:38 <ttx> I think what you are building is operational data about projects
14:44:40 <fifieldt> we still have several agenda items on the go
14:44:52 <ttx> ack, will shut up now. Just somethign to keep in mind
14:44:59 * fifieldt hears you!
14:45:00 <jproulx> ttx: I agree that's the goal
14:45:03 <fifieldt> last chance for binary vs structured data?
14:45:25 <ttx> fifieldt: I think you need structured data before you can build binary tags.
14:45:26 <fifieldt> ... going once ...
14:45:37 <fifieldt> indeed - we need to get some stuff in the repo :D
14:45:42 <fifieldt> which is in fact our next topic!
14:45:49 <fifieldt> so, let's move to:
14:45:49 <ttx> how convenient
14:45:52 <fifieldt> #topic     Discussion of tags underway: ops:packaged tag, ops:docs:install-guide, ops:production-use
14:46:09 <fifieldt> How are we feeling? Anyone want to start with a particular tag?
14:46:39 <maishsk> packaged is a ‘potential’ hot potato
14:46:54 <fifieldt> so, perhaps we should start then with an easy one:
14:46:55 <fifieldt> https://review.openstack.org/#/c/189168/
14:47:01 <fifieldt> ops:production-use
14:47:02 <maishsk> ops:docs:install-guide - should be a ‘potential’ slam dunk
14:47:09 <fifieldt> oh, damn
14:47:12 <maishsk> ;)
14:47:13 <fifieldt> we clashed :)
14:47:19 <fifieldt> well, maishsk you've been doing all the work so far
14:47:23 <fifieldt> so maybe let's go with yours
14:47:34 <fifieldt> https://review.openstack.org/#/c/186638
14:47:39 <fifieldt> Add ops:docs:install-guide tag
14:47:45 <fifieldt> this was supposed to be our easy one :)
14:47:57 <fifieldt> so, is it good to merge? :)
14:49:00 <fifieldt> there was a new section around when this would likely be updated
14:49:03 <fifieldt> any problems there?
14:49:14 <maishsk> fifieldt: will give it a last look-see and +1 if ok
14:49:19 <fifieldt> ok, cheers
14:49:28 <fifieldt> any other comments on docs:install-guide?
14:49:31 <jproulx> I've not followed through all the comments are there any outstanding objections likely?
14:49:35 <fifieldt> nope
14:49:49 <fifieldt> your review would be helpful :)
14:49:58 <jproulx> after meeting I'll review & likely +2
14:50:04 <fifieldt> ok, it seems people haven't had a chance to see that one yet
14:50:07 <jproulx> based on quick look now
14:50:18 <fifieldt> let's move to https://review.openstack.org/#/c/189168/ ops:production-use
14:50:33 <fifieldt> basically the outstanding question here was the actual data format
14:50:41 <fifieldt> whether it;'s a percentage, a ranged number or something else
14:50:49 <fifieldt> personally, I think it would be very nice when we display a set of tags
14:50:53 <fifieldt> to have a continuous number
14:50:58 <fifieldt> that we can use to sort things
14:51:01 <ttx> fifieldt: I'll start a openstack-operators thread on the naming to avoid further polluting the meeting.
14:51:22 <fifieldt> I also think it's just going to be easier to directly use the user survey data
14:51:34 <jproulx> given variablility in the number of total responses I'd think percentage would eb best
14:51:34 <fifieldt> rather than having to look at one number and write another :)
14:51:59 <fifieldt> I know maishsk had some thoughts on this - did we managed to convince you? ;)
14:52:29 <maishsk> for me it makes no difference - I am just trying to think with my operator hat on
14:52:33 <fifieldt> ok :D
14:52:50 <maishsk> do I care if it 49% or 50% - is that useful to me
14:53:03 <fifieldt> right
14:53:05 <maishsk> or a range will tell me more?
14:53:16 <maishsk> not convinced either way
14:53:28 <fifieldt> but if there's numbers 90, 89, 75, 20, 8, 6
14:53:37 <fifieldt> is "90" somehow better than "89"?
14:53:44 <fifieldt> by being in an 90-100 category
14:54:18 <fifieldt> are 20 / 8 / 6 all "bad"
14:54:29 <fifieldt> or is perhaps 20 a lot better than 6
14:54:37 <fifieldt> I think I sound insane :)
14:54:41 <fifieldt> anyway, we don't have a lot of time
14:54:45 <fifieldt> perhaps comment on the review
14:54:48 <maishsk> will do
14:54:52 <fifieldt> and let's get on to ops:packaged
14:55:00 <fifieldt> I made a fairly significant update to this earlier in the week
14:55:13 <fifieldt> removing pkgtype
14:55:24 <jaypipes> fifieldt: it's still in the JSON file... FYI.
14:55:40 <fifieldt> thanks jaypipes!
14:55:45 <fifieldt> basically, when I originally added pkgtype, I was thinking it was more like an internal note to those of us updating the tag
14:55:50 <fifieldt> rather than something for display
14:56:13 <fifieldt> but under discussion it morphed into a behemoth
14:56:37 <fifieldt> basically, I don't think we've got enough peeps to get into the game of doing each distro (+ potentially distro version) for each package
14:56:56 <fifieldt> and as jproulx noted earlier
14:57:07 <fifieldt> for "availabilty" you can just jump in on the package manager
14:57:10 <fifieldt> and find it out
14:57:50 <fifieldt> but we do still have some good distro specific stuff in the caveats
14:57:54 <fifieldt> which is much more maintainable
14:58:01 <fifieldt> basically just a few links to check
14:58:22 <fifieldt> what I would love to see in the future is to turn some of those post-release mailing list posts about massive packaging fail into tag updates
14:58:38 <fifieldt> so this leads to display also - making it easy for people to contribute to the tag
14:58:43 <fifieldt> anyway, I ramble
14:58:46 <fifieldt> thoughts, aznyone?
14:58:49 <fifieldt> (2 mins to go)
14:59:11 <jproulx> sounds largely good but perhaps not decidable in 2min
14:59:17 <fifieldt> oh, for sure
14:59:32 <maishsk> jproulx: +1
14:59:47 <fifieldt> ok, with a minute to go
14:59:55 <fifieldt> we probably need to wrap up, since ceilometer will be here soon
14:59:58 <jproulx> probably time to call it and roll teh rest of the agenda to next meeting?
15:00:01 <fifieldt> I think we have a lot of work ahead of us
15:00:07 <fifieldt> so why don't we meeet again in two weeks?
15:00:08 <ttx> fifieldt: have to run
15:00:15 <fifieldt> thanks ttx~!
15:00:19 <jproulx> fifieldt +1
15:00:20 <maishsk> fifieldt: sure!
15:00:24 <maishsk> Thank you!
15:00:25 <fifieldt> maishsk has made the calendar thing already
15:00:30 <fifieldt> so see you on the ML
15:00:41 <fifieldt> #info check gerrit for tag reviews
15:00:46 * maishsk runs for his ride home
15:00:54 <fifieldt> Thank you all for participating
15:00:59 <fifieldt> #endmeeting