16:59:36 #startmeeting TSC 16:59:36 Meeting started Thu Jul 31 16:59:36 2014 UTC. The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html. 16:59:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:59:36 The meeting name has been set to 'tsc' 16:59:44 #info dmm 17:00:05 #topic TSC members please #info in 17:00:09 #info regXboi 17:01:13 #info abhijt (dmm for abhijt) 17:02:00 #info Madhu 17:02:31 #info Kent Watsen 17:02:50 #info Ivan Wood for Microsoft 17:03:04 #info edwarnicke 17:03:50 #chair regXboi colindixon Madhu edwarnicke 17:03:50 Current chairs: Madhu colindixon edwarnicke phrobb regXboi 17:03:59 #link https://wiki.opendaylight.org/view/TSC:Main 17:04:00 * colindixon saunters in 2 minutes early by TSC member time 17:05:37 #topic Event Updates 17:06:12 http://www.opendaylight.org/events/2014-10-14/opendaylight-mini-summit-sdn-openflow-world-congress 17:06:36 #link http://www.opendaylight.org/events/2014-10-14/opendaylight-mini-summit-sdn-openflow-world-congress we are low on submissions for the ODL mini summit in dusseldorf 17:06:44 #info please submit if you will be there 17:06:54 #topic Sys Integration and Testing Update 17:07:05 Joined using Web IRC (due to issues with the IRC client at my hotel wifi) - may have issues 17:07:10 #info Lenrow 17:08:36 thx abhijit 17:11:13 #topic at large elections 17:11:41 %22 17:11:59 %22 17:12:14 #link https://wiki.opendaylight.org/view/TSC:Committer-At-Large_Election_Process 17:12:18 thanks 17:12:54 #link https://wiki.opendaylight.org/view/TSC:2014_Committer-At-Large_TSC_Election and this is likely to be where we produce the results 17:17:24 #info phrobb goes through the process in detail 17:20:04 #info phrobb notes that the only feedback on the process in the last week was from ChrisPriceAB asking if we could make it so that there was time to make sure we know who has turned down the nomination before we vote 17:20:54 #info edwarnicke asks how we will order people as they’re listed? (suggests alpahbetical by last time) 17:21:52 What about the name of the company that the people work for. Should it be grouped by company name also, as there cannot be more than one from a single company? 17:22:15 Cannot be more than one ELECTED froma a single company 17:22:18 IvanWood: I think the issue was just we wanted a “bias-free” way of listing people 17:23:47 #action phrobb to make the modifications to the at-large election process wiki page and then send a mail to to the TSC asking for people to approve it 17:23:49 * edwarnicke contemplates wheeling out ye-olde-veil-of-ignorance again... 17:23:59 edwarnicke: I will hurt you :p 17:24:10 * tbachman lives in a veil of ignorance 17:24:18 colindixon: LOL 17:24:48 #info abhijit_kumbhare asks if we can allow people to pick whether they wanted to be sorted by first or last name, dmm says he’d vastly prefer to not to do something that is non-uniform in sorting 17:26:28 #info edwarnicke says that phrobb should make sure to note in the e-mail that people will not make their company’s platinum representative step down if they are elected 17:28:31 Core members in OpenStack are per project, they are not equivalent to TSC. 17:28:50 Youcef: Thank you for that clarifiation :) 17:29:28 #info there is a discussion about whether the nomination process (that is who nominated who and if somebody self-nominated) should be done publicly or privately 17:30:56 #info several other data points are brought up: (1) IETF makes it private, (2) OpenStack PTLs are only self-nominated, (3) OpenStack core developers are nominated in public 17:32:19 #info Apache nominations are reported done in private 17:32:38 I kind of like the only self-nominations idea 17:32:50 and allowing people lobby others out of band to nominate themselves if you want 17:33:06 Notes that this is much easier on phrobb 17:33:12 Which is also goodness 17:33:31 regXboi and dmm also is seem in favor of that 17:34:09 #startvote should the nominations be 1) private, 2) public, or 3) self-nomination-only? 1, 2, 3 17:34:09 Begin voting on: should the nominations be 1) private, 2) public, or 3) self-nomination-only? Valid vote options are 1, 2, 3. 17:34:09 Vote using '#vote OPTION'. Only your last vote counts. 17:34:17 #vote 3 17:34:20 #vote 3 17:34:24 #vote 2 17:34:24 #vote 3 17:34:28 #vote 3 17:34:30 #vote 3 17:34:33 #vote 3 17:34:33 There are advantages to self nominate - #vote 3 17:34:42 #endvote 17:34:42 Voted on "should the nominations be 1) private, 2) public, or 3) self-nomination-only?" Results are 17:34:42 3 (6): dlenrow, regXboi, dmm, edwarnicke, kwatsen, IvanWood 17:34:42 2 (1): Madhu 17:34:52 phrobb: I’ll let you #agreed it 17:35:02 #agreed nomination will be done as self-nomination-only 17:35:12 abhijit_kumbhare: for future reference, I think the #vote has to be the first thing on the line 17:35:36 (just as an FYI) 17:35:43 #topic Project Infra and support staff discussion 17:36:19 tbachman: It was a mistake - was writing earlier point before writing # vote 17:36:30 ah :) 17:36:54 #info we’ve seen over the past few weeks (and it’s been discussed at the board) that getting project infrastructure has taken longer than we’d like 17:38:03 #info the core issue is that many feel as though we need to flag budge to hire people and/or acquire infrastructure to help us out and dmm wants to get opinions from the TSC to accurately represent that to the board 17:38:23 #info LuisGomez seconds what dmm said 17:38:38 +1 17:38:48 #info edwarnicke says, we need this resolved and please, Please, PLEASE we need a release manager 17:39:05 +1 17:39:17 self-serving infrastructure 17:39:17 +1 17:39:27 Release manager 17:39:30 Madhu: LOL... I think the infra should serve us ;) 17:40:03 edwarnicke: :) i mean not to have a single point of blockage :) 17:40:04 #info rocky from huawei says they’re trying to do something to help in the release manager space and that they’ve seen that having a community member be the release manager works well in OpenStack 17:40:11 edwarnicke: i want a VM... i should get it 17:40:14 phrobb: can you #action that? 17:40:14 #info it was pointed out that OpenStack has a Release Manager on staff with the foundation 17:40:20 edwarnicke: not open a case and wait !!! 17:40:25 #action probb to put infra and support staff needs on Board agenda for next meeting 17:40:29 edwarnicke: oh I got that wrong 17:40:39 colindixon: I though rocky said the opposite, that the OpenStack foundation employs a Release Manager... 17:40:49 irc://irc.freenode.net:6667/#action phrobb to put infra and support staff needs on Board agenda for next meeting 17:40:52 …. 17:41:13 edwarnicke: I’m not sure, did somebody else catch that 17:41:24 #topic stable hydrogen 17:41:41 #info dmm got ahold of affinity and they asked to not be present in stable hydrogen 17:43:05 #info regXboi says that’s going to complicate cutting those artifacts annoying, but dmm points out that it’s the only thing we can do because we didn’t say participating in hydrogen meant also participating in hydrogen stable as well 17:43:44 #undo 17:43:44 Removing item from minutes: 17:43:55 oh wow 17:43:56 * tbachman learns new meetbot command 17:43:57 that’s a cool command 17:44:14 #info regXboi says that removing affinity has the side effect of requiring new collateral 17:44:16 regXboi: did you actually know that one ? 17:44:22 tbachman: yes 17:44:23 or was that just lucky :) 17:44:25 :D 17:44:27 good! 17:44:29 #link https://git.opendaylight.org/gerrit/#/c/9295/ - the patch is ready 17:44:35 tbachman: I've seen it used previously 17:44:40 nice :) 17:45:13 #info dmm points out that we can't hold things against affinity because we didn’t say participating in hydrogen meant also participating in hydrogen stable as well 17:45:33 #info phrobb and others reached out to Defense4All and they have agreed that because their code passes their tests and they’ve made no changes, we can include them in hydrogen stable 17:49:17 #info there is discussion about whether we need to redo all the testing with this new approach, consensus is that we do 17:49:34 do we have the list of lessons learned from Hydrogen/Helium to apply to Lithium? 17:49:41 on the wiki somewhere 17:50:43 I want to make sure to document the expectation of participation in stable releases after the first release 17:50:54 edwarnicke: did you make a wiki page for that or just a mail thread? 17:50:59 #info dmm asks "when do we expect to be finished with reving/testing Hydrogen Stable again?" 17:51:06 phrobb: thanks 17:51:36 #info people say that we’re bogged down in Helium release stuff, so doing full tests may take longer than we’d expect 17:53:31 #info colindixon suggests targetting one week to get the rev/testing of Hydrogen Stable finished (by next Thursday). edwarnicke notes he is very heads down on Helium. The Helium M4 milestone is consuming most groups currently 17:53:44 #topic helium packaging 17:53:48 thanks phrobb 17:54:00 Yes - agree with Madhu & edwarnicke - about folks being bogged down by M4/Helium 17:55:49 phrobb: can you state what the proposal was? 17:56:18 which proposal? sorry 17:56:25 no worries, I’ll do my best 17:56:57 #info the current most concrete proposed plan for release vehicles is to use karaf and let people build distributions out of features (or the component concept we’ve been developing) 17:57:07 #info dmm seeks feedback about this or alternatives from the TSC 17:57:33 @colindixon Thanks 17:59:05 who is on by default matters 17:59:43 edwarnicke: did we agree to that? 17:59:49 #Madhu notes that having a "base edition" composition of karaf features/components is still needed with providing the ability to add the other components. Then also having an "everything" edition that includes everything. 17:59:56 I mean I agree with it, but I don’t know that *we* the community did 18:00:17 #info Madhu notes that having a "base edition" composition of karaf features/components is still needed with providing the ability to add the other components. Then also having an "everything" edition that includes everything. 18:00:40 thanks colindixon… I'm all thumbs today 18:00:50 colindixon: i don't want to undo :) 18:00:57 but am not talking about everything edition :) 18:01:08 am talking about providing a feature:install for everything else 18:01:09 ah, OK 18:01:21 #info edwarnicke says that being “on by default” is probably a position that everyone would want, but because of conflicts not everyone can 18:01:37 #undo 18:01:37 Removing item from minutes: 18:01:39 #undo 18:01:39 Removing item from minutes: 18:02:17 #info Madhu notes that having a "base edition" composition of karaf features/components that works for people would be really good and then let people turn other things on as they choose 18:02:28 #info edwarnicke says that being “on by default” is probably a position that everyone would want, but because of conflicts not everyone can 18:03:39 timecheck ? 18:04:16 #info dmm says that the level of flexibility from being able to turn features on and off is great, but how does it affect the testing matrix? 18:05:14 #info edwarnicke says we’ve discussed this over the last few weeks and we decided we would test each feature with *only* the other features it requires and with all features that it doesn’t *explicitly* say it conflicts with 18:07:02 #info discussion continues about whether we can have a base edition that works out of the box or if the political battle for who goes into it will kill us 18:07:20 #info LuisGomez asks if we can at least agree that all projects need to support karaf 18:08:18 #info dmm says we should start a thread on discuss or TSC to drive this forward so that we can make a decision about helium packaging next week 18:08:24 endmeeting? 18:08:32 almost... 18:08:40 :p 18:08:43 #endmeeting