20:03:22 #startmeeting tc 20:03:22 Meeting started Tue Nov 18 20:03:22 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:26 The meeting name has been set to 'tc' 20:03:27 Our agenda for today: 20:03:30 oh I do have to leave early today 20:03:34 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:40 annegentle: we'll make it quick then :) 20:03:45 #topic Design summit format feedback 20:03:49 How do you think it went ? 20:03:58 +1 would summit again 20:04:03 I'm exploring how we could merge pods / meetups / contributors-oriented sessions on one side... 20:04:09 i heard lots of good feedback about the Friday change 20:04:11 and differentiate from larger rooms / honeypot / scheduled sessions / feedback-wanted sessions on the other 20:04:13 so I'd call that a keeper 20:04:15 honestly, I really liked the friday free form 20:04:21 the extra focus on cross project sessions was good, and I actually got to attend some of the ops sessions this time and found those useful if under-attended 20:04:21 And find a way to limit attendance to the former 20:04:27 +1 on Friday meetups 20:04:32 I liked Friday 20:04:35 getting feedback from the ops on monday was helpful 20:04:36 I should've set up a docs track 20:04:45 I would have liked fewer idle observes in Wed - Thu sessions though 20:04:45 one question is..; should we have Friday every day 20:04:47 i thought the infrastructure/quality assurance/release management conflict-free scheduling was awesome. fewest schedule conflicts for me yet 20:04:51 also, the dev lounge during tues keynotes was super productive 20:05:00 and def +1 to the friday meetups 20:05:04 in parallel with large-room discussions/feedback sessions 20:05:13 ttx: no, organized sessions work well for my people at least 20:05:14 annegentle: +1 20:05:15 ttx: IMO, no. 20:05:24 ttx: having friday every day would make it challenging for those of us who need to participate in multiple tracks 20:05:28 ttx: we do need organized time 20:05:29 ttx: also, Friday worked because the passive observers had left 20:05:30 what dhellmann said 20:05:35 ttx: it wouldn't have scaled to 200 people 20:05:37 ttx no, to hard to find people 20:05:39 the organizers didn't expect tuesday morning dev lounge to be popular, hence the lack of caffeine until afternoon 20:05:46 yeh, the nova track I think benefited from some structure before friday 20:05:47 it's not just about # of people, it's schedule conflicts 20:05:52 ttx: that said, I could see doing it every afternoon instead of just all day one day 20:05:58 #link https://etherpad.openstack.org/p/kilo-summit-feedback 20:06:02 mikal: ++ 20:06:11 knowing when to be where to hit specific topics is useful on the super busy days 20:06:25 russellb: exactly 20:06:26 just not sure we could do a morning/afternoon split 20:06:34 only because of space constraints 20:06:35 I also think Free form works a lot better on the last day 20:06:42 but for any day where there's no major overlap, +1 to free form 20:06:43 sdague: ++ 20:06:45 because lots of lurkers leave 20:06:47 markmcclain: good point 20:06:52 sdague: ++ 20:06:57 for me it is a brain change, it work best for one whole day 20:06:58 so my idea of running honeypot visible sessions in parallel to more private team workshops is not worthb being pursued ? 20:07:11 you'd rather keep it the way it is ? 20:07:23 ttx: honestly, I think the balance here was pretty solid 20:07:27 not sure we can scale "the way it is" in big-tent mode though 20:07:29 ttx: I'm not sure I like the idea of a honeypot for this. Feels like the wrong attitude. 20:07:36 ttx: you willing to lead the nfv, lbaas, scheduling session? :) 20:07:41 what did you all think of the cross-project sessions, effective? 20:07:49 markmcclain: also containers 20:07:49 the # of lurkers on thursday was a bit startling to me. it felt like more than half didn't have ATC badges 20:08:04 devananda: yes, half by my count too 20:08:08 sdague: good call that should be included too 20:08:10 annegentle: I thought they were good, but conflicted with a lot of conference tracks 20:08:29 tuesday was the most conflicted day for me, but I may be the minority there 20:08:32 ttx: in Vancouver will the main conference run for 3 or 4 days? or don't we know yet? 20:08:38 devananda: same here 20:08:41 devananda: I'm surprised that you still try to get to conference talks. I had to give those up entirely a few summits ago. 20:08:47 don't know yet, I think 4 20:08:48 devananda: it was crowded thursday, but otherwise I didn't have any issues with non-atcs. Were there problems? 20:09:01 * jaypipes would have preferred to see half the number of sessions, but longer, more action-oriented sessions... 20:09:06 customer meetings were all first half of the week, on the main/full/keynote days 20:09:09 i don;t recall attending conference tracks for at least the last several summits, so the cross-project sessions were quite helpful from my perspective 20:09:11 sdague: there are some summit sessions that cover interesting ground 20:09:14 sdague: I did, except I spoke this time around 20:09:28 markmcclain: I'm not saying they aren't interesting 20:09:30 but yeah, lots of really good main conf sessions too 20:09:31 sdague: I stopped trying to give main conference talks a while back ... 20:09:32 dhellmann: yeah, I made the mistake of doing 4 conference sessions. 20:09:36 and we ahve videos up ~ the next day 20:09:46 I'm just saying there is so much conflict... just had to give up that access 20:09:47 jaypipes: wow, you're a glutton :-) 20:09:52 yeah.. :( 20:09:53 ttx: yeah the videos make it easier to defer summit watching time until later 20:09:54 to me, it seems like a failure in our scheduling if the key dev/tc folks can't participate in the conference 20:09:57 yeah I did 3. Silly me. 20:10:09 did 1, that's manageable 20:10:20 on the other hand, I might be failing and trying to do too much ... :) 20:10:43 devananda: that I do agree with.. many conf attendees do want to see/interact with those leading the projects 20:10:48 devananda: the offset was supposed to help with that, but with ops on the offset day, it's another conflict 20:11:01 I wonder if that led to some of the extra folks we had around on Thursday 20:11:06 ok, if you have more feedback, don't hesitate to send me something. I'm in brainstorming mode for the next one. 20:11:12 o/ 20:11:16 I take the general feedback as "was good, do it again" 20:11:25 ttx: ++ 20:11:27 ttx: do you already have a note to schedule something on the ski slopes next time? 20:11:27 ttx: ++ 20:11:29 it really was a great one 20:11:33 dhellmann: ++ 20:11:34 ttx: more whiteboards! 20:11:42 even more whiteboards. 20:11:46 i think mondays are proof that any time we expose a hole in the schedule, some part of our community will fill it 20:11:53 fungi: ++ 20:11:54 fungi: true 20:12:05 #topic TC feedback on proposed bylaws changes 20:12:08 also, random personal note -- arriving 5 days ahead of the conference made things sooo much easier 20:12:16 #link http://lists.openstack.org/pipermail/openstack-tc/2014-November/000871.html 20:12:27 The proposed change is essentially what was described to us during the joint board/TC meeting in Paris 20:12:31 ttx: serious note, we should try to schedule a tc meeting at the next one. Not just the joint thing with the board. 20:12:40 dhellmann: good idea 20:12:42 dhellmann: noted 20:12:53 dhellmann: as long as it doesn't extend the conf another day ... 20:12:57 some people suggested a PTL-only best-practice-sharing session too 20:13:09 russellb: no, we could do it at lunch or something 20:13:11 ttx: ++ 20:13:11 bylwas: I still wish it would just remove much more detail to let us be more flexible in the future 20:13:13 devananda: ++ 20:13:16 honestly those could be between summits on video chat 20:13:29 but yes, PTLs would really benefit 20:13:31 bylaws: But I think we can make it work 20:13:47 As far as bigtent is concerned, the most annoying part of the proposed change would be the "TC approved release" terminology for designating the superset of projects the board can pick from 20:13:55 ttx: i wish the changes were in a proper patch series, instead of one big patch :-p 20:13:55 ttx: which of the 6 dropbox files are we looking at? 20:13:59 I think that if there are multiple trademark programs, we may want to have multiple, distinct TC approved supersets 20:14:06 I'll definitely say I don't like the substitution wording for "integrated" 20:14:12 the largest of the redline is probably the most useful 20:14:17 sdague: ^ 20:14:22 That said, the current wording allows us to play with words: 20:14:28 << The Technical Committee shall designate a subset of the OpenStack Project an �OpenStack TC Approved Release� from time to time >> 20:14:36 Nothing says that �OpenStack TC Approved Release� is unique :) 20:14:55 I do like the flexibility 20:15:03 I am not keen on codifying the notion of a single release 20:15:11 so I think we can make the proposed wording work 20:15:22 ttx: yeh, seems better than current 20:15:27 ttx: it sounds like that might be the thing that our horizontal teams agree to work on, or something totally different -- and the TC gets to choose. 20:15:29 jogo: I didn't read it as a single release as much as a single set of things we would want to apply the trademark to (vs. those we wouldn't) 20:15:50 dhellmann: perhaps 20:16:01 yes, I think the new wording is fuzzy enough to give us some legroom for future change, while being compatible with current situation 20:16:08 so I'm not sure it's worth us objecting to the proposed wording 20:16:12 I think the important point is to give it enough flexibility that we feel like we can honestly provide some interpretation as things change 20:16:31 because we're definitely in odd binds with current bylaws being way too specific 20:17:06 the thing whcih stands out to me: trademark-designated things can only be removed from that grouping with board's consent. Which, honestly, doesn't seem bad to me 20:17:14 sdague: I fought to remove more from it, so that less is written in immutable stone, but wasn't more successful than that 20:17:20 I'd like to see a draft of the separate rules for adding/removing projects from the trademark set 20:17:21 well it shouldn't use the TC acronym for one. I'd at least prefer that point of clarity 20:17:30 ttx: I can live with that 20:17:34 devananda: actually, that's not exact 20:17:42 they could change it to TCup or something. Seems sloppy in a legal doc 20:17:48 annegentle: yeah, I thought the use of the abbreviation there was odd, too 20:17:50 "trademark-designated things can only be removed from that grouping by following a procedure" 20:17:58 annegentle: TCup sounds too much like teacup 20:18:02 dhellmann: heh, we're the word nerds :) 20:18:06 devananda: procedure which remains to be defined and updated, outside the bylaws 20:18:09 mordred: it's tempest in a teacup 20:18:13 ttx: I see 20:18:22 deva__: this is actually much more flexible 20:18:23 anyway my point is, no TC, spell out Technical Committee 20:18:32 then "approved" -- what does that mean? Voted upon? tested? 20:18:33 annegentle: yeh, that's valid 20:18:34 annegentle: we need t-shirts 20:18:39 heh 20:18:51 the proposed changes, remove the non commercial trademark clause. so the board can change non commercial usage at will now 20:19:00 Anyway, if you have further feedback, please send it to the -tc list or directly to Mark Radcliffe 20:19:06 that scares me 20:19:18 jogo: what section is that? 20:19:24 * dhellmann is having a hard time reading this redline 20:19:28 Appendix 8, 1.1 20:19:30 annegentle: I think approved should be vague on purpose, because the criteria for that has adjusted over time, and may in the future 20:19:31 jogo: I think we retain the definition of "the OpenStack project" 20:19:37 sdague: ok 20:19:46 which is arguably a default trademark use case 20:19:52 I'll send my input to the openstack-tc ML 20:20:08 sdague: ++ 20:20:20 sdague: I like that the criteria is de facto "whatever the TC says" 20:20:22 annegentle: because we don't really want to build a quorum of people that sign up to the foundation website to vote to about details of what our release process is 20:20:35 jogo: but you're right in saying that by dropping trademark policy from the bylaws (a good change) we throw the baby with the bath water 20:20:55 the baby being the community usage of the trademark 20:20:59 ttx: as an individual member I will be voting against these changes as is 20:21:20 ttx: because don't throw out the baby 20:21:24 jogo: which means you are voting for OpenStack being defined as Swift and Nova? 20:21:29 that doesn't "scare" me because I don't see them going against the TC for its usage of the trademark (or rather, I'd like to see them try) 20:21:43 yeah I think that "determined by Technical Committee" is fair and flexible, both of which we want 20:21:47 but that's a valid remark 20:21:48 sdague: that is not the current definition actually 20:21:55 jogo: it really is 20:22:13 jogo: but I support you in your ability to vote no 20:22:21 because democracy! 20:22:49 mordred: that is what the existing commercial trademarks are around the ones that are in the bylaws not the ones outside of them 20:23:21 #info jogo says it would be better if we could keep the community right to use the trademark in the bylaws 20:23:28 ttx: I don't imagine the board removing the non commercial usage, but then why remove that clause? 20:23:45 ttx: and in a place that needs a general vote to change 20:23:46 jogo: they remogve all the trademark policy from the bylwas, to be able to change it more often ? 20:24:01 ttx: so remove all but non commercial 20:24:05 right, that was my understanding, was they moved the whole thing to a separate document 20:24:16 I think at the end of the day we have to have bylaws that assume good intent, because if we build bylaws as assuming bad actors we just crustify ourselves into a place where we get stuck by the bylaws from evolving the community the ways the community wants to evolve 20:24:39 sdague: I think I agree with that 20:24:50 sdague: is assume good intent a legal concept? because that is what this is about 20:24:51 so a university or public/govt cloud wants to say they run an OpenStack cloud. Does anything in this revision prevent that? 20:25:35 jogo: I'll send that feedback -- maybe it's possible to now throw the baby with the bath water 20:25:46 jogo: it's assume that the board isn't the enemy of the community, and that we safe guard not through specific protections in the bylaws but by frank communication with the board about what we think is important 20:25:49 jogo: he's saying we need to assume the board has good intent 20:26:01 ttx: thanks, I haven't read the entire change, but when I do I will respond to your thread 20:26:15 and knowing a bunch of board members, many that are TC members as well, I feel pretty comfortable with that 20:26:31 annegentle: because the univ and govt are non-commercial? 20:26:39 OK, let's move on... 20:26:47 ttx: if not there, where are the trademark terms being moved to? this deletion covers more than just the commercial or individual use of the product 20:26:50 if you have further remarks, reply to thread 20:26:53 bah. nvm :) 20:27:01 dhellmann: yes, best examlpe I could think of off the top of my head 20:27:11 jogo: thanks for pointing that out -- i now share your concern 20:27:21 jogo: or at least have a similar one 20:27:23 annegentle: good example, but I think they'd be covered by using community code or a commercial distro 20:27:31 devananda: there be dragons in by laws 20:27:32 #topic Housekeeping changes 20:27:43 There are 3 housekeeping changes in the pipe -- I'll approve them post-meeting unless you object to them now 20:27:48 * Trove is using trove-specs for blueprints and specs (https://review.openstack.org/133363) 20:27:52 * Update Zaqar's PTL information (https://review.openstack.org/134073) 20:27:57 * Add oslo.context to the Oslo program (https://review.openstack.org/#/c/135094/) 20:28:19 if you object, post a -1 there to block fast-track 20:28:23 #topic Stalled changes 20:28:32 so, I think I've said this before. But can we assume fast approve on these in the future, and just let people propose a revert if they don't like it? 20:28:33 We have two stalled changes (both proposed by mordred) in the pipe: 20:28:41 * mordred spews fire 20:28:42 hmm, Zaqar is not the only project with out-od-date PTL information 20:28:43 ttx: could we get an election official to certify the zaqar ptl change, as a matter of process? 20:28:57 anteaya: ^^ 20:29:06 zaneb: are there other patches? 20:29:16 zaneb: care to fix? :) 20:29:23 sure 20:29:25 would it be better to have the election official(s) propose PTL changes to the gov repo, as a matter of course? 20:29:33 sdague: I haven't looked, I just know I'm not the Heat PTL any more ;) 20:29:34 devananda: +1 20:29:36 devananda: that's not a terrible idea 20:29:38 devananda: that seems sensible to me 20:29:38 devananda: ++ 20:29:41 I hear sdague arguing for more discretion to the chair, and dhellmann arguing for less 20:29:55 ttx: I think the chair should have both more and less discretion 20:30:01 ttx: depending on whether I agree with him or not 20:30:05 I'll try to continue doing grey 20:30:11 ttx: I just don't want to have to go find the election results myself. If anteaya says +1 then I'm OK with you approving it. 20:30:23 mordred: well it's tracked, and it's revertable, so more discretion seems fine 20:30:37 do we all agree that I should have approved all those without bothering you with them ? 20:30:40 #undo 20:30:41 Removing item from minutes: 20:30:41 we can flog the chair if it turns out he/she becomes a bad actor 20:30:54 it's not like we won't have a public record of it 20:31:00 I'm fine either way :) 20:31:06 I don't see any reason for us to rush approvals on things like election results. The others I'm OK with. 20:31:18 dhellmann: ok. 20:31:20 WOAH the meeting bot can undo things 20:31:31 ttx: you just removed a topic from the meeting minutes 20:31:34 it's an awesome feature, yes 20:31:34 mordred: you still have a lot to learn! 20:31:36 dhellmann: +1 with link to results 20:31:42 * mordred mind blown 20:31:44 w 20:31:47 anteaya: thank you 20:31:49 we're topicless? 20:31:52 ok, let'(s move on :) 20:31:53 #topic Stalled changes 20:32:09 annegentle: it will all work fine in the end 20:32:13 We have two stalled changes (both proposed by mordred) in the pipe: 20:32:16 * Remove support for vendor extensions from our code (https://review.openstack.org/122968) 20:32:18 * Add a docs environment to the testing interface (https://review.openstack.org/119875) 20:32:20 o/ sorry guys forgot that dst hit while i was in europe 20:32:21 mordred: what are your plans for those ? 20:32:46 I'll propose the out of date ptl changes 20:32:48 should we mark them abandoned until you feel strongly enough about them to revive them 20:32:54 ? 20:32:58 anteaya: thx 20:33:11 #action anteaya to propose "official" PTL changes 20:33:18 ttx: docs interface was all about jeblair's concern, and I don't remember where we got to on that 20:33:21 ttx: I thought we agreed we didn't want the docs environment change? 20:33:36 dhellmann: we did, but mordred wans't around? 20:33:37 or maybe to reword it as optional but not the way the CI system would run 20:33:48 ah. if we did, I can abondon that one then 20:34:10 mordred: no, see my comment from 22 oct -- "we're saying that this specific interface ... is optional" 20:34:11 for the vendor one, I need to read and respond to comments, sorry I have not done that yet 20:34:17 so I think we wanted a reword on that one 20:34:22 k. let me deal with review commends on both 20:34:31 which is easier when I'm not drinking in argentina 20:34:32 mordred: so.. abandon the docs one, keep the other open ? 20:34:40 ttx: let me deal with both 20:34:44 Ill do that this week 20:34:48 famous last words 20:34:54 * mordred stabs ttx with a wet cat 20:35:04 ouch!ouch! 20:35:26 * ttx distracts mordred by switching topic again 20:35:31 #topic Next steps in project structure reform 20:35:45 We need to make progress on this. I invite all members to start smallgroup discussions with their TC peers to seek alignment, as suggested by markmcclain in Paris 20:35:52 We had a hangout last week with Anne, Sean, Devananda and Mark last week, notes here: 20:35:56 wasn't it markmc ? 20:35:59 We don't want to schedule speed dating? 20:36:04 can we have another one this week? 20:36:07 You want people to self organize? 20:36:07 https://etherpad.openstack.org/p/project-restructure-hangouts 20:36:21 mikal, you and me. we're the starting set 20:36:27 annegentle: if we do, please post when it will be to the tc ML so I can participate 20:36:32 I'm fine with not attending every single one of them. Will organize a new one for this week though 20:36:37 26 hours from now perhaps? 20:36:40 Sidenote: jeblair doesn't really want us to standardize on Google hangout for those, I guess smallgroups should pick whatever works best for them 20:36:54 if you use asterisk we can record them 20:37:01 During past week discussion there was strong convergence on the idea of a base compute projectgroup 20:37:07 the sip app has a recording feature 20:37:08 There was much less convergence on barriers to entry into the big tent (some people want none, some people want a basic "are you one of us" check, some people want a stronger "are you useful" assessment) 20:37:25 anteaya: I'm not sure recording was the goal 20:37:29 Personally, I now see how horizontal teams can survive the big tent (by resetting expectations of support for all" openstack" projects) 20:37:33 sorry, you don't have to either 20:37:34 as it was more about letting people think out loud 20:37:37 yeah please not recorded for these 20:37:40 I still need to work on solutions for the design summit and trademark checks 20:37:50 it's for thinking with words that aren't written down 20:37:55 I reached out to the Foundation staff in charge of those trademark checks, to see what could work for us there 20:38:16 it's mostly an etherpad with a parallel unrecorded chat 20:38:30 ttx: I'm a little uncomfortable with us saying it is ok for cross-project groups to only deal with the compute group of projects 20:38:37 but like I said, we can use whatever works for the people meetings 20:38:48 ttx: fwiw, i thought that format worked just fine for an informal, unrecorded, idea-sharing session 20:38:49 dhellmann: that is not what we say 20:39:05 ttx: ok, I guess I need that clarified then because that's what I keep reading 20:39:07 devananda: I'll let you fight jeblair when he is back 20:39:18 :) 20:39:18 devananda: you can also fight me on it now if you like ;) 20:39:24 dhellmann: we say that the cross-project teams should pick what they support 20:39:39 ttx: ok, that feels equivalent 20:39:42 and no longer HAVE TO support the whole "integrated release 20:39:50 * devananda sharpens his wet noodle in preparation to fight with fungi 20:40:03 I'll pick on annegentle and say we shouldn't have *a* documentation team if they aren't going to support everyone in some way 20:40:09 dhellmann: currently we have tension because the TC adds stuff, and the horizontal teams HAVE TO support them all 20:40:16 reading scrollback: just a little note about the bylaws changes. The reason things like Trademark are being pulled is that it is extremely difficult to make bylaws changes because a huge percentage of our membership doesn’t vote. We need to get stuff that we are iterating on (like trademark policy) out of the bylaws so that we can change it. There is a very real chance we can’t pass even this bylaws change because we d 20:40:17 get enough votes. We want to prevent that in the future. 20:40:25 dhellmann: if support is "reviews and automation tooling" 20:40:34 annegentle: yes, that would be enough in my mind 20:40:40 is it really "allowing" cross-project teams to determine their scope, or merely acknowledging that this is what they actually do anyway? 20:40:55 fungi: I think it's putting a stamp on what is actually happening now 20:40:56 it seemed to me that there was agreement that cross-project teams (like docs) should produce tools and advice, and may choose what projects to directly support with those tools 20:41:02 dhellmann: the change says: there is no expectation of direct support anymore. Horizontal teams help everyone, but do not have to directly handle more than they can support 20:41:03 annegentle: but that's more than "choosing which projects to support", which gives you the option of, for example, not describing how to install something in the install guide 20:41:07 annegentle: dhellmann right, that's what i would expect ... horizontal teams empowering projects to get that task done with tools/etc 20:41:11 /n 20:41:20 it's still a tough sell to a common docs team member, "Hey how about you keep an eye on these 20+ repos to see if any changes affect docs" 20:41:32 russellb: empowering is a good term 20:41:34 so reviews are tough 20:41:40 dhellmann: I suspect that's because we have differing ideas of what "supporting" means 20:41:48 dhellmann: so I think that's the you can't have it both ways thing 20:41:50 russellb: ++ 20:41:50 annegentle: no, that's not what I'm saying -- it's up to the projects to come to you with those changes 20:41:52 we provide tools and advice for everyone, for sure 20:41:52 but yes, the idea is to hand over the centralization 20:41:59 devananda: sorry, stepped away for a sec 20:42:04 more self-service, bring your own writers/words 20:42:05 empowering requires a hefty use of the word no 20:42:08 devananda: google hangouts exclude some of teh TC from participating 20:42:14 devananda: which is very rude 20:42:18 doesn't hangouts also limit the number of participants 20:42:21 which is also rude 20:42:22 heh anteaya well dhellmann was trying to help define what the no could be 20:42:32 * russellb can provide a google-hangout equivalent that's entirely peer-to-peer 20:42:36 and no account required 20:42:48 as long as it doesn't require people to install non-free software 20:42:53 right, annegentle and her team should not have to write everything but I don't like that they could possibly turn away a project who does want to come contribute (not that I think they would) 20:42:56 just a webrtc capable browser 20:42:59 then we have to use it, whatever the defition is 20:43:01 mordred: Ididn't say we should only use hangouts :) none the less, I personally found the format acceptable 20:43:04 clarkb: beyond 4 or 5 it's not really a discussion anyway 20:43:04 webrtc ftw 20:43:05 beause that is a non-starter for a non-zero number of our members 20:43:07 and no tends not to be popular 20:43:23 russellb: ++ for rtc solution 20:43:24 mordred: and none of those members had expressed an interest in that particular meeting time 20:43:25 and back to policy 20:43:31 devananda: sure. just saying 20:43:35 mordred: sure 20:44:01 russellb: I'll take your webrtc solution 20:44:05 xlnt 20:44:16 i can give folks info out-of-band 20:44:18 dhellmann: I think we are on the same page actually 20:44:20 russellb: if you could post instructions somewhere, that would be great 20:44:22 russellb: that looks like a typo, is it the name of some app? 20:44:28 * mordred embraces all of russellb's solutions 20:44:30 * ttx puts dhellmann on the next brainwashing group 20:44:34 ttx: ok, maybe it's a phrasing issue 20:44:42 dhellmann: which looked like a typo? 20:44:43 dhellmann: example with release management 20:44:47 xlnt? 20:44:54 oh, no ... excellent 20:45:00 oh, heh 20:45:22 gotta go, will catch up online 20:45:28 dhellmann: We would provide tools for everyone, and define process. But we would only actually push tags and guarantee a common release on the same day for a subset of projects, not all the big tent. 20:45:29 * dhellmann thought it was some x11 app 20:45:36 nah :) 20:45:43 ttx: sure, that's what I do within oslo, too :-) 20:45:57 ttx: ok, I think we're closer to agreement that I feared 20:46:09 dhellmann: "support" is confusing since it applies to both cases 20:46:13 right 20:46:17 dhellmann: I do think the install guide is a good example though. Is the docs team empowered to build the base install guide that they think provides the crispest user experience, or do we need a giant choose your own adventure that includes any projects that comes forward. We do have to give some trust to horizontal teams to do sensible things for the users. 20:46:23 I prefer "directly handle" vs. "empowering" 20:46:32 I think in one of these patches I had "provide tools and guidance" instead of "supports" 20:46:45 horizontal teams empower everyone in the big tent, and may opt to directly handle a few 20:46:53 +1 20:47:06 ttx: yep, I think that's solid 20:47:12 sdague: sure, I would expect some choices, but if the project doesn't go in "the" install guide, then they need to make it possible to have other guides where the info can land 20:47:25 dhellmann: sure 20:47:27 rather than "horizontal teams have to directly handle everyone in the tent (so better keep it small)" 20:47:34 I think that's the empowering bit 20:47:51 just as infra doesn't ask too many questions about the suitability of a project when we add it, I don't think the other cross project teams should be in a position of vetoing another team's goals 20:48:19 ++ 20:48:20 sdague: right, it just wasn't clear from some of the other phrasing that "empowering" was actually the goal 20:48:36 so what about the limits to the big tent... who is for "no barrier at all", who is for "are you one of us" basic checks, who is for "are you actually useful" checks 20:48:46 I'm for "are you one of us" 20:48:48 dhellmann: right, I think we're agreed. As long as they have a way that Docs content from one of these projects has a place to live, and a way to be found, even if not in the main install guide, that's the goal 20:48:50 because otherwise we're just github 20:49:02 sdague: ++ 20:49:11 I know annegentle was leaning towards "are you actually useful" to avoid 30 different chef recipes repos 20:49:21 well - I think "are you one of us" 20:49:22 yeah, we need some sort of community sense at least 20:49:29 mordred: right. 1 = github. 3 = TC making a quality-assessment. 20:49:32 "are you one of us" is pretty nebulous 20:49:36 I think useful is important 20:49:38 * ttx thinks we at the very least need "are you one of us" (mission and 4 opens check) 20:49:39 impplies that you're willing to listen to the TC when we tell you to work with the other chef repos 20:49:44 got more specifics about one of us/ 20:49:45 ? 20:49:51 if we're going to support competition, I don't see how we can object to some competition and allow others 20:49:58 dhellmann: ++ 20:49:59 * jaypipes is for "are you one of us". 20:50:09 mordred, jaypipes ++ 20:50:09 if I am going to spend time on something I wuold at least like to feel it is useful 20:50:12 I'm not sure I entirely like that, but there it is 20:50:15 sdague: at least vaguely part of the openstack mission, and following the 4 opens 20:50:27 as in "are you aligned with the OpenStack mission", but not "are you a member of The Cabal" 20:50:27 gabba gabba hey gabba we accept you we accept you, gabba gabba hey gabba we accept you one of us! 20:50:33 ttx: "4 opens"? 20:50:37 because I'd like whatever definition to be crisp enough that project-config reviewers have the guidance to approve these without TC voting on everyone 20:50:39 * dhellmann feels slow today and blames the cold 20:50:43 sdague: ++ 20:50:45 dhellmann: open development, community, design, source 20:50:49 k 20:50:52 sdague: ++ 20:50:54 dhellmann: ++ to the 4 opens. I added that to my governance patch. 20:50:54 sdague: ++ 20:51:25 sdague: actaully I'd like us to delegate that tyo some community council 20:51:34 ttx: ++ to the 4 opens, I like those. 20:51:37 also that's one of the ways we can keep the load on the infra team and systems from going beyond absurd into ludicrous 20:51:50 ttx delegate what? 20:51:51 ++ 20:52:12 A community council could check for "are you one of us", the same way they could vet openstack-planet additions or openstack meeting schedule requests 20:52:14 if we don't have a clear direction coming out of this for how to approave a new repo patch, what is the point? 20:52:18 anteaya: the "are you in openstack/ code namespace" decision 20:52:26 (shameless plug for the gerrit-powered-agenda) 20:52:30 s/are you/can you be/ 20:52:36 I think the test should aim to provide mutual benefit. So projects that we can contribute something to other than the "OpenStack" name, and which will contribute something back too 20:52:36 I thought that's what this was 20:53:10 ok, so it feels like there is at least growing consensus for a "are you one of us" barrier 20:53:20 a committee has to apply criteria for every repo? that is going to slow things down 20:53:48 anteaya: no, I think the TC wants to not be involved in every repo 20:53:57 mordred: ++ 20:53:58 great 20:54:05 we create at least one per day 20:54:09 mordred: right, but ttx said a different committee would be 20:54:12 I still need to work out a solution for trademark checks, I know openstack/* makes some worried 20:54:19 so one committee to decide who's in the community and another to decide the direction? seems like that could get out of sync quickly 20:54:21 sdague: I did not see that 20:54:25 that community council would have a delegation from the TC 20:54:26 so whatever the outcome we need to be able to apply criteria and approve patches 20:54:27 I do not agree with that 20:54:38 david-lyle: ++ 20:54:52 sdague: actaully I'd like us to delegate that tyo some community council 20:54:55 it seems like if we don't have an idea of if you're one of us enough that anteaya can apply it, we don't know what we're actually talking about 20:54:58 we should probably also require the cla and apache license 20:54:58 david-lyle: it's not a separate committee 20:55:11 david-lyle: it's a delegation so that we don't rely on TC members for everything 20:55:16 mordred: thanks for hearing me 20:55:20 vishy: good point 20:55:26 ttx: so a subset of the TC? 20:55:29 vishy: actually had some chats about opening up on the apache license part in the "one of us" section 20:55:41 dhellmann: i thought your wording already required CLA and Apache license 20:55:45 apache license is only really important if we're intending on your code being something we release 20:55:47 vishy: my proposal specifically lists the license and the DCO as requirements. 20:55:48 vishy: right, agreed, things like that are crisp and delegatable 20:55:56 devananda: I know it does the license, I don't remember about the cla 20:55:58 * mordred EXPLCITLY opposes codifying apache license 20:56:02 we definitely already include code under compatible licenses which are not exactly apache 20:56:03 david-lyle: or a group of people that we would delegate autrhority to (but we would still have oversight on) 20:56:07 mordred: i think both the cla and apache license is important for company contributions 20:56:08 because it will make life hell for infra 20:56:08 devananda: the smaller change probably does, since that's there now 20:56:09 no 20:56:19 mordred: oh, right 20:56:20 there are things infra does that have uptreams 20:56:22 one of the ideas of the big tent is to make it easier for companies to put people on it 20:56:33 but I guarantee that work is done as part of openstack and is one of us 20:56:35 mordred: don't the bylaws say we have to use the apache license? 20:56:43 mordred: but that is not openstack stuff 20:56:44 dhellmann: not the new bylaws 20:56:45 dhellmann: for what we release 20:56:46 dhellmann: only for code we release as openstack 20:56:48 if it is upstreamed 20:56:51 it is upstream 20:56:54 ok, sure 20:56:55 vishy: for example 20:57:07 we would like to rewrite the irc bots using a framework that is GPL 20:57:09 ok, so I think the license thing can probably be detailed out out of band 20:57:11 the bot code will be openstack-infra code 20:57:14 mordred: current idea is to require "open source", and only require apache on the "open,stack TC approved release" stuff 20:57:27 ttx: yes 20:57:31 yeah, I think we can make that distinction easily 20:57:32 ttx: ok i’m good with that 20:57:32 ttx: that would be fine 20:57:35 mordred: wait. infra isn't under openstack/* 20:57:44 ttx: ++ 20:57:45 devananda: sure. I just want to be very clear with our wording 20:57:53 so taht we don't accidentally say somethin gwe don't mean 20:57:57 devananda: it would still be part of "the openstack project" 20:58:00 yaj 20:58:02 mordred: if we're ONLY saying this stuff applies to openstack/* then I actually don't see the problem 20:58:02 yah 20:58:05 mordred: yeh, I think we're still reasonable humans mostly 20:58:13 sdague: yes. I believe we all are 20:58:15 I mean 20:58:16 openstack-*/* is different 20:58:17 except me 20:58:19 OK, we are running out of time. 20:58:29 devananda: not necesarily 20:58:50 ok back 20:58:57 the openstack-* spaces all have reasons for being, only certian repos can go in there 20:58:58 I'll follow up to get a few of you in a meeting later this week, for a smallergroup chat 20:59:08 we'll put notes on the same etherpad 20:59:28 I'm under the impression we are mostly agreeing, just nee dto talk more about it to make sure we agree on the same thing 20:59:36 #topic Open discussion 20:59:40 Anything else, anyone ? 20:59:44 annegentle and I will discuss midcycle meetups during the next meeting, you can tag along 20:59:56 spoiler: they are evil! 21:00:00 a while back, I had started suggesting that we create more top level things, like openstack-ops/*, rather than add all the chef things to openstack/ 21:00:06 hahaha 21:00:17 just a heads up that the DefCore/Refstack team is working on defining capability groups for Icehouse and will need review/help 21:00:17 devananda: ++ 21:00:24 then I forgot to bring that up again for a while 21:00:32 #info DefCore/Refstack team is working on defining capability groups for Icehouse and will need review/help 21:00:39 thanks 21:00:42 but I think that might make some of the lines about "are you one of us" clearer by having clearer buckets of "us-ness" 21:00:58 #action ttx to set up new smallgroup meting to progress on converging toward a clear proposal on bigtent 21:01:00 devananda: oooo, taxonomy :-) 21:01:03 your us-ity 21:01:16 ttx: Wanted to give everyone a warning that I will be starting a thread on the ML to split Neutron into two repos with seperate core teams 21:01:24 markmcclain: ++ 21:01:24 markmcclain: +3 21:01:31 markmcclain: ++ 21:01:32 markmcclain: split how? 21:01:34 markmcclain: this for the advanced services split? 21:01:36 #info upcopming thread on the ML to split Neutron into two repos with seperate core teams 21:01:40 russellb: yes 21:01:45 separate from the driver split.. 21:01:46 k 21:01:48 ok, time is up 21:01:54 #endmeeting