15:00:05 #startmeeting Lithium M1/M2 15:00:05 Meeting started Wed Jan 7 15:00:05 2015 UTC. The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html. 15:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:05 The meeting name has been set to 'lithium_m1_m2' 15:00:26 #topic RollCall TSC members and Project Leaders/Contacts Please #info in 15:00:38 #info regXboi (TSC and all around gadfly) 15:01:23 #info alagalah (GBP) 15:01:32 #chair gzhao regXboi colindixon 15:01:32 Current chairs: colindixon gzhao phrobb regXboi 15:01:32 #info edwarnicke 15:01:42 #info lori (lispflowmapping) 15:01:42 #info colindixon (TSC, TTP, Docs) 15:01:44 #info mlemay (Docs, Reservation) 15:01:47 #info liemmn (AAA) 15:01:57 * regXboi wonders about being a chair for a IRC only meeting :) 15:02:04 #info Venkat (LACP) 15:02:08 #info Hideyuki Tai (VTN) 15:02:11 #info ankit (plugin2oc) 15:02:34 #info Vijay for SNBI 15:03:00 #info ttkacik for controller and yangtools 15:03:04 #info ebrjohn (Brady Johnson) for SFC 15:03:18 #info ttkacik__ for controller and yangtools 15:03:27 Hi 15:03:31 #info bennyr for Defense4All 15:03:36 #info abhijitkumbhare for OpenFlow Plugin 15:03:38 #info dneary 15:03:42 #info edwarnicke just for fun ;) 15:04:09 One more minute for roll call 15:04:34 Hi, #info hchen for USC 15:04:35 #info oflibMichal for openflowjava 15:04:36 #info alagalah (OpFlex POC) (should have put that on the first one) 15:04:38 edwarnicke - good to see you having fun :) 15:04:44 #info oflibMichal for topoprocessing 15:04:47 #info Rajesh (LACP) 15:04:52 abhijitkumbhare: Aren't I always having fun? ;) 15:05:10 Yes - but edwarnicke its a new year of fun :) 15:05:15 #info Ravi (LACP) 15:05:44 #info The purpose of this meeting is to have a place where project can ask questions of one another, and announce any interesting or/or change in plans 15:05:55 #info Thanh (Releng) 15:05:59 edwarnicke: you aren't here just for fun, you have that magic "tsc" next to your name! 15:06:24 Before we start with the agenda items I sent, does anyone have any general questions or comments on this meeting? 15:06:50 phrobb: so, is this meeting basically just an open call for questions, concerns and issues? 15:06:54 #info Dana for bgpcep 15:06:55 regXboi: Surely the TSC can be fun 15:07:12 colindixon: I think its also a good place to bounce ideas intentions etc 15:07:23 * edwarnicke has a few he'd like to socialize personally, but should probably wait his turn ;) 15:07:28 colindixon: Yes, just a forum to ensure communcation can happen as projects prepare their final release plans 15:07:45 #info fabiel.zuniga for PErsistence Data Store 15:07:53 colindixon: did you have another/addition goals for this meeting? 15:08:13 * edwarnicke suspects we will learn a good format as we go :) 15:08:26 phrobb, edwarnicke: no, that sounds good. I think in the longer run it probably makes sense to spend a few minutes looking over each release plan before they’re finalized at M2. 15:08:28 phrobb I think we should really check if there are any project leads who need to have a different timezone meeting - my guess is that there may not be any but for that we will have problems for the Eurpoean timezone folks 15:08:29 #info ChristineH for snmp4sdn 15:08:49 colindixon: and all, as we get close to M2 we can review candidate final release plans 15:08:53 abhijitkumbhare: That is a good idea :) 15:08:57 abhijitkumbhare: yes, that is the last agenda item for today 15:09:23 #topic Any questions from one project to another 15:09:58 #info Do any project leaders have requests or informational questions to any other projects for the Lithium Release? 15:10:05 I have a question… Anyone using token-based auth out there? or are we still using basic auth? 15:10:31 liemmn: I am just using basic auth... but am far from representative ;) 15:10:41 liemmn: same for me 15:10:55 liemmn: should we be moving to token based auth? 15:10:59 We would like folks like dlux to start using token-based auth 15:11:00 yep 15:11:13 liemmn: basic 15:11:34 I am from the India time zone - would the time for the meetings be different every time or would it differ? 15:11:44 colindixon: What is the canonical way to record that request? 15:11:55 (colindixon liemmn's request) 15:12:01 liemmn: basic is useful for quick testing 15:12:31 edwarnicke: I’d put it as a request on the release plan for dlux if one exists yet 15:12:35 colindixon: enhancement/improvement bug in bugzilla 15:12:36 yep, for operator, it does not matter, but for application authenticating like dlux, token auth allows federation, etc... 15:12:56 https://wiki.opendaylight.org/view/OpenDaylight_dlux:Lithium_Release_Plan#Requests_from_Other_Projects 15:12:56 Venkat_: this might be the only time to have a meeting for all time zones 15:12:58 there' 15:13:08 Venkat_: the original proposal was to alternate between 8pm and 8am India time 15:13:09 but, let's first have apps do token-auth first, and then we worry about federation... 15:13:18 liemmn: Could you take an action to record your request in the manner colindixon pointed to in https://wiki.opendaylight.org/view/OpenDaylight_dlux:Lithium_Release_Plan#Requests_from_Other_Projects 15:13:27 liemmn: Do you have a proposed target list other than Dlux ? 15:13:29 got it, ed 15:13:29 liemmn: So that its on record with dlux and we can track it? 15:13:31 Liem: As DLUX member, I say we are using Basic Auth but I'd prefer Token if possible, we did OAuth code for AngularJS 15:14:03 #link https://wiki.opendaylight.org/view/Simultaneous_Release:Per-Project_Lithium_Release_Plan_Template#Requests_from_Other_Projects the rough process and template to make a request on another project is here 15:14:04 * edwarnicke worries about things falling between the cracks 15:14:05 AAA uses OAuth2 15:14:41 #info liemmn is asking for dlux to switch to using token-based authentication since it’s an application (and not a human user), which should make it easier 15:15:14 colindixon: for controller and yangtools project we extended that process also to contain bug in bugzilla 15:15:20 gzhao: colindixon phrobb Can we get a #link to the current project release task-list dashboard ? 15:15:23 ttkacik__: sounds good 15:15:26 colindixon: so we can proper track dependencies 15:15:31 liemm: Yea.. that's what I meant sorry... can we discuss this for DLUX offline as I am meeting with Harman / Maxime tomorrow to review their plan 15:15:35 phrobb, colindixon - I have a feeling there will be more requests from projects to each other in the coming few meetings - so will this be an ongoing topic for the next few meetings? 15:15:56 This is YuLing from TSDR project... our DataCollection Service has a dependency on OpenFlow Plugin statistics collection. We have some questions related to OpenFlow plugin... is it possible for us to get some support from OF plugin team? 15:16:03 #action liemmn to log the request on dlux’s release plan as well as reach out to them as described in the process above 15:16:04 abhijitkumbhare: that's the idea, we have this meeting weekly at least up until M2 15:16:09 gzhao: current timing works well for me. thanks! 15:16:10 OK 15:16:10 ttkacik__: Do you have a link to how to file a bug as a request for controller's release plan? 15:16:30 #link https://wiki.opendaylight.org/view/OpenDaylight_dlux:Lithium_Release_Plan#Requests_from_Other_Projects this is the section to formally log the request 15:16:33 alagalah: https://docs.google.com/spreadsheets/d/1KPpO9LH539Vlcoa4RvLa6PPCdLifi5JD-ihRhlybqeo/edit#gid=0 <= is this the link? 15:16:52 YuLing - we can schedule a meeting sometime 15:17:00 That sounds great 15:17:19 I'll send you invitations 15:17:25 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:Lithium:Release_Plan#Requests_from_Other_Projects Controller Request section 15:17:35 YuLing: abhijitkumbhare as we figure out the needs, lets make sure we get them recorded in the release plan :) 15:17:44 #info colindixon notest that the formal documenting the request on the release plan is designed to provide a summary of what is hopefully a longer discussion between the two projects that need not be fully logged on the wiki (although a pointer to mailing list threads would be good) 15:18:02 #info vishnoianil 15:18:06 Yes - we will be doing that - edwarnicke 15:18:06 colindixon: Would this also be a good place to highlight possible things that might impact projects downstream? 15:18:11 * edwarnicke :) 15:18:23 #info ttkacik__ notes that the controller and yangtools are asking people to also file bugs for requests so that they can be tracked with dependencies 15:18:37 #info Sachi (plugin2oc and GBP oc Renderer) 15:18:43 phrobb: did you have another topic for general announcements, or is this a good time? 15:18:55 Yes, there is another topic... 15:19:03 Are we finished with questions? 15:19:04 sorry i am late to the party 15:19:11 i want to share on more info 15:19:14 …. Last call for inter-project questions 15:19:17 abhijitkumbhare: yes I tihnk this meeting will continue and act as a clearing house for cross-project issues—although nothing should stop you for from reaching out via mail not during these meetings 15:19:19 welcome to the party vishnoianil 15:19:30 vishnoianil: announcements are comming up next… good timing 15:19:33 i am working on a migrating nsf to openflowplugin 15:19:35 yes - of course colindixon 15:19:43 abhijitkumbhare: :-) 15:19:56 statistics-manager/forwarding rule manager/inventory manager etc to openflowplugin 15:19:57 #topic Project Announements 15:20:10 Good timing vishnoianil :) 15:20:11 phrobb: I tend to think personally more in terms of "I think that it would be good to do this and am willing to pick up a shovel and do it... what do you guys thing?" 15:20:12 think 15:20:28 phrobb: gzhao I will resend gzhao the GBP project link and also the OpFlex intent email thing. 15:20:50 phrobb: gzhao Will do that this morning 15:20:51 i already pushed the intial patch to openflowplugin 15:20:54 alagalah: thanks 15:21:02 #link https://git.opendaylight.org/gerrit/#/c/13879/1 15:21:06 I would like to suggest that we turn on clustering for the odl-mdsal-broker by default soon. I am told that it works correctly in single node mode, and thus the controller would be out of the box cluster able. 15:21:10 alagalah: GBP only need update link of release plan 15:21:11 I am working on GBP OC renderer which will map policy in Juniper Opencontrail controller.. Can I get some documentation about yang data modelling being done 15:21:33 #info vishnoianil working on moving nsf to openflowplugin - has pushed the initial patch to openflowplugin 15:21:35 edwarnicke: +1 on clustering by default 15:21:42 gzhao: Ack that but I see that OpFlex isn't tracked but deadline is tomorrow for OpFlex to announce intent to participate in SR so I will do both at same time 15:21:45 #link https://git.opendaylight.org/gerrit/#/c/13879/1 15:22:04 abhijitkumbhare: what—if any—is the impact on other projects? 15:22:15 # am working on transition of plugin2Oc from ad-sal to md-sal....I have one query is INeutronAware interface is available as a provider services so that the same can be implemented by any SB plugin and hence follow MD-SAL provider/consumer architecture.. ? 15:22:15 I mention it because it *should* just be a transparent change... odl-mdsal-broker becomes odl-mdsal-broker-localonly, and odl-mdsal-broker picks up clustering... but wanted others thoughts 15:22:16 #info NSFs affected statistics-manager/forwarding rule manager/inventory manager etc 15:22:47 sheena_: currently not... but there is plan to make neutron MD-SAL ready 15:22:50 ttkacik__: Is controller ok with the flow stuff moving to OFplugin? 15:23:04 alagalah: did you see sachi's request? 15:23:23 ok thanks...:) 15:23:29 edwarnicke: yes... we also planned to propose this but ofplugin folks were faster 15:23:33 edwarnicke: i believe we discussed in mailing list, and i didn't see any -1 for that 15:23:45 phrobb: Yes and I have been unicasting her before and during the meeting. Sachi I believe your request is intra-project, and I've discussed with you a plan. I hope that is sufficient for now 15:23:58 I recall it being discussed, and I'm hugely supportive (see my patchwork in that direction... just wanted to make sure we minded our p's and q's ;) 15:24:06 thanks alagalah 15:24:18 edwarnicke, totally agree :) 15:24:20 colindixon: From what we discussed in the OF plugin meeting sometime ago - there may be some testing needed from projects - vishnoianil can you expand on this? 15:24:21 sheena_: Ping me on IRC offline and I'll help you get the neutron stuff cleared up :) 15:24:38 #info edwarnicke says he’d like to see us move to using the clustered md-sal-broker by default at some point soon, it should be transparent, but people should be aware 15:24:50 sheena_: I did the work to make neutron not depend on the AD-SAL pieces, and it should be pretty easy (*almost* transparent) for you to migrate ;) 15:25:08 #link https://bugs.opendaylight.org/show_bug.cgi?id=1674 for LBaaS need to be fixed. This will be needed for plugin2oc implementation 15:25:13 sheena_: there is also *some* disuscussion of md-sal native Neutron interfaces 15:25:19 #info edwarnicke will be sending email for these things to the lists as well (its nice to talk in IRC, but we should get it out to email too) 15:25:35 sheena_: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Neutron_RESTCONF 15:25:41 colindixon: Would it make sense to move those discussions to a cross-project neutron call? 15:25:50 ok _ :edwarnicke 15:25:53 Since there are multiple projects with an interest in the subject? 15:25:56 edwarnicke: likely 15:26:08 edwarnicke: when you use terms like "these things" in #info messages, it's quite the mystery when you read them later :-) 15:26:10 edwarnicke: I do not believe clustering is ready to be the reference implementation yet 15:26:11 #info sheena_ asks about how to move the MD-SAL and still use INeutronAware 15:26:17 colindixon: Could you take the AI to organize such a call? 15:26:24 colindixon: what???? 15:26:25 #info edwarnicke notes that phrobb said something about something 15:26:27 ;) 15:26:31 lispflowmapping is also intrested in moving from AD-SAL-based Neutron to MD-SAL 15:26:34 LOL 15:26:44 phrobb: I will endevour to do better, thank you very much for the correction ;) 15:26:51 * edwarnicke couldn't resist the counter tease though ;) 15:27:24 #info edwarnicke says that INeutronAware has been moved to be not AD-SAL dependent, but merely OSGi bundles 15:27:34 lori: Cool... ping me offline and we can get you through the initial steps to break off the AD-SAL bits pulled into lispflowmapping by neutron 15:27:38 * edwarnicke should really do a wiki page... 15:27:52 #info regXboi says as far as INeutronAware is concerned that is how it should be 15:27:52 edwarnicke: thanks, will do 15:27:59 happy to see project are planning to migrate to md-sal 15:28:07 * edwarnicke thanks regXboi for his help in getting it done :) 15:28:08 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:Neutron_RESTCONF colindixon notes that there has been some work on building an MD-SAL native Neutron bindings 15:28:15 phrobb: colindixon gzhao May I make a format suggestion ? 15:28:39 colindixon: that link is a BAD idea 15:28:41 edwarnicke: I’d rather not take the #action, but I may delegate 15:28:53 alagalah: of course 15:29:16 phrobb: colindixon gzhao I'll make a few and I'll start with a SYN and finish with a FIN :) 15:29:41 regXboi: we should probably take that offline, greg hall and some others have been working on it, but what’s the one-line version? 15:30:01 SYN : 1. Publish a wiki page for agenda, where folks can pre-populate with questions for other projects (why not just email? Cos if its structured it may get others asking the same question they hadn't thought of). 15:30:10 neutron interface is evolving outside our control - encoding it in yang is not something I get behind 15:30:16 alagalah: I hope you wont wait for an ACK after each message ;) 15:30:17 2. Make sure the agenda is up front and reviewed so people know what is coming up so they can wait on questions 15:30:19 FIN 15:30:22 that's the one liner 15:30:49 alagalah: Excellent suggestions 15:30:50 at least somebody is going to have to explain *why* it's a good idea 15:30:52 regXboi: I think the goal is not to make YANG map directy to the Neutron interface, but to get as close as we can and then deal with the rest in a shim layer that is as thin as possible 15:30:55 alagalah: +10 15:31:15 colindixon: let's take it off line, but that's not how I read that wiki page 15:31:27 phrobb: colindixon If it pleases the court :) I can have a stab at making a page... just give me a good root location 15:31:52 alagalah: Let's work offline to put one up together 15:32:00 #info alagalah suggests that for future meetings we use a wiki page to generate an agenda ahead of time so that we can aggregate similar concerns and to let people review them to be better prepared 15:32:07 #action alagalah to take stab at making agenda wiki page for M1 cross-project meetings (working with phrobb) 15:32:11 * regXboi delegates :) 15:32:12 thanks regXboi 15:32:39 colindixon: somebody made the mistake of giving me chair privs (evil laugh in background) 15:32:48 colindixon: I need a good root location 15:33:03 gzhao: thoughts ? 15:33:15 regXboi: the logic is that—given the state of maintanence of the AD-SAL—we want to have the state for Neutron be an MD-SAL construct at some point and given that you likely want to do it as soon as possible 15:33:21 alagalah: I like the wiki idea 15:33:26 Lithium_Release:Cross_Project_Meetings:Agenda? 15:33:27 alagalah: We'll probably hang it off the Lithium Release plan page somewhere 15:33:38 regXboi: DONE! Thanks 15:33:52 colindixon: Neutron should be SAL agnostic! 15:34:01 #action colindixon to set up a thread/meeting with stakeholders from Neutron related projectecs about the proposed MD-SAL neutron interface 15:34:13 regXboi: +1 at the top layer 15:34:34 in fact, I'll go further... ALL NB should be SAL agnostic 15:34:35 regXboi: at some point it has to be SAL dependent and the question is just how much lives above vs. below that line 15:34:37 alagalah phrobb - may be a google doc may be better - as it will have more protections against people overwriting previous changes than a wiki 15:34:57 abhijitkumbhare: I'll consider it but both have tracking 15:35:06 +1 to wiki 15:35:09 Any further announcements 15:35:09 keep it in house 15:35:10 regXboi: we should probably take this offline to a thread, but the truth of the matter is that nearly all of our NB interfaces are now MD-SAL specific 15:35:22 Yes - but with a wiki it is easier to stomp on other folk's changes 15:35:22 regXboi: +1 ... then we could have neutron to md-sal transformation...and providers which will work with md-sal neutron model 15:35:25 colindixon: I already said we should go offthread 15:35:30 abhijitkumbhare: wiki has history too 15:35:32 +1 to Wiki 15:35:36 because I frankly don't agree with that 15:36:03 … Last Call for Annoucements 15:36:13 regXboi: I have some thought I think may be in line with your concerns 15:36:21 regXboi: We should talk offline and bring it to the meeting 15:36:27 Well google docs folks can edit simultaneously - wiki only one version will get saved 15:36:29 edwarnicke: agreed 15:36:42 #topic Any Questions on what should, or should not be in your Lithium Release Plan 15:36:55 for LBaaS there is bug https://bugs.opendaylight.org/show_bug.cgi?id=1674 , which needs to fixed for LBaaS v2 to be working correctly 15:38:29 deepankar: that bug is misfiled 15:38:39 neutron is NOT part of ovsdb, it's part of controller 15:39:30 but seems like it's assigned to srini 15:40:20 vishnoianil: bugs should follow code, not humans ;) 15:40:35 (meaning, we can assign it to srini in whatever the appropriate place for the bug to be filed is ;) ) 15:40:45 edwarnicke is correct 15:40:49 yeah unfortunately we need human to write that code 15:41:04 vishnoianil: Sure... but anybody can submit a patch anywhere ;) 15:41:14 phrobb: I think the answer is no, but my guess is that some will emerge from looking over release plans as we move forward 15:41:35 colindixon: I would say "no for now" 15:41:39 Yep agreed colindixon 15:41:43 but I agree with the rest of the statement 15:41:48 phrobb: we should probably encourage projects to look at others release plans 15:42:11 I think you just did :-) Want to #info it? 15:42:45 edwarnicke: generally people don't pick up the bugs that's already assigned, so time to move it to controller and keep it open for takers :) 15:43:03 vishnoianil: We can assign controller bugs to srini ;) 15:43:12 #info projects are encouraged to review other projects release plans to look for places where cross-project friction might occur 15:43:30 thanks 15:43:30 phrobb: does that work? 15:43:37 edwarnicke: i was pointing toward what if current taker is missing ;) 15:43:57 colindixon phrobb gzhao - may be in the action items tracked for each project we should have one whether dependencies on other projects have been conveyed and have been acked 15:44:00 I think it’s more general than that, but it works, I think if people scan realease plans they will find things 15:44:00 regXboi: phrobb colindixon I shall make it an agenda item on the wiki with a lijnk to gzhao spreasheet with has links to the rp's 15:44:11 alagalah: works for me 15:44:18 #info, it will be very important for cross-project tracking that all projects read and understand the release plans of projects within their "dependency path" Also, any features or bugs that need to be implemented/fixed should be documented in the dependent release plans so that everyone knows, and can track those items. 15:44:24 I have a general question on feature-complete projects' release plan ;-) 15:44:43 vishnoianil: apologies... I totally misunderstood ;) 15:45:01 rovarga: go for it 15:45:05 specifically, tcpmd5 is feature-complete and all it can really do in this release is to reorganize structure, add maybe a few tests and and improve documentation 15:45:50 #info abhijitkumbhare suggest in the action items tracked for each project we should have one whether dependencies on other projects have been conveyed and have been acked 15:45:58 so aside from the general documentation requirements we have not much to put into the release plan 15:46:15 (which really was the point of splitting it out) 15:46:44 rovarga: I think it’s find to have no project-specific deliverables other than to fix bugs 15:46:50 fine 15:47:33 @colindixon: for these type of projects should they be encouraged to a new project lifecycle? 15:47:39 phrobb: colindixon maybe project dependency acked should be added to M2 15:47:46 Last call for release plan questions 15:48:25 gzhao: Yes, let's at least make it part of the M2 Report Out template 15:48:35 I would suggest we should have section on main page of each project where other project can list themselves as dependency 15:48:48 vishnoianil: I like that idea 15:48:54 it will be easy for the project tech to communicate any major change that's going to be effect them 15:49:05 really having a dependency graph which people check is good, but also putting it on the wiki isn’t bad either 15:49:10 +1 for the idea 15:49:23 at openflowplugin we had a discussion to proactively share our agenda to all the dependent project 15:49:24 gzhao: could you make a graphviz (or whatever) dependency diagram again as you gather information? 15:49:40 * edwarnicke wonders if we could derive the project dependency graph automagically from the JJB stuff 15:49:41 just to save the last time issues which we had in helium release 15:49:56 zxiiro has helpfully put a mechanism where you can just list the projects you depend on and your integration job runs 15:49:57 colindixon: will do 15:49:58 edwarnicke: probably, but we'd need more projects in there first 15:50:04 colindixon: gzhao I would ask that this time for the dependency tree its in google draw (ie edittable) 15:50:13 zxiiro: Who still needs to migrate? 15:50:44 #info alagalah asks: colindixon: gzhao I would ask that this time for the dependency tree its in google draw (ie edittable) 15:51:01 (only did that cos I am going to use these minutes to help structure the agenda on the wiki etc) 15:51:12 * regXboi asks if we expect to run past the top of the hour? 15:51:14 If you look at the tabs at the top, those are the projects have have migrated: https://jenkins.opendaylight.org/releng/ 15:51:42 phrobb: did we have other topics for today? 15:51:44 #topic Meeting Cadence and Schedule for next Cross-Project IRC Meeting 15:51:48 edwarnicke: there's still quiet a few projects who have not yet. I've been reaching out to a few projects at a time to try to help them move 15:52:12 There have been three options brought forth thus far..... 15:52:37 * regXboi waits for phrobb to list 15:52:38 1 - Alternate 7am and 7pm PST Wednesday mornings 15:52:56 #info patch for the proposed neutron yang model: https://git.opendaylight.org/gerrit/13970 15:53:11 2 - Hold two meetings each week, 7am and 7pm each Wednesday 15:53:45 phrobb: preference for 1 mtg per week, alternating 15:54:02 phrobb: (option1) 15:54:03 3 - Hold fixed meeting time at 6am (or 6:30am) PST we Wednesday 15:54:18 I think I would prefer 7am PST wed morning and 7pm PST tues night instead - that way we can schedule 1 and if need be go with 2 15:54:23 * alagalah should learn to read... sigh... srry 15:54:34 Does anyone want to suggest another time schedule before we vote on these three? 15:54:59 last call for other alternatives.... 15:54:59 As I said I prefer option 3 as I think the only timezone for whom today’s meeting time of 7 am Pacific is not suitable would be somewhere between Japan and Alaska. 15:55:07 phrobb: I have an alternative 15:55:17 ok regXboi 15:55:20 7pm PST will be really hard for those in Europe, as it will be 4am 15:55:26 I prefer 3 15:55:35 Yes - that's my feeling ebrjohn 15:55:36 I prefer option 3 15:55:53 I had a general question, if we're near the end of the agenda 15:55:57 option 3 15:56:05 I propose alternating between 7am Wed morning and 7pm Tues Evening - that way if after the 7pm Tues Evening meeting there are open issues, a second meeting on 7am Wed morning can be held 15:56:06 that question on 3 is will we get enough U.S. west-coasters 15:56:23 I can say flat out that I will NEVER be able to make #3 15:56:30 and I'm not a US west coaster 15:56:41 #3 won't work for me either 15:56:45 (re timezones, I will repeat my suggestion to avoid real-time meetings where possible, with a suggestion to alternate times by 12h every week) 15:57:11 So option 1 as the best of the options 15:57:12 regXboi: 7pm will not work atleast for yangtools, controller, bgpcep, openflowjava 15:57:14 Option 3 can be modified to 7 am Pacific (instead of 6 am or 6:30 am) 15:57:26 as ebrjohn pointed out, 7pm PST is impossible for Europeans 15:57:26 ttkacik_: that is why I want to alternate 15:57:47 7am PST will be better than 6:00 15:57:58 regXboi - whom exactly are we alternating it for? 15:58:07 which timezone? 15:58:14 OK so now there is a fourth option as well: 4 - alternating between 7am Wed morning and 7pm Tues Evening - that way if after the 7pm Tues Evening meeting 15:58:42 abhijitkumbhare: I have a general preference for spreading the pain - if I had my druthers, I'd rotate on 3 8-hour separations 15:58:53 if we are going to alternate, will 9am and 9pm PST meeting slots work/ 15:59:08 +1 to changing option 3 to 7am 15:59:21 Alternate time is convenient for team in India... 15:59:21 9 pm Pacific is 12 am EST 15:59:32 curious - who is "left out" at this time slot? (7am PST) 15:59:41 exactly bigalh 15:59:53 Week One: 7:00am PST (4pm Slovakia, 8pm Bangalore, 11pm Shenzhen, Midnight Tokyo) 15:59:54 Week Two: 7:00pm PST (4AM Slovakia,, 8am Bangalore, 11am Shenzhen, noon Tokyo) 16:00:13 7am is tough for Japan 16:00:25 bigalh: 7am it rought for Japan/Australia/New Zealand 16:00:27 thanks for the clarification 16:00:49 Isnt Bangalore 3 1/2 hours ahead of Europe?? 16:01:01 also Hawaii 16:01:02 bigalh, Some West coast, Australia, tough for China & SE Asia (some people have families, etc, and 10pm or 11pm meetings really are not nice) 16:01:32 7 AM PST is 8.30PM bangalore 16:01:37 regXboi: Do we have folks in Hawaii? ;) 16:01:52 edwarnicke: should we call for volunteers? :) 16:02:15 so, should we do a poll 16:02:18 via doodle or something? 16:02:22 regXboi: we should base time on interested parties 16:02:29 ttkacik__: no 16:02:29 I don’t see how else we’re going to resolve this 16:02:30 colindixon: yes 16:02:30 phrobb - why don't we try 2 meetings next week and see how it goes? 16:02:34 which pretty much are project leads + tsc 16:02:38 I know consensus is tough on this question, but should be put it to a vote? We can do it here or I can start a condorcet poll 16:02:42 that's a circular argument 16:02:43 ttkacik_: The problem with that is that it's a self fulfilling prophesy 16:02:44 colindixon: +1 for poll 16:02:45 for project tracking meeting 16:02:50 dneary: +1 16:02:51 phrobb: doing it here has a huge sampling bias 16:03:04 ttkacik_: who will want to sign up to a project that expects you to attend 3am meetings to participate fully? 16:03:17 dneary: Its only the project leads 16:03:21 dneary: I understand that 16:03:22 colindixon: yea, you've got a good point 16:03:41 alagalah: how would want to *lead* a project that expects you to attend 3am meetings on a regulare basis? 16:03:44 colindixon, Has the project ever used mailing list voting? 16:03:47 * regXboi shudders 16:03:50 regXboi: no one said regularly 16:04:07 regXboi: It seemed like option2 was getting the most traction 16:04:07 as far as I am concern, 6:00am is as bad as 12:00am, could we add 7:00am PST fix option for voting 16:04:08 Alright, I'm going to run a condorcet poll for TSC members and Project Leaders only 16:04:15 alagalah: ... once a precedent is set .... 16:04:26 regXboi: yep, genie, bottle, got it 16:04:38 dneary: we have 16:04:41 alagalah: actually, my preference would be for #2 as well 16:04:46 gzhao I'll add that as an option 16:04:56 that just requires *somebody* to be on both meetings (shudder) 16:04:57 regXboi: Well your option4 which is an augment of #2 but same deal, like it 16:05:02 phrobb: thanks 16:05:12 regXboi: Well it would be offset a 12hours and a week 16:05:13 and I suggested option 4 so that I could be one of the people to make both 16:05:37 Condorcet will give us the "most liked" option since folks can rank them… 16:05:42 option 2 as it stands - I can't make 7pm PT wed nights - that's a standing block until May 16:05:47 regXboi: net net, I'm good with just voting on an option given in the poll 16:05:56 We are out of topics… Any last comments/questions before we adjourn? 16:06:00 alagalah: +1 16:06:00 regXboi, colindixon, phrobb: If there are 2 meetings per week, what is the attendance expectation? 16:06:13 phrobb: did you take the action item to set up the poll? 16:06:15 dneary: I would expect a project lead to make one of them 16:06:25 Should everyone attend both, or attendance be agenda driven, or is there one meeting for US & Europe, and another for Europe & Asia? 16:06:35 I would expect TSC members to do their best to make both 16:06:35 dneary: What we did in the past that worked was run two meetings a day 16:06:37 phrobb thanks (for the condorcet poll) 16:06:39 #action phrobb to make a condorcet poll for meeting timing 16:06:42 dneary: Folks mostly attended just one 16:06:43 phrobb: also, presumably we should have two polls one of project leads and one of everyone since—unfotuantely—the first matter more 16:06:48 regXboi, And certain people would be expected to attend both? 16:06:49 dneary: Some fearless folks attended two 16:06:57 dneary: TSC folks 16:07:03 dneary: If something needed deciding, it ping ponged around once 16:07:08 dneary: It worked well for *daily* meetings 16:07:15 dneary: Not sure how it will work for weeklies 16:07:16 dneary: and anybody else who had a masochistic streak 16:07:24 :) 16:08:02 colindixon: two polls? Why? We need to know the preference of the projects (project leads voting) and the TSC members, right? They are the essential participating parties 16:08:29