20:01:44 <ttx> #startmeeting tc
20:01:45 <openstack> Meeting started Tue Jan 13 20:01:44 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:49 <openstack> The meeting name has been set to 'tc'
20:01:52 <ttx> Our agenda for today:
20:01:58 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:22 <ttx> First, a number of changes about the project structure reform
20:02:27 <ttx> #topic Template for tags definition
20:02:32 <ttx> #link https://review.openstack.org/145734
20:02:39 <ttx> This one is the first step, defining a base template to use to define future tags
20:02:48 <ttx> In this new patchset I included the "category" concept that multiple people suggested.
20:03:02 <ttx> I also separated (as requested) proposing the tag definition from applying the tag to existing projects, to facilitate adoption of proposed tags
20:03:22 <ttx> So in the tag definition you only list examples of projects that would likely get the tag applied, rather than proposing the full governance change
20:03:30 <ttx> Comments / discussion on that one ?
20:03:42 <mikal> Seems that review is quite new?
20:03:43 <ttx> I guess we can refine the template as we go, doesn't have to be perfect the first time
20:04:01 <ttx> mikal: proposed Jan 8
20:04:05 <mikal> I'll take a look at it later today
20:04:15 <mikal> ttx: sure, so last week sometime
20:04:20 <jaypipes> +1 from me on it.
20:04:24 <jeblair> i think the 2 step process is good.  what's the example use of categories?
20:04:24 <mikal> ttx: not angry, just noting I haven't looked at it yet
20:04:38 <ttx> mikal: I suspect LCA makes you a busy man
20:04:50 <mikal> ttx: its true, I am in fact in a keynote right now
20:04:59 <ttx> jeblair: typically release:coordinated, release:compatible etc
20:05:02 <jeblair> i am not, so i really hope they don't call my name
20:05:11 <mikal> jeblair: heh
20:05:17 <mikal> jeblair: if they do you'll never live it down
20:05:42 <ttx> Let's move on to the second part
20:05:44 <sdague> ttx: so a lot of tags are going to end up with reference materials, have we thought about ways to express that?
20:05:48 <jeblair> ttx: is there something about the category structure that optimizes it?
20:06:04 <sdague> docs:api-reference-partial:<some url>
20:06:07 <jeblair> ttx: like, do you still have to define foo:bar and foo:qux as separate tags, each with a tc review, etc?
20:06:09 <ttx> jeblair: I didn't want to over-engineer it before the tags start coming
20:06:22 <annegentle_> my thinking for docs, though, is that if we cant' automate the tagging, it's not worthwhile
20:06:23 <jeblair> ttx: or is it purely just a suggestion for how to name them?
20:06:32 <annegentle_> it's just another truth test I won't be able to keep up with
20:06:40 <ttx> jeblair: so far it's a name. But we could share some process within the same category
20:06:48 <jeblair> ttx: yeah, not suggesting that, just trying to determine how much they have been engineered. ok sounds good.
20:07:10 <ttx> annegentle_: automating is fine if you can manage it
20:07:25 <annegentle_> ttx: I'm saying if the tags aren't accurate what good are they
20:07:32 <dhellmann> annegentle_: you could also delegate that to the projects, who will be motivated to keep their tags up to date
20:07:35 <annegentle_> ttx: and it's too difficult to autmoate some of that
20:07:41 <annegentle_> dhellmann: yeah that makes sense
20:07:54 <annegentle_> not trying to over engineer, believe me :)
20:08:24 <ttx> annegentle_: no you're right... not sure we can avoid some staleness in data (much like the list of repos sometimes lags reality)
20:08:37 <annegentle_> thinking docs especially will have a tough time marking completeness
20:08:52 <ttx> sdague: not sure what you mean by 'reference materials'
20:08:53 <annegentle_> but driver coverage, api call coverage, sure
20:09:17 <mikal> Oh interesting
20:09:22 <mikal> Do we put sunsets on tags?
20:09:28 <mikal> So they expire when they become stale?
20:09:38 <mikal> Or do we have to manually clean them up when they're no longer true?
20:09:49 <sdague> ttx: well something like api docs is going to have a url where those api docs exist, which is important first order info for someone evaluating the project
20:09:55 <ttx> mikal: by default I would say clean up when false
20:10:13 <mikal> ttx: a once per release audit thing?
20:10:25 <devananda> I'm struggling to see how a "partial" or "complete" tag makes sense beyond the point in time in which it is tested
20:10:27 <ttx> sdague: not sure I would pack that attribute in the tag name though
20:10:28 <jeblair> sdague: though that should also be standardized; eg docs.o.o/something/project
20:10:34 <annegentle_> sdague: good litmus, but right now, projects that aren't blessed don't get to use openstack.org domains
20:10:40 <ttx> sdague: I see your point -- allowing the tag to have a value basically
20:10:42 <annegentle_> sdague: so is it "good enough" to have docs offsite
20:10:49 <annegentle_> sdague: or even preferred
20:11:07 <ttx> mikal: depends on tag I'd say, but yes, a regular audit
20:11:25 <devananda> ttx: once a "complete" tag is put on something, who audits it?
20:11:38 <devananda> who determines that it is stale and should "fall back" to partial?
20:11:41 <mikal> ttx: ok
20:11:42 <ttx> devananda: shoudl be part of the tag definition, in the process section
20:11:59 <sdague> annegentle_: it might be. For something like upgrade readiness I'd really want to be able to put a url in there for reference so people have the footnotes of the evaluation
20:12:08 <devananda> the projects themselves will not have an incentive to keep these status-based tags up to date
20:12:29 <russellb> sdague: seems like we could have metadata with tags expressed as child elements in yaml
20:12:32 <sdague> if the point of this is to provide assessment material to ops, the footnotes are going to be one of the most interesting parts
20:12:35 <russellb> as applicable
20:12:38 <sdague> russellb: sure
20:12:44 <ttx> devananda: for example, imagine a 'security-supported' tag that says that the VMT is issuing advisories for your project
20:12:46 <russellb> defined as a part of the tag proposal
20:12:52 <ttx> that tag requires you to provide a security liaison
20:13:08 <dhellmann> sdague, russellb : yeah, I'd like to have a release version associated with the tags to make building the tables easier, too
20:13:10 <ttx> If the project has a dead liaison, I'd expect the VMt to remove the tag
20:13:12 <sdague> russellb: yeh, I could definitely go that way as well, that would make it easy to automatically parse
20:13:17 <ttx> (if nobody steps up)
20:13:26 <devananda> ttx: ok - that works. the tag doesn't say "is secure" but rather "is supported by security team".
20:13:32 <ttx> right
20:13:33 <russellb> dead liason sounds morbid, heh
20:13:44 <devananda> ttx: my concern is for tags that indicate a quality, such as "well documented" or "partially documented"
20:13:53 <annegentle_> devananda: me too.
20:14:08 <ttx> devananda: I'd rather have tags describe objectove quality
20:14:14 <ttx> "partial" sounds a bit.. subjective
20:14:23 <jaypipes> russellb, sdague: you mean like this? https://review.openstack.org/#/c/126581/2/openstack-projects.yaml
20:14:27 <devananda> ttx: if the tag is "doc-syupporeted" -- great. that's measurable and clear. it could mean the doc team is working with doc writers from the project team, and docs are on docs.oo
20:14:29 <dhellmann> devananda: yeah, I don't think we would approve those sorts of tags at all
20:14:33 <annegentle_> ttx: with docs you just can't say
20:14:54 <devananda> dhellmann: ok. maybe i misread an earlier comment about partial/complete tags
20:14:56 <ttx> annegentle_: you could have a "docs:anne-likes-it"
20:15:03 <annegentle_> ttx: riiiiiight.
20:15:11 <annegentle_> I hate all your docs! /ragequit
20:15:12 <annegentle_> :)
20:15:25 <dhellmann> devananda: or maybe I missed that; either way, I wouldn't want "doneness" included in most of the tags
20:15:37 <russellb> jaypipes: sure, maybe, something like that anyway :)
20:15:45 <devananda> dhellmann: cool
20:15:46 <sdague> jaypipes: yeh, possibly. Though honestly I think reference subtree is probably appropriate.
20:16:00 <ttx> I'd say that's a bridge we'll cross as more tags are proposed. We should definitely be careful with subjective tags
20:16:01 <sdague> also... it honestly feels like this kind of needs to be temporal
20:16:07 <jaypipes> sdague: sorry, not following you... what is a "reference subtree"?
20:16:18 <sdague> jaypipes: what russellb proposed
20:16:53 <jaypipes> sdague: you mean like this? https://review.openstack.org/#/c/126581/2/project-schema.json
20:16:57 <russellb> i didn't have anything written down
20:17:06 <sdague> for instance "upgrade:manual" "upgrade:offline" "upgrade:online" with references to back up those decisions
20:17:16 <devananda> ttx: perhaps some guidelines in the template that we should avoid completeness-based and subjectively-applied tags
20:17:27 <russellb> just agreeing that 1) the application of a tag could have associated metadata, 2) we can easily capture that in yaml in a tree (and not in the name)
20:17:35 <ttx> devananda: sounds like a good suggestion -- please add comment and I'll roll it in
20:17:39 <devananda> ttx: and stick to representational and objectively measurable things
20:17:41 <sdague> russellb: yeh, honestly, we can extend over time
20:17:41 <devananda> ack
20:17:46 <sdague> so the temporal question
20:17:48 * markmcclain arrives late
20:18:01 <ttx> let's move on to the practical example
20:18:05 <ttx> #topic Definition of the initial 'integrated-release' tag
20:18:14 <ttx> That one was split in two (defining and applying):
20:18:18 <ttx> #link https://review.openstack.org/145735
20:18:21 <sdague> it seems like from an operator point of view, the state of things in icehouse vs. the state of things in kilo is a real think
20:18:23 <ttx> #link https://review.openstack.org/146818
20:18:26 <sdague> s/think/thing/
20:18:30 <sdague> not just integration status
20:18:35 <sdague> but for *all of it*
20:18:41 * ttx thanks sean for writing that blogpost about splitting commits
20:19:07 <ttx> Like Jay mentioned, I think the 'integrated-release' tag should have no category since it's the absolute tag that covers so many different things today
20:19:10 <jaypipes> ttx: link to that blog? :)
20:19:22 <jaypipes> or sdague ...
20:19:22 <ttx> #link https://dague.net/2014/07/24/splitting-up-git-commits/
20:19:25 <jaypipes> danke
20:19:36 <ttx> Apart from that, it's pretty straightforward since it's a frozen tag
20:20:29 <ttx> sdague: can't we have that information from git history ?
20:21:04 <sdague> ttx: that assumes that tags are applied completely synchronisly to whatever functionality is out there
20:21:05 <ttx> (and from git tags at each cycle)
20:21:38 <dhellmann> it would be a lot easier to get if it was just included in the yaml
20:21:38 <sdague> and that we don't come up with a new tag that we want to apply to currently supported versions of openstack in the field
20:21:39 <ttx> sdague: I see your point
20:21:40 <annegentle_> I think that there's value in knowing which release things originally went together, but that's not the point is it?
20:21:54 <sdague> dhellmann: honestly, I think it's a top level construct, it's in the filesystem
20:22:06 <dhellmann> sdague: or there -- not the git history was my point
20:22:10 <devananda> there is likely to be some lag time in applying tags anyway
20:22:28 <devananda> it is, after all, a separate process from the changes which the tags refer to
20:22:51 <ttx> sdague: any suggestion on how we could represent that ?
20:22:53 <devananda> so don't we need a means to represent "this tag applies to the state of $thing at $point in time"
20:23:13 <sdague> ttx: honestly, I'd do it in the filesystem
20:23:23 <sdague> juno/projects.yaml
20:23:51 <annegentle_> sdague: that would take care of it
20:24:06 <ttx> sdague: per cycle ? So we would mandate some (limited) adherence to dev cycles for all projects
20:24:16 <jeblair> i think that's conflating this with the release cycle, and i don't think we should do that
20:24:31 <devananda> jeblair: ++
20:24:40 <sdague> ok, well that's my best idea :)
20:24:40 <ttx> yes, same point than jeblair
20:24:42 <annegentle_> oh yeah.
20:24:43 <annegentle_> hm
20:24:45 <devananda> tag-applies-at-SHA:
20:24:50 <annegentle_> sigh
20:24:58 <sdague> devananda: that's completely useless from an ops perspective
20:25:00 <dhellmann> yeah, a subproperty under the tag would let us be more flexible about what time marker we use (dates, releases, whatever)
20:25:14 <jeblair> i'm not certain this needs to be quite so comprehensive
20:25:21 <ttx> OK, we'll have to brainstorm how we can express tags in two dimensions
20:25:41 <ttx> (and if)
20:25:59 <jeblair> i mean, just adding notes like "foo achieved online upgrades starting with the lemming release" may convey the needed information
20:26:18 <ttx> jeblair: ++
20:26:29 <sdague> maybe, how would that be consumed?
20:26:45 <devananda> sdague: date seems similarly not helpful, then
20:26:48 <vishy> projects could be required to make release tags
20:26:55 <jeblair> sdague: by humans reading the notes in jaypipes' tag display/navigation app?
20:26:56 <sdague> an operator comes to OpenStack capabilities site and navigates to where to get the view
20:26:56 <vishy> * git tags
20:27:06 <devananda> jeblair: that isn't machine parseable. and what about projects which dont follow the release cycle?
20:27:08 <ttx> I speent some cycles seeing if I could easily save the -since info from that YAML but couldn't come with something simple and elegant
20:27:13 <vishy> using whatever version number they want
20:27:20 <jeblair> devananda: "notes: 'foo achieved online upgrades starting with the lemming release'"
20:27:31 <vishy> so we could use the 2014.1 tag for example
20:27:36 <jgriffith> tags seems promising
20:27:42 <vishy> and swift could use 2.5
20:27:46 <vishy> or whatever
20:27:48 <annegentle_> tags for tags. sweet.
20:27:50 <jeblair> vishy: that sounds good
20:27:55 <sdague> vishy: yeh, release tags are good
20:28:03 <jgriffith> annegentle_: lol
20:28:08 <sdague> it should be an artifact that actually escaped
20:28:36 <devananda> vishy: +1
20:28:37 <jeblair> ttx: also, you can put "integrated-since" back in the new format.  ;)
20:28:50 <vishy> although branch name might be better
20:28:52 <ttx> eh
20:29:08 <vishy> if these need to move
20:29:10 <sdague> so, honestly, I also expect that with the preponderance of values coming in, we realistically probably want to split up projects.yaml into on per project
20:29:29 <ttx> sdague: reduce conflicts ?
20:29:30 <vishy> i suppose if they are “since XXX” they don’t need to move
20:29:31 <sdague> vishy: I actually think branches are bad for this
20:30:00 <ttx> ok we need to move on... let's continue the discussion on the review
20:30:05 <sdague> ttx: yeh, and size of this file
20:30:31 <ttx> sdague: I think that can be a subsequent change
20:30:37 <sdague> ttx: agreed
20:30:37 <ttx> #topic Move from program-based structure to project-based (including new projects requirements)
20:30:43 <ttx> #link https://review.openstack.org/145740
20:30:50 <ttx> So... this one is obviously more open-ended. There are two sides in it:
20:30:59 <ttx> 1/ switch wording from "programs" (with their expectation of exclusivity) to a team-oriented "projects" concept
20:31:10 <ttx> 2/ define base objective requirements for new projects -- in effect, what you must meet to be considered "an OpenStack project"
20:31:24 <ttx> On the first one there were comments on the wording -- basically should we call "the Nova project" what the Nova team works on
20:31:39 <ttx> On the second one the comments were mostly about details (should we recommend Apache licensing, should we require logged IRC channels, and how to best express the Keystone interoperability requirement
20:31:52 <ttx> Not sure everyone got their chance to review those in context yet though.
20:31:57 <dhellmann> do we need to ditch the word "program" or is it enough to redefine it?
20:32:06 <ttx> From my previous discussions it appeared there was lack of convergence on those, and that lack is not really showing in comments yet.
20:32:16 <ttx> dhellmann: I think we need to ditch it
20:32:44 <ttx> dhellmann: nobody ever got what it meant -- and now it conlicts with "trademark license programs"
20:32:45 <dhellmann> I just thought keeping it would let us eliminate the issue with overloading the term "project"
20:32:49 <dhellmann> ah, ok
20:33:20 <ttx> the problem is program as a theme aspect -- Deployment is a program
20:33:23 <ttx> has*
20:33:25 <annegentle_> yeah I think it's tough to explain programs v projects (and now v trademark program)
20:33:47 <ttx> TripleO is not a program, it's a project
20:33:50 <jeblair> we'll just have to say 'the openstack project' when we mean that now.  which, honestly, i've had to do for a while anyway.
20:34:17 <ttx> I think everyone says "the Nova project" -- nobody says "the Nova program"
20:34:24 <annegentle_> ayup
20:34:28 <ttx> so let's just use what people already use
20:34:34 <morganfainberg> ttx, ++
20:34:48 <ttx> agree there is /some/ collision with "the OpenStack project"
20:34:50 <mikal> We do say "Compute Program", but we don't know what it means
20:34:57 <ttx> mikal: heh
20:34:57 <mikal> So "Nova Project" makes more sense to me to be honest
20:35:00 <sdague> mikal: ++
20:35:10 <markmcclain> ++
20:35:17 <mikal> I do want better words for "OpenStack projects" though
20:35:23 <mikal> Cause I don't like using project at two levels
20:35:32 <mikal> Perhaps "OpenStack Ecosystem"
20:35:50 <ttx> Ecosystem / Projects / Code repositories
20:36:01 <ttx> that would be the 3 levels
20:36:08 <mikal> That works for me
20:36:13 <devananda> mikal: ++
20:36:16 <mikal> Programs made it hard to explain IMHO
20:36:17 <annegentle_> that reflects reality
20:36:21 <ttx> btw, tags apply to repositories
20:36:26 <annegentle_> is it docs project then?
20:36:29 <annegentle_> infra project?
20:36:39 <ttx> annegentle_: yes?
20:36:45 <annegentle_> I think so (docs project)
20:36:53 <annegentle_> just making sure
20:37:00 <ttx> release cycle management project might need some rebranding
20:37:08 <ttx> because that sounds weird :)
20:37:14 <jeblair> so, the tc governs the ecosystem?
20:37:29 <mikal> ttx: How about "Operation Kermit Arms"?
20:37:31 <ttx> the ecosystem of OpenStack projects yes
20:37:44 <ttx> mikal: lol
20:37:46 <annegentle_> one other question coming in is, does a stackforge repo get tagged?
20:37:50 <jeblair> sounds a little bit of a reach to me.
20:37:53 <ttx> annegentle_: no
20:38:13 <dhellmann> jeblair: yeah, I think ecosystem is generally understood to include things we don't control
20:38:14 <ttx> but then I expect some stackforge project to apply to become openstack projects and be accepted
20:38:17 <devananda> annegentle_: but they can ask to move to openstack/ more easily now
20:38:49 <ttx> I invite you all to continue that discussion on the changes themselves, and we'll continue that discussion next week -- we have a couple more items to cover today
20:38:52 <annegentle_> what if no PTL wants it?
20:39:07 <annegentle_> (asking for a friend)
20:39:09 <devananda> ttx: how does ecosystem/project/repository describe divergent solutions to the same problem?
20:39:11 <ttx> annegentle_: they would have their own PTL
20:39:16 <annegentle_> got it
20:39:20 <ttx> they don't need to be adoped
20:39:22 <ttx> +t
20:39:29 <annegentle_> sorry have to step afk for a few but will catch up
20:39:46 <ttx> devananda: multiple projects can share overlapping scopes ?
20:40:02 <devananda> ttx: yes
20:40:23 <ttx> ok, moving on -- please comment on those changes
20:40:27 <ttx> #topic Tally votes on log guidelines openstack-spec
20:40:32 <ttx> #link https://review.openstack.org/#/c/132552/
20:40:43 <ttx> The TC is supposed to tally the votes from PTLs and the crowd on specs in openstack-specs, and I think that time has come for the log guidelines one
20:40:52 <ttx> It's been discussed at last week's cross-project meeting
20:41:05 <ttx> Some people said there was room for improvement in the future, but nobody opposed this version of the spec as a first step
20:41:24 <devananda> wow, most votes I think I've ever seen on a patch. awesome
20:41:38 <ttx> It's the first one we do so I'm not sure how to proceed -- we can do it same style as TC votes I guess
20:42:03 <ttx> or have one of us just tally the vote and Workflow+1 it
20:42:12 <ttx> suggestions?
20:42:16 <mikal> Oh poo
20:42:23 <mikal> I just accidentally +W'ed that logs change
20:42:24 <vishy> i like tally and workflow+1
20:42:25 <sdague> honestly, I think doing it like normal repo, no -2 votes means it's able to be approved by anyone with +2
20:42:29 <dhellmann> I'd like to use the normal TC voting procedurs
20:42:32 <dhellmann> mikal: heh
20:42:33 <ttx> mikal: nice!
20:42:41 <mikal> How do I un +2?
20:42:46 <mikal> +W I mean
20:42:53 <dhellmann> sdague: I don't think 2 people should make decisions for the entire project. That's the point of bringing it under TC voting.
20:42:53 * ttx turns his +1 to +2
20:42:56 <jeblair> mikal: vote again
20:43:07 <ttx> well it merged
20:43:11 <jeblair> ++ normal tc voting procedures
20:43:17 <ttx> so it's a bit late
20:43:20 <mikal> jeblair: sorry, merged too fast
20:43:25 <mikal> Sorry guys
20:43:27 <ttx> I knew we couldn't trust mikal with such powerz
20:43:32 <sdague> jeblair: so if we want that we should remove +A from everyone but ttx
20:43:48 <sdague> I thought we specifically stated this was normal specs rules when we got started though?
20:43:55 <ttx> yes
20:44:00 <ttx> sdague: we did say that
20:44:03 <dhellmann> that's not what I remember
20:44:09 <ttx> that any TC member could tally the votes
20:44:21 <ttx> which is why we all have APRV rights
20:44:34 <dhellmann> ok, but 2 votes of +2 shouldn't be enough for this one
20:44:52 <ttx> It actually has 6 +2s
20:45:02 <dhellmann> right, I meant this repo
20:45:05 <devananda> in either case, it has 6 +2's from TC and enough +1's from representatives of different projects that I feel comfortable with it
20:45:07 <dhellmann> sorry, not being clear
20:45:09 <ttx> dhellmann: oic
20:45:17 <jeblair> i think i may have an outstanding action item to do something about the permissions here
20:45:23 <dhellmann> yeah, I'm completely happy with this particular spec
20:45:31 <sdague> dhellmann: so I think the important part is no -2 after some amount of clear time
20:45:32 <jeblair> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-10-28-20.03.html
20:45:51 <ttx> I'm fine with limiting W+1 to TC chair and tally the vote using TC members +2
20:45:52 <sdague> when it's clearly had time to breath
20:46:01 <jeblair> i think that got assigned to me and then *summit*.  sorry.
20:46:07 <ttx> if you think that will avoid accidental W+1
20:46:22 <dhellmann> sdague: maybe that's good enough
20:46:30 <ttx> let's fix it before the next one needs to be approved
20:46:48 <mikal> I think using the TC voting rules makes sense to be honest
20:46:57 <mikal> Because this repo isn't something that's a core focus for a lot of people
20:47:05 <mikal> So getting prompted in a meeting to look by ttx is useful
20:47:47 <ttx> jeblair: did you have something different in mind ?
20:48:20 <sdague> fwiw - http://paste.openstack.org/show/157307/
20:48:39 <jeblair> i'm reading the meeting log
20:48:43 <ttx> maybe we can move that to the list or a future meeting, still a couple items to cover
20:48:50 <ttx> #topic Removal Plans for keystoneclient.middleware.auth_token
20:48:51 <sdague> jeblair: yeh, that's the relevant snipet I think
20:48:56 <sdague> at least the right time box
20:48:57 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054059.html
20:49:09 <morganfainberg> o/
20:49:10 <ttx> morganfainberg posted this to the -dev ML, requesting the TC members opinion on how to solve that backward compatibility dilemma
20:49:30 <ttx> #action ttx to put openstack-specs approval rules back on agenda in a future meeting
20:49:43 <morganfainberg> this is not a common issue with client libs. most don't have middleware like keystoneclient does.
20:50:04 <sdague> morganfainberg: it can be generalized to any interface use though
20:50:11 <morganfainberg> sdague, ++
20:50:16 <dhellmann> yeah, this came up in a similar way with oslo libs
20:50:19 <sdague> so I don't think that keystoneclient is really exceptional here
20:50:35 <morganfainberg> sdague, we're just at a point where we are ready to drop support in favor or something else.
20:50:38 <dhellmann> we talked about capping the requirements in stable branches, but ran into implementation issues and then I got busy on other things
20:50:44 <ttx> sdague: just another incarnation of the 'cap on stable' need ?
20:51:03 <sdague> ttx I think so - http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html was my best stab and putting down my thoughts
20:51:12 <ttx> yes, that was very helpful
20:51:45 <morganfainberg> i figured sdague's repsonse was probably the clearest direction to take / focus
20:51:57 <ttx> dhellmann: the question is more -- are those issues solvable. But that's not really a topic for this meeting
20:52:10 <sdague> so this remains one of those holes in doing stable compat testing correctly, instead of in our odd adhoc way
20:52:32 <sdague> and needs some champions
20:52:34 <dhellmann> ttx: yeah, every issue was a result of a test we were running, so we could decide to change them
20:52:39 <ttx> feels like we need to put a number of people in a room and lock it until stable capping is done. And I would probably be in that room
20:53:10 <ttx> but yes, orthogonal discussion
20:53:12 <morganfainberg> depending on the room size and number of people that project could get done faster or slower :P
20:53:21 <ttx> morgabra: do you agree that stable capping would solve the issue ?
20:53:25 <ttx> morganfainberg: ^
20:53:32 <morganfainberg> yes, capping should solve the issue
20:53:34 <ttx> multiple morga<TAB<
20:53:46 <ttx> morganfainberg: ok, we probably have a way forward then
20:53:56 <morganfainberg> ttx at least you used more than mor<tab> and get mordred instead of morganfainberg
20:54:01 <vishy> I have to head to another meeting. I want to add something to the meeting next week discussing oslo. I’m concerned that there aren’t enough experts for some of the really important shared components like oslo.db and oslo.messaging. Wondering if there is some way we can help.
20:54:25 <vishy> o/
20:54:28 <ttx> #action ttx to add oslo to next meeting
20:54:28 <dhellmann> vishy: find companies willing to devote resources to it
20:54:41 <ttx> ok, rushing through the last points on the agenda then
20:54:45 <ttx> #topic Other governance changes
20:54:50 <ttx> * oslo.policy promotion (https://review.openstack.org/142813)
20:54:59 <ttx> This one has dhellmann's +1, will approve tomorrow morning unless someone opposes it
20:55:06 <ttx> * Add debtcollector library for oslo project/program (https://review.openstack.org/146224)
20:55:14 <ttx> Same here
20:55:33 <ttx> Any comment on those two ?
20:55:57 <russellb> lgtm
20:56:00 <ttx> #topic Open discussion
20:56:09 <ttx> I'd like to start the L naming poll before the end of the month
20:56:19 <ttx> As some of you know, the marketing folks were a bit alarmed at the idea of fighting easy anti-OpenStack jokes if we picked the Lemming name
20:56:34 <ttx> Now that they explained it to me, I can only agree with them that it would be a gift to all the haters
20:56:41 <russellb> agreed
20:56:50 <ttx> The trademark checks came back OK for Love, London, Liberty and Lizard, so I propose we run the poll with those four options
20:57:13 * dhellmann predicts London, in keeping with our "not the one you think" naming record
20:57:19 <sdague> heh
20:57:22 <ttx> I would be fine with that
20:57:32 <russellb> i wouldn't hate any of them, so works for me
20:57:39 <ttx> Love and Liberty are a bit too cheesy to my taste
20:57:56 <ttx> or maybe it should be named Charlie and mess people up
20:58:01 * morganfainberg agrees with dhellmann
20:58:21 <ttx> Anything else, anyone ?
20:58:35 <sdague> I'm good with that, though I thought there were some first nation names that were in the list as well which might be neat
20:58:40 <devananda> London is the least bad, but I'm meh on all of those
20:58:52 <sarob> i put "libre" out there
20:58:57 <ttx> sdague: was there ?
20:58:58 * jgriffith likes Lizard :)
20:59:03 <jeblair> i like lemming
20:59:20 <sarob> libre = free
20:59:22 <jgriffith> :)
20:59:30 <russellb> sarob: oh is that what that means?  :-p
20:59:37 <sarob> ugh
21:00:05 <sarob> better than lizard lemming
21:00:08 * devananda wanders off to get coffee befoer the next meeting.
21:00:08 <sarob> ;)
21:00:09 <ttx> sarob: there is no location named like that in Britsh Columbia though
21:00:17 <ttx> anyway end of meeting
21:00:20 <ttx> #endmeeting