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