20:01:47 #startmeeting tc 20:01:48 Meeting started Tue Sep 29 20:01:47 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:52 The meeting name has been set to 'tc' 20:01:56 Our (busy) agenda for today: 20:02:01 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:05 * ruagair lurks 20:02:09 I reorganized it a bit so that easier topics can be cleared fast 20:02:17 and because the Kosmos decision might affect other decisions 20:02:24 #topic Adds OpenStack UX core reviewers to extra-atcs 20:02:29 #link https://review.openstack.org/224923 20:02:34 4 names proposed, all Foundation members. 20:02:45 Piet, Eric and Ju Lim are actually already ATCs for their contribution to other projects 20:03:02 still missing a few votes 20:03:04 objections? 20:03:09 ttx I put them in the patch because I couldn't confirm that when I wrote it 20:03:20 This is really about Michael Hinnant who doesn't have ATC status. However, he has been very active providing reviews. 20:03:33 none that I see, I think we should just let votes accumulate and move on 20:03:44 ok, will approve when it reaches 7 20:03:45 ttx: has 7 now 20:03:49 can they still be added to the tc election roll? 20:03:54 alright then, approved 20:04:00 Sweet! 20:04:04 anteaya: no, we tagged it 20:04:09 okay thanks 20:04:20 #topic Formal vulnerability:managed application criteria 20:04:24 #link https://review.openstack.org/226869 20:04:30 The previous version of this was basically saying "whatever the VMT is comfortable with" 20:04:38 This version is just them actually detailing what they are comfortable with, so ++ 20:04:55 ++ 20:04:58 * dhellmann likes that we are writing things down 20:05:10 objections ? Otherwise will approve when it reaches 7 votes 20:05:12 me too 20:05:13 ++ 20:05:15 yep, this seems pretty concrete 20:05:42 has 5 so far.. 20:05:53 lets move on, will approve async 20:05:59 #topic Add new project Kosmos 20:06:06 #link https://review.openstack.org/223674 20:06:13 Last week we deferred the decision on this one 20:06:24 since it may affect the decision on latter topics I moved it up 20:06:25 * russellb is fine with it, but would rather be approving with clear consensus 20:06:31 The project and the project teams are sane, the question is more whether we should generally require "some" work to be done before approving project teams 20:06:37 We generally require that of completely-new project teams (see for example kiloeyes) 20:06:41 personally I'm fine with this, however I don't think we should force it if people are against it 20:06:43 and there doesn't seem to be clear consensus, so i'm also happy saying "go do your thing for a bit first" 20:06:44 We didn't require it for the packaging initiatives (packaging-deb, packaging-rpm...), though 20:06:44 I'm on the fence, but leaning to the side of waiting to see what's actually produced so we don't set a bad precedent 20:06:48 I think we should no matter the team makeup 20:06:55 I'm generally leaning towards requiring "some" work to be present -- it makes judging "are you one of us" a lot straightforward 20:07:00 the project also needs to prove itself 20:07:02 but then should we kick out packaging-deb which do not even have their repositories set up yet ? 20:07:06 I do not think we need to require "Some" work myself 20:07:08 so we've set objective criteria up 20:07:10 what about packaging-rpm, with its grand total of 4 commits ? 20:07:18 ttx: that was probably premature, then 20:07:19 but I do not feel so strongly about it to argue vehemently 20:07:37 me either, but you know, consistency 20:07:42 but we've pushed back on some projects because of lack of evidence of meeting the criteria - it just feels really weird to me that we'd not be consistent about that 20:07:51 * mordred does not care about consistency or a set of rules we published 20:07:53 if we go the "needs some work done first", that's fine, i can take the action to propose a guidelines update to make that more clear 20:07:54 at this point it's only expensive to add things if it's expensive to delete them 20:07:56 * mordred cares about our judgement as humans 20:07:57 if packaging-* doesn't have anything to show in a cycle or two, we can remove them :) 20:07:58 I think one difference now is that theer is no issue in proving yourself in openstack/* repositories without being official just yet 20:08:03 I like the project and contribs, but seems there should be some kind of digital trail 20:08:20 * mordred considers our guidelines to be guidelines and that we are humans and can decide to accept or not accept a set of humans should we choose 20:08:22 note that at last check, the deb packaging repos don't even exist yet 20:08:23 so there is no cost in starting the project out of the governance 20:08:24 mordred: I care about our judgement as humans - but I also care about what we're communicating to the other humans involved 20:08:33 mordred: but unfortunately that line of thinking means that we are a clique and the cool kids have to do nothing to get in 20:08:45 lifeless: I agree - but I think we can massage our guidelines - I want to make sure we do not become a slave to them 20:08:56 mordred: I would like for us to make sure we're not establishing a clique culture, where we accept any project from "people we know" and put newcomers through some sort of acceptance test -- it's a low enough bar to say, "run for a couple of months and let's see" 20:08:56 Looks like most people are fine waiting, and some people object to approviung. We should therefore delay 20:08:58 annegentle: i consistently vote to add new projects with no history :) 20:09:00 yeah.. concerned we've never expressed the standard 20:09:06 annegentle: +1 20:09:16 annegentle: is it that? or is it that proven members of the community have some trust which should be portable? 20:09:17 mordred: we're not a slave, we still have the judgement call of 'how much' needs to be there.. I think it is >0 20:09:19 annegentle, dhellmann: I think the only thing left that defines us as people is that the people are part of our set of people 20:09:23 mordred: sure. So - the first thing is that http://governance.openstack.org/reference/new-projects-requirements.html doesn't talk about guidelines 20:09:36 sdague: as a minority in this community I have to state what it looks like to me 20:09:44 sdague: I like trust, I also like earned trust 20:09:46 Anyone strongly objecting to delaying until there is something set up ? 20:09:48 I'm +1 on it, my only thought is going forward keep in mind the criteria used here and in other places 20:09:52 mordred: sure, but this is as much about appearances as anything. I can't imagine we'll come back in a month and say no to this team. 20:10:08 which is to say - I my vote is to be permissive in this case, but I understand and respect the alternate opinion 20:10:11 there seems to be more people objecting to approving it, than people objecting to delay it 20:10:25 I'd be happy to appprove if we go back to the folk we pushed back on and approve them, as they were no less conformant 20:10:29 for the record, I do not object to a delay 20:10:36 my vote is to include but that's because i _want_ to establish a culture where people start new projects and do them right and fully integrated from the start. 20:10:38 but I'd be fine moving forward 20:10:39 annegentle: well said 20:10:45 I think you can definitely approve it even with my no vote, right? Just voicing what I needed to say. 20:10:52 jeblair: ++ 20:10:53 jeblair: ++ 20:10:56 jeblair: fair point 20:11:05 jeblair: that is what I was trying and failing to say 20:11:07 jeblair: can they not do that without our blessing? 20:11:09 jeblair: yes~ 20:11:25 jeblair: like, what is held back from not-yet-in-governance projects these days? 20:11:55 now that applying to governance later doesn't imply a git repo rename, it's possible the interest in starting teh project first and then applying will increase 20:12:00 lifeless: voting 20:12:01 lifeless: services on openstack.org like docs hosting, and some amount of attention and care from other cross-project teams. 20:12:07 sigh, feels like it's when people don't have strong optionions that it's the most difficult to come to a conclusion 20:12:09 lifeless: and that 20:12:16 opinions* 20:12:26 ttx: lol 20:12:31 heh 20:12:36 so, while we have a voting mechanism, we also aim to be concensus based 20:12:45 quick check -- who strongly objects to delaying ? 20:12:47 no concensus means we should delay 20:12:52 and who strongly objects to approving ? 20:13:09 lifeless: like if you want to run ruby on java in your docker, i'm not going to care for a stackforge project, but i'm going to hold openstack projects to a higher standard in terms of ci construction 20:13:10 I don't really care either way. Slight preference for delaying. 20:13:19 sdague: +1 ... ideally with a guidelines followup that clarifies "do at least some work first", which i don't mind adding 20:13:30 it would be good if one or more of the folks that are pro delaying write those guidelines 20:13:32 or russellb :) 20:13:48 russellb: +1 20:13:52 russellb: please do 20:14:03 I'm happy to work on the guidelines 20:14:03 it'll just be a sentence or 2 to http://governance.openstack.org/reference/new-projects-requirements.html 20:14:11 A counter argument to "do at least some work first" is that it's possible corporate sponsors may want a project team to receive TC blessing before starting on a large endeavor. 20:14:13 So the ONE reason why I prefer to delay is: we'd accept the cool kids and delay the people we don't know and ask them to prove themselves first. 20:14:14 anyway, it seems like folks that are pro delay probably can best describe what makes them uncomfortable with moving this forward as is 20:14:32 my thinking is we have no evidence of "basic interop" or contributions 20:14:36 I think it's simpler to require everyone shows something 20:14:37 SpamapS: fyi, not an issue in this case. 20:14:37 nothing measurable yet 20:14:43 right, just show us something 20:14:51 i actually don't care much, but i'm happy doing the guidelines if that helps get us to better consensus 20:15:00 russellb: thanks 20:15:11 but is it just going to have 5 -1s "we shouldn't have to wait" ? 20:15:14 I feel strongly that governance should not impact interest/desire to work on the project, I also feel strongly that we should embrace our concept of inclusion 20:15:14 thanks russellb 20:15:16 if so, that doesn't really get us anywhere 20:15:21 OK, let's delay and have a general rule from now on that the project is started before applying 20:15:22 In other words, what's the point of wating? 20:15:23 SpamapS: with big tent, if we're doing that, we've gotten the engagement model very wonky 20:15:26 It succeeds or it doesn't 20:15:49 russellb: so how do I know that the last three bullets are met with Kosmos? 20:15:52 It has little impact on the TC either way after we get through the process of approving no? 20:15:53 jgriffith: so why did we ask monasca to wait? 20:15:57 russellb: well, I'd give it a shot 20:16:04 ok, will do 20:16:09 lifeless: I agree 100% with your statement. 20:16:12 I don' tthink requiring even a small history doesn't embrace inclusion, as annegentle said, without it the only history we have is personal history and that doesn't reflect what _that_ proiject might do in the future 20:16:14 annegentle: we annegentle ssume they will based on what we know of the team members, which very much feels like a bias 20:16:22 weird tab completion there 20:16:23 ttx: don't we need someone with a +1 to revoke it in order for the motion to fail? 20:16:25 ttx: right 20:16:30 ha 20:16:57 dtroyer: right.. we've had other proposed projects that wandered off in teh wrong direction after organizing 20:16:58 jeblair: formally yes, which is why I'd like people to agree on the direction 20:17:08 jeblair: procedurally can't ttx just table it 20:17:09 * jgriffith lifeless they weren't in the cool-kids club 20:17:09 lifeless: well, they had a definite not-one-of-us history 20:17:21 sdague: that sounds awfully like a veto 20:17:21 I can table it like swe did others 20:17:23 Feels weird to say there's no history available. There's a team somewhere that came up with the idea, and some other team that agrees with the idea. And that sounds like a short history of collaboration between orgs? 20:17:29 yeh, I do think monasca was actually the inverse here 20:17:38 lots of commit history, very little community history 20:17:42 jeblair: the resolution is still valid, just the timing is bad ? 20:17:55 rather than rejecting those we have been generally tabling them 20:18:32 edleafe: collaboration with what, 3 different contributing organisations 20:18:43 ttx: I think that is the right approach. 20:18:57 SpamapS: group based policy is an example that started the same with known people/team, but ended up in a place that would be hard for inclusion at this point 20:19:00 edleafe: resulted from community discussions at summits... 20:19:04 lifeless: I meant the closed meetings, java codebase, etc 20:19:07 If we were to call for a final vote now it would pass, based on current votes 20:19:13 frankly I liked seeing the application right off, it shows intent and makes the history a shorter peocess in my mind anyway 20:19:25 dtroyer: ++ 20:19:34 anyway, I think we agreed on a path forward right 20:19:40 1) delay 20:19:48 2) write up new guidelines on what is expected 20:19:56 sdague: jeblair objects and calls for a final vote 20:19:58 I've registered my concerns with the perception and I feel heard. That's how voting works, I think. 20:20:05 I think the hesitation is because removing is not so easy if they don't meet expectations 20:20:26 jeblair: is that what's happening? 20:20:39 If he does I'm hapopy to call for final vote now 20:20:43 i didn't think that was what i was doing -- i just thought we voted on things. :) 20:20:47 or happy even 20:20:48 if it goes in, can we still update guidelines to say "we encourage early application" ? 20:21:05 russellb: yes please 20:21:06 let's update guidelines either way, basically :) 20:21:11 ok, I guess I'm just confused. How about we #vote on plan listed above 20:21:19 with whatever history expectations we wind up with 20:21:20 delay 1 month and have new guidelines 20:21:34 I don't understand the issue, we table things for more discussion all the time 20:21:51 #startvote Should we delay the vote until the project is set up ? yes, no, abstain 20:21:52 Begin voting on: Should we delay the vote until the project is set up ? Valid vote options are yes, no, abstain. 20:21:53 Vote using '#vote OPTION'. Only your last vote counts. 20:21:54 i'd say we should expect a few months of project history (roughly), or we accept this and say we encourage early application like this 20:22:00 #vote yes 20:22:01 #vote yes 20:22:02 #vote yes 20:22:04 #vote yes 20:22:09 #vote yes 20:22:20 #vote yes 20:22:20 jeblair: feels less like a veto that way I guess 20:22:26 #vote yes 20:22:30 ttx: yes :) 20:22:38 sdague: thx :) 20:22:40 #vote yes 20:22:47 closing in 10 seconds 20:22:53 #vote yes 20:22:57 #endvote 20:22:58 #vote no 20:22:58 Voted on "Should we delay the vote until the project is set up ?" Results are 20:22:59 yes (9): ttx, annegentle, jeblair, russellb, sdague, mordred, dhellmann, dtroyer, markmcclain 20:23:05 dammit john 20:23:06 jgriffith: just missed it. 20:23:12 aw 20:23:12 Oh well 20:23:18 it will be in the minutes 20:23:22 :) 20:23:24 #agreed delay the vote until the project is set up 20:23:24 and it doesn't impact the actual vote 20:23:30 sdague: agreed 20:23:34 Obviously doesn't matter anyway 20:23:36 #vote yes 20:23:37 let's move on 20:23:40 blink and you mis it 20:23:48 #topic Add Juju Charms for Ubuntu to OpenStack 20:24:02 So the decision on Kosmos kind of sets a precedent here 20:24:04 same situation? 20:24:06 the wording of that is odd, since it is setup/created/cookiecutter/irc/etc, so please clarify what it means. i'll assume "show me some code". sdague, 1 month is likely too short in this case, due to it being summit month. 20:24:07 This is imho comparable to other packaging efforts we have in the big tent 20:24:12 There are no existing repositories though, so we could kosmos this one 20:24:18 dougwig: i was thinking "a few months" 20:24:19 is it the same situation? I thought they had a ton of code 20:24:23 ttx: verbed a noun 20:24:28 sdague: doing it in openstack though? 20:24:32 russellb: agree 20:24:34 annegentle: is that dirty ? 20:24:39 nah just funny to me 20:24:41 :) 20:24:47 russellb: ok, so is it a delay until there is a project-config import? 20:24:47 dougwig: but we'll have a review following up on this agreeing on some rough guideline 20:24:51 thre's a weird thing 20:25:00 the commit message makes me think its not open 20:25:01 The only original thing is the integration testing being done on Canonical infrastructure 20:25:03 I noticed the GPL mentioned here, does that present any issues since this isn't part of the actual applications? 20:25:26 " the core reviewers on 20:25:26 each repository may be derived from the company developing the charm." 20:25:34 maybe I'm reading that wonky 20:25:37 yeah, that also struck me as odd 20:25:44 but it sounds like a company-lock-on-the-repo 20:25:50 jamespage: ^ ? 20:25:57 oh, hey, I guess I missed that bit 20:26:04 "Charms are currently licensed under GPL v3." 20:26:15 perhaps the "may be derived from" is not definitive and merely a starting point 20:26:33 How about we table it since there is nothing yet -- and ask for clarification in the mean time ? 20:26:34 russellb: yeah, that's what I meant -- is that a problem since the charm code isn't part of the applications we deliver that have to be apache 2? 20:26:41 the GPL v3 is ok per our governance doc requirements - though its definitely unusual 20:26:47 dhellmann: our guidelines just say we prefer apache 2 20:26:53 dhellmann: just require "an open source license" 20:27:02 russellb: the bylaws are more specific, aren't they? 20:27:04 i'd certainly *prefer* apache 2 ... 20:27:04 right, so that seems fine 20:27:08 dhellmann: good question 20:27:21 though those only apply to trademarked code, iiuc, which is why I pointed out this is not application code 20:27:22 I thought the bylaws changed on that fron 20:27:24 How about we table it since there is nothing yet -- and ask for clarification in the mean time ? 20:27:36 ++ 20:27:38 +1 on tabling, I'll raise my questions on the review 20:27:53 fungi: you're likely right, but if so why mention it at all? 20:27:58 article VII in https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/ 20:28:06 The bit on ntegration testing being done on Canonical infrastructure is also making my openness radar buzz 20:28:10 sdague: did they? 20:28:12 lifeless, fungi: agreed -- likely overspecification but good to double check 20:28:32 fungi: just say 'initial core reviewers will be the folk that create each charm' or something 20:28:38 yep 20:28:41 7.1.b seems to only apply to the tc-approved-release, so I think we're ok, I just wanted to get confirmation 20:28:46 ttx: i wonder if there is a technical reason they can't do it upstream? 20:28:46 fungi: *company* is a very odd thing here :) 20:28:47 fwiw, we asked fuel to collaborate with os-infra, we probably might want to do the same with charms. 20:28:52 ttx: third-party ci? 20:29:10 jeblair: its all part of OIL 20:29:12 jeblair, dhellmann: sure, I just want to make sure that's a technical reason 20:29:15 ttx: also, it is worth noting that despite being one of the earliest third-party ci operators, they've never been good about reporting upstream... 20:29:33 jeblair: their proprietary 'openstack interoperability lab' that they sell testing-on-and-via to companies 20:29:41 dhellmann, ttx: so i would not even assume that text means "we will report our local testing upstream" 20:29:58 https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/ "INTELLECTUAL PROPERTY POLICY" mentions Apache 2 quite specifically 20:30:03 I guess that's a good point for clarification 20:30:05 but i need a bit more time to parse it in pedantic mode 20:30:08 lifeless: yeah, concerning. 20:30:09 ok, I think we have a path forward here 20:30:09 jeblair: its very much bare metal based, and upstream infra have no baremetal facilities today AIUI - including baremetal routers etc 20:30:25 jeblair: fair 20:30:40 lifeless: that may be true - but I thnk a good faith effort to come up wiht a workable infra soluiton would be nice 20:30:43 jeblair: so AIUI, at least some of the charms aren't able to be exercised in a virtual environment 20:30:58 #agreed Juju charms application delayed until there is something substantial in the repositories (they can be set up without being "official" now). We'll clarify other specific points in the mean time 20:30:58 I was still parsing the OIL acronym 20:30:59 :) 20:31:09 it says we distributed the "approved release" under the apache license. it also says we accept contributions with an agreemen that lets us redistribute under the apache license. 20:31:11 the least we can ask is a third party CI where all logs and access are open 20:31:15 mordred: / jeblair: / fungi: has Canonical discussed that with infra? 20:31:22 lifeless: not to my knowledge 20:31:27 annegentle: what did you get? :-) 20:31:29 lifeless: no. there has never been any attempt at ocooperation 20:31:31 Moving on... 20:31:38 OIL=OpenStack Interop Lab 20:31:58 #topic CloudKitty application for Big Tent 20:32:00 annegentle: thanks 20:32:03 russellb: yes, the cla may not be sane for gpl projects? 20:32:11 dhellmann: I expanded it on my next line :) 20:32:12 #link https://review.openstack.org/225201 20:32:15 annegentle: of course we have the Wide Area Testing and Experimental Reporting project 20:32:23 lifeless: ah, missed that 20:32:37 OK, so CloudKitty. This feels rather straightforward big-tent to me 20:32:43 jeblair: may they ever mix 20:32:44 the project has been around for a while in the OpenStack community and is even used in production somewhere 20:32:54 ttx: ++ 20:33:15 ttx: yep agreed 20:33:16 objections, questions ? 20:33:22 I think we have the PTL around 20:33:29 fungi: yeah ... and it may just mean that this could never be part of the "TC approved release", which is probably fine 20:33:32 Yes, I'm here. 20:33:41 sheeprine: o/ welcome 20:34:06 how could you say no to something called CloudKitty? 20:34:08 one more approval and it's in 20:34:11 with big eyes like that? 20:34:22 sheeprine: i request a cute kitten logo 20:34:28 jeblair: the name fails annegentle guidelines with capitalization :) 20:34:38 +1 fro me on the spec 20:34:40 ttx: lol oh so true 20:34:45 annegentle kicks kittens! 20:34:45 :) 20:34:53 ok, we have a winner, approving now 20:34:55 ttx: we're at 9 20:35:01 welcome, cloudkitty! 20:35:03 meow. 20:35:06 cloudkitty! 20:35:10 kitty kitty 20:35:19 now go change the capitalization 20:35:23 thanks 20:35:23 * dhellmann wants a mascot sticker at the summit 20:35:32 I'll work on the capitalization. 20:35:37 * ttx continues to rush through the busy agenda 20:35:39 after you make stickers 20:35:45 #topic Remove MagnetoDB from OpenStack 20:35:52 We've got stickers and more for the summit ;) 20:35:55 #link https://review.openstack.org/224743 20:35:58 sheeprine: \o/ 20:36:01 We discussed this one last week 20:36:08 There is general agreement that we should remove MagnetoDB, we just disagreed on how to encode that in the governance repository 20:36:17 Not much progress or proposals on the review this week 20:36:25 Should we just have a retired-teams.yaml and move the entries there, with some timestamp to account for expiration of entries after the ATC delay ? 20:36:36 ++ 20:36:44 it'd be good book keeping, i think 20:36:52 ++ it fits with the rest of our dont-delete-history 20:36:52 I'll propose that if folks want 20:36:57 retired-teams.yaml sounds good to me 20:36:59 dhellmann: thanks! 20:37:00 +1 20:37:12 if you do it while we continue the meeting we could even approve it :) 20:37:20 * dhellmann starts typing 20:37:25 or projects-emeritus.yaml :) 20:37:28 i mean, i'd love it if git were the history, but i'm okay with retired-teams until our schema stabilizes 20:37:54 attic? /me stops naming things 20:38:00 jeblair: yeah, that was my original thinking, but people got worried 20:38:12 (to bikeshed, it really ought to have a name relation to projects.yaml though) 20:38:15 I mean, do we still move code to the attic if a team retires? 20:38:19 the worry was about tooling around calculating ATC status wasn't it? 20:38:23 not sure it's a real problem in this case 20:38:25 ok, let's move on while dhellmann types, and come back to it in a few 20:38:30 but could be eventually *shrug* 20:38:33 russellb: yep 20:38:40 #topic Cross-project track at Mitaka design summit: status update 20:38:50 Flavio set October 9th for the deadline to propose things at http://odsreg.openstack.org/ 20:38:57 right, in this case it potentially impacted 1 atc, but I could imagine there being more 20:39:06 We have 17 proposals there, not sure if all the etherpad was copied or not 20:39:22 Ideally the cross-project workgroup volunteers would do the heavy lifting between the 9th and the 13th, so that we have somethign to discuss and approve at the Oct 13th TC meeting 20:39:31 And move to scheduling quickly afterwards 20:39:43 Does that sound like a plan ? Probably means a quick meeting on the Monday 20:39:55 of the cross-project track volunteers 20:40:09 damn you flaper87 for closing it on a friday instead of a thursday 20:40:17 sdague: I know, right 20:40:19 dates are important 20:40:40 I think more importantly, are there topics we feel need to be addressed that aren't getting proposed 20:41:09 I can do monday 20:41:15 ttx: updated 20:41:23 sdague: ITYM wednesday, since a meeting on your friday is my saturday :) 20:41:55 :) 20:42:00 everyone: please review https://review.openstack.org/#/c/224743/ 20:42:44 I'm happy to bikeshed the "retired-on" field in a separate patch 20:42:51 we'll go back to topic brainstorming at the end of the meeting in Open Discussion. We can also interpret the bylaws on GPLv3 then 20:43:12 one more... 20:43:22 it seems like a good time for every TC member to put their nickle down on a cross project issue they feel is getting neglected 20:43:47 sdague: I filed one but I'll definitely give it another thought session 20:44:18 ok, 7 votes, I can approve the MagnetoDB removal 20:44:28 last call 20:44:35 sec 20:44:46 there 20:44:56 i'll go ahead and force-merge the related retirement change in project-config 20:45:19 fungi: that was the patch to delete all the code? 20:45:28 yep. and i'll also abandon open changes 20:45:42 we have some infra documentation (maybe already merged?) on returing repos now 20:45:43 ok. I was a little surprised by that, but I guess it makes sense 20:45:54 retiring too 20:46:07 dhellmann: we have had users not realize that they are using abandoned projects, so we are striving to make it more clear 20:46:08 ok done 20:46:15 fungi: thanks for that 20:46:17 #topic Communications workgroup report 20:46:20 jeblair: this is certainly one way to do that :-) 20:46:26 annegentle: anything to report ? 20:46:40 blog post done last week, have to admit I had missed 2 from the prior 2 weeks ago so it was chockful of info :) 20:47:26 do you think we should do one flaper87 to get cross-project summit proposals by 10/9? 20:47:44 annegentle: that sounds like a good idea 20:47:48 that wouldn't hurt. But could wait next week meeting maybe 20:47:52 it seems like getting one out this week to beat that drum would be good 20:47:53 #link http://www.openstack.org/blog/2015/09/technical-committee-highlights-september-25-2015/ 20:48:01 given that this friday is the 2nd 20:48:05 ++ 20:48:05 let's see the 9th is next Friday... hm 20:48:29 We did mention it at the end of that post ^^ 20:48:38 so we're probably covered 20:48:45 ok, then maybe wait and do a last reminder one next week ? 20:48:56 with things approved today and next week ? 20:49:15 or tweet tweet? 20:49:42 where's my partner in crime flaper87? :) 20:50:00 I can see blogging by next Wed. 20:50:04 we might raise a thread on the ML around TC candidates too 20:50:34 ok, moving to open discussion since we are talkign about everything at the same time now 20:50:36 #topic Open discussion 20:50:43 Everyone: Tomorrow is the last day to submit your TC candidacy if you're interested in joining us 20:50:50 Also there will be a joint TC/Board meeting in Tokyo on the Monday, starting at 2:30pm 20:50:56 At 4:30pm we'll be joining the "Women of OpenStack networking event" (4:30pm - 7:30pm) 20:51:12 mark your calendars if you're a member of running for election 20:51:16 At some point, we need to chat about how surveys are distributed in the community. Not sure if this is the forum. 20:51:28 Piet: probably not. We don't do surveys. 20:51:41 ttx: k 20:51:46 ttx: I was going to do one on the devs 20:52:00 ttx: but I ran out of steam - there was lots of interest in it though 20:52:03 lifeless: about terminal width ? 20:52:15 ttx: hah, no. I'll dig up a thread pointer for you 20:52:36 ttx: but - I was thinking that the foundation which already runs e.g. the user survey might be a good body to coordinate such things 20:52:45 ttx: do you know anyone there to chat with about that? 20:52:49 Piet: cross-project meeting though sounds right 20:52:50 let's ask about editor preferences too 20:53:00 russellb: so actually that was one of the questions I was going to ask 20:53:10 lifeless: I can relay the concerns to staff if we voice them 20:53:11 russellb: to put the .gitignore questions to bed 20:53:20 but only have "vim" as a choice 20:53:37 ttx: so - the question is, is there someone at the foundation with the time to run a developer survey, if we put the questions together ? 20:53:37 russellb: vim and "other" I like it 20:53:46 in Piet's case maybe the "openstack-foundation" ML is the right forum 20:53:56 annegentle: sounds good. I want to make sure that we are able to be responsive to the project teams. Adding a few questions to a bi-annual survey may not get us there. 20:54:07 since most surveys are coming from the Foundation surveymonkey account 20:54:16 Piet: ttx is also right, surveys through Foundation 20:54:30 well part of it is that Piet doesn't have access to the fondation survey data 20:54:38 and would like to have some data 20:54:41 annegentle: I'm pushing back on that assumption 20:54:46 if I understand correctly Piet 20:54:47 * ttx looks at Foundation bylaws and GPLv3 20:55:11 for clarity, Piet and I are talking totally different things :) 20:55:32 yeh, so I swore there was something in Atlanta about it just needing to be open source 20:55:42 however, I can't find it anywhere now 20:55:44 We generally try to focus on small samples, but occasionally need to do surveys 20:55:54 ttx: Article 7.1 in particular 20:55:57 Piet: lifeless: yes still sounds like surveys are cross-project and Foundation areas 20:55:57 so maybe GPLv3 is a blocker 20:56:20 And the foundation has not provided raw data 20:56:22 not something the TC mediates 20:56:25 looks like a question for foundation legal 20:56:26 7.1 (b) sayd "TC approved release", so it would at a minimum mean something non-apache2 could never be in TC approved release 20:56:30 annegentle: so openstack-foundation is the place to ask ? 20:56:31 7.1 (a) is much less clear though 20:56:34 ttx: ++ 20:56:43 right, in the TC approved release, that seems fine 20:56:44 russellb: yeah, b is clear, a is lawyerese 20:57:05 lifeless: for your Q I would log a ticket in their system or ask directly on the openstack-foundation list 20:57:06 but aren't there things in openstack-infra that are not apache2? 20:57:06 "may adopt additional contributor license agreements as may be appropriate for certain organizations or contributions to secure a license on terms which will permit distribution under the Apache License 2.0" seriously 20:57:15 yeahhhh 20:57:24 "we use a cla, and whatever else want to ensure we can distribute under apache 2" 20:57:25 i think.. 20:57:31 sdague: I don't think so 20:57:34 right, which is the whole CLA trump the world thing 20:57:37 sdague, russellb: i believe we have heard from the foundation's lawyer that things outside the release are gpl-okay 20:58:12 speaking of which, have we heard recently about board / tc meeting agenda 20:58:18 and the CLA vs. DCO thing 20:58:30 this needs to be added to https://wiki.openstack.org/wiki/LegalIssuesFAQ 20:58:33 sdague: I'm taking up suggestions for the BoD/TC meeting agenda :) 20:58:41 annegentle: 'their system' ? 20:58:42 because I believe the last email statement around that was it would be voted on in Tokyo 20:58:53 ttx: it should be a standing agenda item :( 20:58:54 ttx: ok, that's my first suggestion 20:59:03 jeblair: ++ 20:59:06 sdague: ++ 20:59:08 lifeless: they have a ticketing system for support requests, sorry I can't recall the email address. I use it for logo@openstack for example 20:59:12 sdague: agreed, that is my expectation 20:59:16 I have no idea what the agenda of the Board part of the meeting is. Maybe mordred or russellb know 20:59:18 lifeless: might be info@openstack? 20:59:21 no updates re: DCO 20:59:29 o_O 20:59:29 no updates available to me anyway 20:59:40 russellb / mordred could you push on that? 20:59:41 legal affairs committee kind of blocked it 20:59:50 and insisted they needed a private lawyer only meeting to move forward 20:59:55 ttx: o/ 21:00:01 https://wiki.openstack.org/wiki/Governance/Foundation/26Oct2015BoardMeeting 21:00:01 in between last meeting and next one (tokyo) 21:00:01 cpallares: o/ 21:00:06 but i don't know if that has happened ... 21:00:06 no agenda listed yet 21:00:17 or, very little of one 21:00:18 russellb: really? disappointing 21:00:20 ok, we are running out of time 21:00:34 because, I'll be honest, if this isn't getting a floor vote in Tokyo, I'm not really sure why the TC is going to the board meeting 21:00:37 ttx: Can we discuss CoC next week? 21:00:45 russellb, mordred: could you get an updated status on that ? 21:00:48 sdague: i'm going into it expecting a vote 21:00:51 ttx: Should I come back for the next open discussion? 21:00:57 ttx: can try 21:00:57 as we've been asking about this for 3 cycles now 21:00:57 cpallares: yes please 21:01:04 that's what we left the last meeting with ... 21:01:12 russellb: ok 21:01:12 * mordred agrees with russellb 21:01:12 "let people get any last questions answered now, and we vote in tokyo" 21:01:16 ok time is up 21:01:22 #endmeeting