20:02:00 <ttx> #startmeeting tc
20:02:00 <openstack> Meeting started Tue Feb 24 20:02:00 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:04 <openstack> The meeting name has been set to 'tc'
20:02:07 <ttx> Our agenda for today:
20:02:11 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:21 <ttx> #topic openstack-specs approval rules
20:02:29 <ttx> I put this one first since we'll need to use the decision here on the next topic
20:02:41 <ttx> Current state (once https://review.openstack.org/158666 lands) is:
20:02:51 <ttx> Anyone can +1, TC members can +2, TC chair can tally votes (and workflow+1)
20:03:01 <ttx> Does that work for everyone ?
20:03:04 <mordred> ++
20:03:05 <vishy> +1
20:03:06 <devananda> +1
20:03:08 <sdague> sure
20:03:12 <markmcclain> +1
20:03:12 <jeblair> yep
20:03:17 <mordred> best. thing. evar
20:03:19 <mikal> Works for me
20:03:20 <sdague> is there a quorum issue?
20:03:26 <ttx> #agreed openstack-specs approval rules: Anyone can +1, TC members can +2, TC chair can tally votes (and workflow+1)
20:03:38 <russellb> o/
20:03:40 <ttx> sdague: it's part of the "tally votes" thing
20:03:40 <russellb> ++
20:03:45 <sdague> ttx: ok, sounds good
20:03:50 <mikal> We should do that for the governance repo too
20:03:57 <ttx> sdague: ideally chair should only wiorkflow+1 when there is "consensus"
20:04:16 <mikal> i.e. let anyone +1 / -1
20:04:22 <ttx> mikal: I guess.. we could
20:04:32 <jeblair> mikal: did you read my mail to the list?
20:04:47 <mikal> jeblair: it depends when you sent it... its 7am here
20:04:50 <ttx> ISTR there was a reason not to
20:04:57 <jeblair> mikal: like 2 weeks ago
20:05:14 <mikal> I do not recall it then
20:05:32 <russellb> ttx: the need to differentiante between TC -1 vs. general -1 i think?
20:05:41 <annegent_> color coding?
20:05:48 <annegent_> (kidding)
20:05:53 <ttx> russellb: right, that one.
20:06:01 <jeblair> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056788.html
20:06:08 <jeblair> so anyway, there are some options
20:06:18 <jeblair> they are described in that email
20:06:29 <ttx> let's follow up there
20:06:40 <sdague> russellb: so... we all know who is in the TC right? We can read the votes :)
20:07:10 <ttx> jeblair: since that review to use the right group is blocked, could you add me to https://review.openstack.org/#/admin/groups/573,members so that we can proceed with approvals today ?
20:07:23 <mikal> Ahhh, I see
20:07:31 <russellb> sdague: sure, just trying to recall the reasoning way back when
20:07:33 <mikal> Its also about avoiding a TC member vetoing
20:08:14 <jeblair> ttx: done
20:08:18 <ttx> thx
20:08:21 <ttx> #topic Final rubberstamp on CLI Sorting Argument Guidelines
20:08:31 <anteaya> sorry ttx did want to have that in before the meeting
20:08:32 <ttx> #link https://review.openstack.org/#/c/145544/
20:08:49 <ttx> anteaya: np, we worked around it
20:08:59 <ttx> So I'm about to approve this review. Any last comments before I do ?
20:08:59 <anteaya> yep
20:09:16 <ttx> I still see unanimous support from where I stand
20:09:22 <ttx> and support from all the PTLs impacted
20:10:12 <annegent_> looks completely approvable to me
20:10:20 <ttx> ok, will take that as a yes
20:10:30 <ttx> approved
20:10:50 <ttx> #topic M+ Release naming process
20:10:58 <ttx> #link https://review.openstack.org/150604
20:11:14 <ttx> This proposal is still a bit short on approval
20:11:25 <ttx> Technically if I call for final voting it can pass if it gets 5 YES and less than 5 NO
20:11:41 <jeblair> i think we should ask people to vote asap and do last-call on this.
20:12:17 <ttx> jeblair: in meeting or before next week ?
20:12:32 <jeblair> i don't thing we should drag it out; if there are minor changes (like moving the date around) we can do those as followup ammendments
20:13:13 <ttx> ok, vote asap, let's try to close this one during the meeting
20:13:21 <ttx> I'd like to make sure we have volunteers to run this process if it's approved, too
20:13:22 <markmcclain> so my biggest concern is that the discussion is separate from the vote
20:13:32 <ttx> (since I think it will result in more pain that the current system, I'd rather not drive that train)
20:13:42 <ttx> jeblair, mordred: would you be ok to drive the M one ?
20:13:46 <jeblair> ttx: i think mordred has previous volunteered
20:13:49 <mordred> ttx: sure
20:14:08 <ttx> #indo mordred volunteered to drive the M release naming train on the new process, should it be accepted
20:14:12 <ttx> err
20:14:19 <ttx> #info mordred volunteered to drive the M release naming train on the new process, should it be accepted
20:14:26 * mordred puts the indo in his pocket for later
20:14:32 <ttx> markmcclain: discussion on ?
20:14:37 <markmcclain> the names
20:14:49 <jeblair> markmcclain: yeah, i think there's an attempt to tie them together though -- with the process for annotating names with discussion about them
20:15:12 <markmcclain> jeblair: cool.. that will work
20:15:17 <ttx> one issue I has in the past naming contests was that nobody would add names to the wiki page
20:15:29 <ttx> so names were randomly thrown out and never really "proposed"
20:16:03 <ttx> you'll probably have to make stronger calls
20:16:04 <russellb> has 6 YES now
20:16:29 <mordred> ttx: I will attempt to use my annoying voice
20:16:31 <ttx> ok, will approve if it has less than 5 NO by the end of the meeting (as it should)
20:16:47 <ttx> unless it gets a 7th YES right now
20:16:59 <ttx> #topic Projects using private communication channels
20:17:00 <markmcclain> it has 7 now
20:17:10 <ttx> markmcclain: ok approving
20:17:32 <ttx> not sure I can approve the vote without voting +2 on it though
20:17:52 <ttx> let's see
20:17:55 <jeblair> ttx: yeah, that's one of the points i addressed in my email.  we should be able to fix that too.
20:18:15 <ttx> I'll m´┐Żake my abstention known with a note then
20:18:19 <jeblair> ttx: in the mean time, i suggest you leave a comment indicating your +2 is procedural and you are actually (abstaining/voting no/etc)
20:18:34 <mordred> jeblair, ttx: we could force-merge it so that ttx doesn't have to +2 vote
20:18:45 <annegent_> mordred: oh dear the power.
20:18:51 <mordred> it is an awkward position to put him in
20:19:04 <ttx> It's fine, I commented
20:19:06 <mordred> kk
20:19:12 <jeblair> cool. we'll fix this in the acl overhaul.
20:19:26 <mordred> ++
20:19:29 <ttx> #undo
20:19:30 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa360f10>
20:19:34 <ttx> #topic Projects using private communication channels
20:19:38 <ttx> back on topic
20:19:44 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056551.html
20:19:47 <reed> o/
20:19:49 <ttx> reed: o/
20:19:56 <reed> I have tracked down the story of the private channel established within one of our project
20:19:57 <ttx> reed has been serving as ombudsman and contact point for the various parties on this issue
20:20:29 * mordred hands reed a cookie
20:20:32 <reed> the channel was created at one point in time with the specific intention to discuss a delicate issue that required privacy
20:20:55 <reed> the team that created it was very careful and made it +i +s
20:21:00 <ttx> just to confirm, I'm actually fine with private temporary channels created to gather people temporarily on an issue. I don't agree with protected / invite-only channels, or permanent private channels
20:21:08 <mordred> ++
20:21:18 <russellb> yeah, agree
20:21:20 <jeblair> ttx: i think that describes my feeling as well
20:21:35 <reed> the channel remained active *after* the crisis was over
20:21:36 <ttx> and making *not* protected actually ensures that they are temporary
20:21:39 <ttx> and using funny names
20:21:43 <amrith> could we let reed finish first please.
20:22:20 <reed> but the team using it wasn't really using it for anything but a convenient place where to discuss other topics that rquired privacy
20:22:30 <reed> this has happend once or twice only
20:22:59 <reed> i was also reassured that the team was not 'hanging out' in that private team
20:23:35 <reed> meaning that the channel was not used much and the group was self-policing it so that public topics were addressed on the public channels
20:23:36 <annegent_> reed: or anyone really, can you give more info on the meaning of +i and +s?
20:23:40 <vishy> so it kind of sounds like someone made a mountain out of a molehill
20:23:51 <reed> vishy, sort of...
20:24:12 <ttx> well, the trick is... permanent private channels always degenrate
20:24:15 <reed> as I mentioned on email, I think that a *permanent* private channel develops bad habits
20:24:30 <reed> and they should not be used
20:24:45 <reed> temporary private channels I'm ok with them
20:24:53 <amrith> annegent_, IRC channel flags (https://www.alien.net.au/irc/chanmodes.html), +i invite only, +s secret
20:25:07 <ttx> discussing things is so much more convenient when the crowd is controlled that you end up discussing stuff there that you shouldn't
20:25:15 <annegent_> reed: do you have any analysis on the "internet jury/public shaming" aspect of the mailing list thread? What I mean is, how can we ensure the mountain doesn't rise up again from some other misunderstanding?
20:25:32 <annegent_> how can we encourage trust rather than distrust?
20:25:33 <mikal> So, in the interests of full disclosure, the group now known as nova-specs-core had a private channel which we used while navigating the early days of how specs would work. That channel appears to have been used between 22 April 2014 and 18 June 2014, but has been idle since. We never did get around to deleting it though.
20:25:34 <ttx> it's one thing to have company-private channels (like everyone has)
20:25:54 <annegent_> thanks for that mikal
20:25:56 <reed> annegent_, the email thread was not about an IRC channel only
20:26:02 <ttx> iit's another to have a channel in the openstack community exclusing another part of the community permanently
20:26:16 <ttx> excluding*
20:26:46 <ttx> So I guess we can consider the issue closed on the particular issue that raised this thread. Should we write a resolution to avoid that kind of "issue" in the future ?
20:26:48 <anteaya> I think annegent_ brings up a good question, how do we encourage trust
20:26:48 <mikal> Frankly, I see that happening a lot more with company channels than I do with private channels based on available data
20:26:54 <devananda> mikal: ty. I have been wondering what all this was actually referring to, and while I love talking in the abstract, it's good to know
20:26:59 <ttx> Or was the current noise about it enough to prevent it in the future ?
20:27:14 <russellb> devananda: i think this was actually in reference to another case
20:27:15 <mikal> Its relatively common for me to hear that somehting has been discussed in a private company channel and that a subgroup has formed an opinion that way
20:27:30 <devananda> russellb: oh ...
20:27:39 <mikal> devananda: the channel I am disclosing is not the one which caused the complaint (to my knowledge)
20:27:42 <russellb> i'm sure in both cases, the channels were mostly idle, but if you know it exists but aren't there, it becomes a trust issue
20:27:43 <devananda> I'll just settle for being in the dark then
20:27:55 <devananda> russellb: right
20:28:34 * eglynn-afk eglynn
20:28:49 <ttx> does the TC think further action needs to be taken on this ?
20:29:01 <mikal> So, that's kind of where I was going...
20:29:13 <mikal> I think we should make some sort of blanket statement encouraging peopel to work in the open
20:29:13 <anteaya> I think the larger question of how to encourage trust still could use some thought
20:29:14 <russellb> i think our stance on openness is already clear enough
20:29:16 <devananda> mikal: groups of people who work together often form collective opinions, whether that grouping is by-project, by-company, or what ever -- and I think that's normal and acceptable behavior
20:29:21 <russellb> don't see a need for resolution
20:29:22 <mikal> Specifically not use corporate channels to pre-bake ideas
20:29:23 <ttx> There also was an #openstack-social channel -- at some point we realized we started having the wrong discussions on it and we killed it
20:29:27 <russellb> people should just continue calling things out that don't seem right
20:29:30 <ttx> russellb: is that a fair assessment ^ ?
20:29:32 <russellb> let it be culturally enforced
20:29:33 <reed> ttx, I think that a resolution is not necessary
20:29:39 <devananda> russellb: ++
20:29:43 <russellb> ttx: right, and killed it
20:29:49 <mordred> ++
20:29:53 <reed> just a reminder from the TC on the mailing list would be enough
20:29:58 <markmcclain> ++
20:30:04 <ttx> russellb: it's my texbook exampel on why permanent invite-only channels are bad :)
20:30:05 <mordred> also - I think the underlying thing about fostering trust amongst the community is very important
20:30:48 <ttx> Also the whole "core is not special" point needs to be reinforced
20:30:54 <mordred> ++
20:30:55 <ttx> which I think was half of the original thread
20:30:57 <devananda> ++
20:31:01 <markmcclain> +1
20:31:03 <jeblair> i think the project's principals of open development and decision making are already well stated, and i think the end of that thread reinforced many of these things
20:31:08 <sdague> +1
20:31:09 <jeblair> i don't feel like a resolution is _necessary_
20:31:24 <ttx> *if the channel had been about left-handed people I'm pretty sure it would have been less of an issue
20:31:24 <russellb> i wouldn't oppose one if someone feels up to writing one
20:31:33 <annegent_> I think reed's handling of the further investigation helped immensely and is part of resolutions for these concerns when brought to the ML.
20:31:50 <jeblair> reed: however, if you would like a reminder from the tc on the mailing list, in order for the tc to speak, i think we should have a resolution so we can vote on it.  then someone can forward that to the list.
20:31:55 <sdague> honestly, I think the more interesting questions that arose from it were the inconsistencies around logging of project channels, which continues to confuse new contributors
20:32:15 <russellb> yeah, should address that too
20:32:18 <jeblair> sdague: i feel like many folks are thinking we should just blanket-log every channel we know about
20:32:28 <jeblair> perhaps we should take a tc resolution to make that a policy?
20:32:28 <russellb> might be easier to have TC set logging policy than deal with tracking down consensus for every project channel
20:32:36 <russellb> yes :)
20:32:39 <zaneb> in #heat it's announced in the topic that it's logged. do other channels not do the same?
20:32:40 <sdague> yeh, I'm fine with that
20:32:43 <reed> jeblair, I would like to avoid formalities because they end up taking time
20:32:48 <ttx> jeblair: should we address the logging question in the same run ?
20:32:48 <jeblair> then infra can make that happen and perhaps set up appropriate channel announcements, topics, etc.
20:33:08 <ttx> zaneb: I think it's a good thing to have (logging notification in topic)
20:33:18 <markmcclain> consistency there would be a good idea
20:33:22 <jeblair> reed: i think if you want a statement from the tc, we should pass a resolution.  i expect this one to be quick.  :)
20:33:25 <sdague> zaneb: so there are multiple inconsistencies, #1 which channels are logged, #2 which channels tell you they are logged that are
20:33:26 <reed> I feel like there is enough consensus that if ttx or you or anyone from the TC writes a #info here I can use that and close the incident
20:33:40 <zaneb> yeah, I can't think of an excuse not to have it in the topic for all of them
20:33:44 <reed> jeblair, I leave that up to you then
20:33:47 * ttx can't draft anything after 9pm
20:33:56 <zaneb> though I confess that #heat was logged for about 6 months before I noticed
20:34:03 <ttx> zaneb: heh
20:34:11 <devananda> ++ to announcing logging, ++ to enforcing it in all official project channels
20:34:20 <zaneb> luckily I don't think I said anything too outrageous ;)
20:34:20 <ttx> ++ to announce where it's logged too
20:34:21 <reed> sdague, yes, that's another topic I'd like to discuss
20:34:22 <anteaya> devananda: define official
20:34:48 <ttx> anteaya: channels about an official project ?
20:35:00 <russellb> and don't you grant -infra ownership of channels?
20:35:02 <ttx> as in an "openstack project team" ?
20:35:05 <mordred> anteaya: I'd say "ones that are registered with infra as channels?"
20:35:06 <russellb> that seems like an easy trigger
20:35:16 <anteaya> mordred: that one is easier to track
20:35:28 <devananda> anteaya: eg, the project info on LP states "the channel is X" -- or in infra/project-config, there's an infra bot already managing in the channel
20:35:43 <devananda> I think mordred said it better
20:35:45 <ttx> so.. anyone up to propose a text, or should we just draft a resolution off-meeting ?
20:36:00 <sdague> ttx: I think take it off meeting
20:36:03 <devananda> ttx: I feel like a resolution is unnecessary ...
20:36:04 <russellb> off meeting probably ... need to get right definition of what channels are included
20:36:13 <russellb> (for the logging part)
20:36:17 <devananda> ttx: oh, you mean w.r.t. logging. yah, that's fine
20:36:25 <ttx> devananda: two birds one stone ?
20:36:40 <anteaya> two birds in a stone
20:36:41 <jeblair> if we have resolutions for both, let's have two resolutions
20:36:58 <sdague> jeblair: ++
20:37:06 <ttx> jeblair: up for drafting the IRC policy ?
20:37:11 <jeblair> ttx: will do
20:37:13 <sdague> they are related, but separate things.
20:37:28 <ttx> #action jeblair to draft IRC policy resolution
20:37:31 <jeblair> sdague: and they have bikesheds of completely different colors
20:37:49 <mordred> jeblair: can we also discuss the colors of the bikes?
20:37:55 <sdague> but what if I want to store my snowblower in it?
20:38:01 <mordred> ++
20:38:05 <ttx> current issue considered closed, will use a closing email referencing said IRC policy when passed
20:38:07 <russellb> i think all channels should change to proper capitalization of OpenStack
20:38:15 <jeblair> sdague: isn't your snowblower in constant use? :)
20:38:31 <sdague> well... it will be may eventually
20:38:33 <ttx> #topic Definition of the release tags
20:38:40 <ttx> #link https://review.openstack.org/157322
20:38:52 <ttx> this proposal introduces tags to describe the release model that each code repository uses (if any)
20:39:02 <ttx> Those are pretty objective and would be maintained by the release management team
20:39:21 <ttx> mikal: replied to your objection, let me know if it makes sense
20:39:34 <mikal> Yep, I read it just now
20:39:54 <mikal> I do wonder if we should clarify what the meaning of those tags is in the context of defcore
20:39:58 <mikal> Even if its "nothing"
20:40:09 <mikal> Because previously the integrated release was a requirement
20:40:23 <ttx> it is "nothing". defcore may say they would only consider release:common projects for example
20:40:36 <russellb> that detail needs to be worked out
20:40:44 <russellb> there hasn't been anything from defcore to say what is even needed
20:40:45 <ttx> but until the tag exists... they use "integrated-release" as of Kilo
20:40:48 <mikal> Well, haven't they effectively said they want to use release:integrated
20:40:51 <mikal> Which doesn't exist?
20:40:55 <ttx> once we replaced it by series of tags they will pick
20:40:56 <russellb> like, do they want something for separate trademark programs?  just one big group?
20:40:59 <zehicle> o/
20:41:07 <ttx> mikal: exists for kilo
20:41:18 <russellb> mikal: note that defcore also is on icehouse and juno right now
20:41:19 <russellb> not even kilo
20:41:24 <russellb> so we've got some time to sort it
20:41:28 <ttx> anyway, I expect defcore to ask us "what is the list of projects that you think will fit program Y"
20:41:31 <russellb> before "integrated release" doesn't work
20:41:38 <ttx> and we'll have to define a specific tag to answer that
20:41:39 <russellb> ttx: that was my thinking
20:41:40 <mikal> Well, I'm asking in the context of some epople wanting to change the release cycle for nova
20:41:44 <ttx> rather than overloading an existign tag
20:41:46 <zehicle> russellb, FWIW it looks like we're trying to move DefCore away from release ties to date ties
20:41:49 <mikal> And seeking to understand if the defcore process would even allow that
20:41:53 <ttx> otherwise it's integarted-reelase all over again
20:41:58 <mikal> (But not saying I think we should change the nova release cycle if that makes sense)
20:41:59 <russellb> zehicle: ok
20:42:21 <russellb> mikal: i sure hope if it does change, it's still coordinated with a major set of projects ... another topic though i suppose :)
20:42:34 <mikal> Yeah
20:42:48 <ttx> mikal: that's a sane question -- the answer is not in the definition of that tag though
20:42:48 <devananda> zehicle: does defcore have any intrinsic dependency on a project's release cadence?
20:42:53 <mikal> What I want from this bit of the conversation is just a clear statement of if release:coordinated is a requirement for defcore
20:42:56 <zehicle> we're reviewing it tomorrow @ 9 PT
20:42:58 <mikal> But it sounds like I am asking the wrong people
20:43:01 <sdague> mikal: yeh, it feels like that other conversation is a bit premature. Of all the projects to move into release:free state, nova would not be my first pick
20:43:04 <devananda> zehicle: or was it the dependency previously that trademark usage was pinned to integration status?
20:43:04 <ttx> mikal: that's upto defcore, not us
20:43:10 <devananda> *just that ..
20:43:39 <mikal> ttx: I thought defcore was about certifying the contents of the integrated release?
20:43:47 <mikal> ttx: which is a thing the TC has historically designated?
20:43:54 <ttx> mikal: err... no?
20:44:11 <zehicle> sorry - did not mean to distract the agenda.
20:44:13 <ttx> defcore is about what you need to implement to claim a trademark program usage
20:44:22 <annegent_> mikal: capabilities are defined by defcore
20:44:27 <ttx> i.e. what you need to do to call your stuff "openstack Compute powered"
20:44:45 <annegent_> zehicle: I think it's important we all understand
20:44:45 <ttx> they ask us for lists of projects, we provide said list. And they pick within it
20:44:50 <mikal> Sure
20:44:52 <zehicle> we recognize that DefCore is trailing
20:44:56 <mikal> And isn't that list the integrated release?
20:44:56 <russellb> what ttx said
20:44:58 <devananda> ttx: defcore / the board has the responsibility to inform us / the TC of what we can change. ie, we can't remove an integrated project that defcore has already approved w/o their consent
20:45:22 <devananda> ttx: so it would make sense IFF defcore cares about release cadence that they might have some input there. but I don't actually see why defcore would care about that yet.
20:45:25 <ttx> devananda: "remove"
20:45:26 <ttx> ?
20:46:05 <ttx> devananda: I totally agree that defcore needs to take a stance on what release model they would actually consider for theiur trademark programs
20:46:12 <rockyg> Mikal: Defcore is about mature (*cough*), well adopted capabilities within the context of the OpenStack projects
20:46:14 <devananda> ttx: not that we're discussing removing projects, but IIRC that was the only constraint defcore is able to place on the TC's integration (or non-integration) of projects
20:46:18 <ttx> I just think this is orthogonal to the definition of tags
20:46:29 <ttx> which are just an objective description of a curent situation
20:46:40 <mikal> ttx: agreed
20:46:49 <devananda> ttx: so it stands to me to reason that, IFF defcore cares about release cadence, we may both want their input and need to respect their requirements, should they have some
20:46:53 <devananda> however that discussion is really premature
20:46:56 <mikal> ttx: I am happy to handle my question elsewhere
20:46:58 <devananda> because so far they haven't expressed any such requirements
20:47:03 <ttx> but yes, clarifying the various release models makes us realize there is a question that needs to be answered
20:47:15 <devananda> ttx: yup
20:47:19 <ttx> for example, swift would be release:compatible
20:47:26 <ttx> and it never bothered defcore so far
20:47:42 <ttx> release:free ? maybe they would object to that  (I would)
20:47:56 <ttx> I think at the very minimum release:compatible should be required
20:48:02 <ttx> but then, not my decision to make
20:48:12 <ttx> I just want to provide the classification
20:48:19 <ttx> and apply it to projects
20:48:28 <ttx> so that they actually have that information :)
20:48:40 <devananda> ++
20:48:45 <ttx> I'm pretty sure a lot of defcore people didn't even know that swift was different.
20:49:15 <ttx> anyway, we can iterate on the review
20:49:58 <ttx> another hot question, or should we move on ?
20:50:05 <mikal> Move on
20:50:06 <annegent_> I had one
20:50:11 <mikal> Doh, sorry
20:50:21 * ttx reads comments from anne
20:50:30 <annegent_> oh I can keep commenting in the review
20:50:34 <annegent_> s'okay to move on
20:50:48 <ttx> annegent_: as-needed might exclude time-based-however-I-want-it
20:51:19 <mikal> How about "unrestrained"?
20:51:19 <annegent_> ttx: ok, does only the common and compatible tag holders get to pick dates?
20:51:21 <ttx> I felt "free" was more open, as-needed seems to imply "only when necessary", which implied feature-based
20:51:45 <ttx> common = you follow the common cycle, whatever that ends up being
20:52:05 <annegent_> ttx: once you earn a tag, how long do you hold it?
20:52:23 <ttx> annegent_: as long as that project chooses to use that release model
20:52:24 <annegent_> ttx: dates picked by common?
20:52:31 <ttx> This tag is not earned, it's just a factual dedc
20:52:33 <ttx> desc
20:52:44 <annegent_> sure, should have written "apply"
20:52:58 <annegent_> what's the cycling for tag reapplication
20:53:13 <ttx> If mikal tells me he switches nova to release:free and/or tags whenever he wants, tags will switch to release:free
20:53:39 <ttx> annegent_: it changes to reflect the current situation, whenever it changes
20:54:12 <annegent_> ttx: should these details be documented in this patch?
20:54:12 <ttx> it's not a badge, it's more like a box
20:54:27 <annegent_> ttx: it's a sticker :)
20:54:37 <ttx> I think I make it pretty clear that it's a factual tag, but feel free to suggest alternate wording
20:54:38 <devananda> annegent_: one doesnt 'apply for' these tags, and no one needs to vote on their application.
20:54:42 <annegent_> ttx: just making sure I understand
20:54:58 <ttx> annegent_: happy to talk to you off-meeting to clarify isf needed
20:54:58 <devananda> annegent_: sticker could have the connotation of something you earn for meeting a certain criteria, which I dont think is the intent here
20:55:07 * ttx moves on
20:55:13 <ttx> follow-up on review
20:55:17 <ttx> #topic Other governance changes
20:55:19 <annegent_> devananda: badge doesnt?
20:55:20 <ttx> * Add Cinder's os-brick library to cinder (https://review.openstack.org/153673)
20:55:27 <ttx> This one has 7 YES -- not a big fan of the os- prefix but I'm fine to be outnumbered
20:55:37 <ttx> actually 8 YES
20:55:41 <ttx> Approving now unless someone has a last-minute objection
20:55:48 <ttx> * Adding Piet Kruithof as Horizon ATC (https://review.openstack.org/154271)
20:55:50 <annegent_> devananda: ah sorry, nevermind my words are not working :)
20:55:58 <ttx> mikal spotted that Piet is not a Foundation member, which is a requirement to be an ATC (not a requirement to contribute, just a requirement to be an ATC and get a vote)
20:56:07 <devananda> annegent_: np. happy to discuss postmeeting
20:56:12 <mikal> Well he might be
20:56:16 <mikal> But I can't find him
20:56:19 <mikal> We should ask him
20:56:23 <ttx> david-lyle: you mightj want to suggest him to join, or drop the request
20:56:26 <russellb> nice attention to detail :)
20:56:35 <ttx> * Add board-owned openstack/defcore repository (https://review.openstack.org/155738)
20:56:37 <david-lyle> I will track down
20:56:43 <ttx> I'd like 7 YES on this one since it defines the concept of board-owned repositories to mirror the tc-owned ones
20:56:49 <ttx> I think we should encourage the BoD to use git and Gerrit more, so I'm all +1 on this
20:56:50 <mikal> david-lyle: I think him joining would be sufficient for my emotional needfs
20:57:31 <russellb> ttx: +1
20:57:47 <ttx> 6.. one more ?
20:58:04 <ttx> 7, thx
20:58:05 <russellb> otherwise this stuff will live in google docs
20:58:11 <russellb> or private docs
20:58:16 <sdague> yep, gerrit ftw
20:58:16 <ttx> in hell!
20:58:24 <mikal> As long as those docs aren't in a private irc channel...
20:58:28 <russellb> lol
20:58:28 <mikal> :P
20:58:41 <ttx> * Add ironic-lib to Ironic program (https://review.openstack.org/157757)
20:58:46 <ttx> That one still could use some details on how ironic-specific those utilities are
20:58:56 <ttx> to make sure they aren't a better match for Oslo
20:58:59 <mikal> I feel Jim's second argument there is weak
20:59:08 <mikal> But yeah, all I want is some due dilligence there
20:59:27 <devananda> I should follow up between jroll and dhellmann on this
20:59:27 <ttx> so let's keep that one up a bit more
20:59:29 <mikal> Perhaps we could ask dhellmann to take a look?
20:59:31 <ttx> #topic Housekeeping changes
20:59:33 <sdague> yeh, though, honestly this has been a direction tons of projects are headed down
20:59:36 <ttx> * Change TripleO PTL to James Slagle (https://review.openstack.org/157216)
20:59:40 <ttx> ^ obvious repo housekeeping, so I'll approve it now
20:59:46 <ttx> * openstack-spec housekeeping (https://review.openstack.org/#/c/156717/)
20:59:54 <lifeless> ttx: they can always move later, lets not let become too hidebound
20:59:55 <ttx> ^ That one is on openstack-specs, not governance, will approve it now too
20:59:59 <ttx> sceram if you disagree
21:00:00 <sdague> we have keystonemiddleware, ceilometeremiddleware, for instance. Might be nice to name things better the *middlerware or *lib
21:00:10 <ttx> * Build list of teams from YAML file (https://review.openstack.org/125788)
21:00:13 <ttx> There was a nit on boilerplate there, maybe we can fast-fix it
21:00:16 <devananda> sdague: short version is, I think, folks in Ironic just want to iterate on a lib that we use, without the process overhead of oslo, or waiting on oslo-incubator when none of us have core status there
21:00:20 <ttx> Will approve later in the week once that's addressed
21:00:28 <lifeless> sdague: now I want to have a bette-middlerware repo, just because
21:00:32 <ttx> No time for open discussion
21:00:47 <sdague> lifeless: :)
21:00:54 <mordred> lifeless: wins
21:01:00 <sdague> ttx: why do you hate open!?!?!
21:01:03 <sdague> :)
21:01:07 <annegent_> :)
21:01:20 <jeblair> lib is short for liberty, right?
21:01:34 <ttx> ok, closing this one, thx everyone
21:01:36 <ttx> #endmeeting