17:00:48 <colindixon> #startmeeting tsc
17:00:48 <odl_meetbot> Meeting started Thu Oct 22 17:00:48 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:00:48 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:48 <odl_meetbot> The meeting name has been set to 'tsc'
17:00:54 <colindixon> #topic roll call and agenda bashing
17:00:56 <dlenrow> #info dlenrow
17:01:05 <colindixon> #info colindixon
17:01:15 <jmedved> #info jmedved
17:01:31 <colindixon> #link https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=37793#Agenda the agenda in it's usual place
17:01:40 <colindixon> #link https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-10-15-17.02.html last week's meeting minutes
17:01:45 <mohnish> #info mohnish anumala
17:01:58 <colindixon> #action colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR3) https://bugs.opendaylight.org/show_bug.cgi?id=3160
17:02:27 <colindixon> #action ttcacik and zxiiro to work on getting feature-level code coverage numbers
17:02:31 <colindixon> #action colindixon to figure out where we lost action items, e.g., feature-level code coverage and make sure we didn't lose any others
17:02:32 <edwarnicke> #info
17:02:35 <edwarnicke> #info edwarnicke
17:02:45 <edwarnicke> Anyone else having trouble getting on the webex?
17:03:00 <afredette> I'm on
17:03:27 <colindixon> edwarnicke: I got on the webex just fine
17:03:30 <lori> edwarnicke: yes, can't get on
17:03:39 <dfarrell07> #info Daniel Farrell
17:03:49 * edwarnicke grumble grumble
17:03:51 <ebrjohn> Am I the only one that cant connect to Webex?
17:04:00 <giorgiogarziano> yes, the link to webex does not work for me
17:04:02 * edwarnicke is now on webex
17:04:12 <lori> edwarnicke: "We've hit a glitch in processing your request. Try again later."
17:04:14 <zxiiro> works for me
17:04:16 <abhijitkumbhare> edwarnicke: ebrjohn - others are OK
17:04:26 <ebrjohn> I get this error: "We've hit a glitch in processing your request. Try again later."
17:04:45 * ebrjohn wondering who says glitch anymore...
17:04:48 <LuisGomez> #info LuisGomez
17:04:58 <edwarnicke> Did anyone hear me?
17:05:11 <tykeal-> edwarnicke: no
17:05:24 <giorgiogarziano> I get "the webex meeting was not found"
17:05:27 <colindixon> lori: are you in?
17:05:52 <lori> colindixon: no, I'll try loggin in as guest, maybe the problem is trying with my user
17:05:56 <colindixon> giorgiogarziano: were you able to get in?
17:05:57 <alagalah> Folks if you have issues joining, please ensure you aren't using a local Calendar copy and go  to   https://meetings.webex.com/collabs/meetings/join?uuid=MA3SRND964PIX06V2LS3SXX3RE-9VIB
17:06:13 <colindixon> #topic mailing list votes and discussions
17:06:26 <jamoluhrsen> colindixon, do you want to add a quick vote to move old integration project to abandoned state?
17:06:39 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2015-October/004026.html platinum designate bylaw waiver discussion
17:06:59 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2015-October/004021.html requirements to remain in a release w.r.t. autorelease
17:07:33 <lori> colindixon: joining as guest helped
17:07:40 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2015-October/004032.html should we  meet next week despite OpenStack Tokyo next week?
17:08:00 <edwarnicke> Is colindixon 's audio coming and going for anyone else?
17:08:03 <ChrisPriceAB> #info Chris Price
17:08:04 <rovarga> sorry to be late, what is the meeting URL?
17:08:15 <lori> rovarga: https://meetings.webex.com/collabs/meetings/join?uuid=MA3SRND964PIX06V2LS3SXX3RE-9VIB
17:08:55 <rovarga> lori: thanks, I thought that ... but gives me 'This meeting was not found and may have been removed.'
17:09:16 <alagalah> Ok folks I clicked on the link and it worked for me so seems to be a system problem
17:09:59 <alagalah> FYI folks on IRC only, discussion about cancelling next weeks TSC due to OS
17:10:11 * edwarnicke resisted the urge to encourage counting in hex
17:10:11 <colindixon> #agreed there will be no TSC meeting next week due to OpenStack in Tokyo
17:10:12 * ChrisPriceAB wonders what happened to 1, 2, 3, & 4
17:10:19 <dlenrow> Will be awake, but not in meeting mood
17:10:31 <ChrisPriceAB> :D
17:10:33 <colindixon> #topic events
17:10:58 <colindixon> #link https://www.opendaylight.org/global-events events in the usual place
17:11:03 <edwarnicke> Did anyone else just loose audio?
17:11:07 <colindixon> edwarnicke: no
17:11:42 <edwarnicke> Hmm...
17:11:44 <abhijitkumbhare> edwarnicke: I guess the webex is just a bit unreliable today for some of you folks
17:11:44 <colindixon> #link https://aws.passkey.com/g/43882140 register for the hackfest
17:11:48 * edwarnicke is suspecting it may be him
17:12:15 <colindixon> #topic beryllium
17:12:23 <lori> edwarnicke: no audio issues here
17:12:32 <colindixon> #info we have one offset 0 project with no M4 (odlparent)
17:12:52 <colindixon> #info we have 10 projects missing for M3, anipbu is contacting them
17:13:39 <colindixon> #info we have made a lot of project on autorelase, but we still have two projects which can't be added back into autorelease: NIC and VTN due to dependencies on AD-AL
17:14:18 <colindixon> #info currently integration is failing to build because of dependencies on features that no longer exist, there are mailing list threads working on solving that
17:15:20 <colindixon> #info benchmarks from coretutorials are going to be created in controller to provide the tests for integration
17:15:32 <colindixon> #info LuisGomez says they really need that by M4
17:15:48 <colindixon> #action jmedved to talk to ttkacik about how to get the benchmarks into controller by offset 2 M4
17:15:49 <rovarga> is there an issue tracking that requirement?
17:16:39 <colindixon> #link https://wiki.opendaylight.org/view/Weather#Current_Weather_Report current weather report, anipbu says nothing that needs to come up here
17:17:06 <colindixon> #action anipbu will open a bug against controller to move the benchmark tools there by M4 offset 2
17:17:43 <alagalah> rovarga, Can we get a link here please ?
17:18:30 <colindixon> #link https://wiki.opendaylight.org/view/Weather#Implementation_of_RFC6020_structural_container_lifecycle rovarga says that the patches fro BUG 2399 are coming in and projects should test if they can, they've tested integration tests without issues
17:18:52 <colindixon> #action rovarga to add BUG 2399 to the weather page for the the structural issue
17:19:16 <colindixon> #chair phrobb anipbu
17:19:16 <odl_meetbot> Current chairs: anipbu colindixon phrobb
17:19:24 <colindixon> #topic stable/lithium
17:19:45 <colindixon> #info autorelease is currently breaking while trying to build AAA, there's an e-mail thread trying to diagnose it now
17:22:11 <colindixon> #topic autorelease
17:22:29 <colindixon> #info zxiiro says that autorelease for beryllum is making it to integration
17:22:32 <colindixon> #undo
17:22:32 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x252b150>
17:23:14 <dfarrell07> #link https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-06-18-17.00.log.html#l-159 Java 8 #agreed
17:23:57 <tykeal-> that's what I remember as well
17:24:52 <colindixon> #info zxiiro says that autorelease for beryllum is making it to integration consistently which is expected until M4 when VTN can drop it's dependecies on the AD-SAL
17:25:28 <colindixon> #info rovarga asks how we're doing on moving to JDK8?
17:28:17 <colindixon> #info zxiiro suggests that we just JDK8 tests out to projects
17:28:42 <colindixon> #action alagalah to provide instructions on how to switch from Java 7 to Java 8 and back to test if your project works with Java 8
17:29:58 <colindixon> #action anipbu to add a readout on whether you build with Java 8 and wehther you have jdk8 verify, etc. jobs to the M4 readout and not the if you don't by RC time, you will be dropped
17:30:02 <colindixon> #undo
17:30:02 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x240dbd0>
17:30:09 <colindixon> #action anipbu to add a readout on whether you build with Java 8 and wehther you have jdk8 verify, etc. jobs to the M4 readout and note the if you don't by RC time, you will be dropped
17:31:27 <colindixon> #action zxiiro to create a beryllium-jdk8 autorelease job (replacing the lithium-jdk8 release job)
17:32:00 <colindixon> #topic system integration & test
17:32:35 <colindixon> #Info it's been two weeks since the termination review was posted
17:32:51 <jamoluhrsen> #link https://wiki.opendaylight.org/view/Archive_Proposals/Integration
17:32:55 <edwarnicke> Just lost audio again :(
17:32:59 <edwarnicke> And its back
17:33:11 <dfarrell07> #link https://lists.opendaylight.org/pipermail/tsc/2015-October/003966.html Integration (pre-split) project termination request email
17:33:33 <colindixon> #info system tests are passing, but when people are loading lots of features locally, lots of weird things are happeneing
17:34:56 <colindixon> #info for example, when jamoluhrsen loads compatible-with-all his controller goes out to lunch for an hour and seems to eventually come up, but with some omenous log messages
17:35:29 <colindixon> #info LuisGomez says that even with only 2-3 features that used to work before, Karaf will hang and there are memory issues that weren't there befomre
17:35:48 <colindixon> #info rovarga would like to see a memory dump when/if there's an OutOfMemory issue
17:36:29 <colindixon> #Info rovarga suggests for karaf hangs, using Yourkit to see where it's hung might help
17:36:39 <colindixon> #topic infastructure
17:37:07 <colindixon> #info tykeal- is working slave images that have been having issues
17:38:10 <colindixon> #info alagalah asks about ubuntu images in the sandbox, tykeal- says he's stuck because they can install docker in vagrant, but when they snapshot it, it won't come back up with networking because docker doesn't come up well
17:38:56 <colindixon> #info tykeal- notes that this is just an issue on how docker installs with an unattendend install on Ubuntu, it works with an attended install, and it works on RHEL
17:40:14 <colindixon> #topic dealing with upstream/downstream breakages
17:40:20 <dlenrow> Debugging by committee from your TSC
17:43:16 <colindixon> #info alagalah says that, more tactically, he was unable to write any code for 1.5-2 weeks, should we extend the release to the back end
17:45:11 <colindixon> #info ebrjohn (Brady) says we desperately need to be able to roll back in an easlier way, instead in his experience as a later offset proejct it's nearly impossible to roll back and make progress
17:46:46 <colindixon> #info ebrjohn and abhijitkumbhare suggest doing more frequent mini-releases
17:49:39 <colindixon> #info anipbu asks would it be enough to have a relase per milestone, ebrjohn says it's a step forward, but wouldn't fix things entirely
17:50:06 <alagalah> Soooooo we add 2 weeks to the M4 and offset from there ?
17:50:08 <alagalah> :)
17:50:24 <colindixon> #info edwarnicke says if we could get autorelease to run consistently and then we could have tools to roll forward and backward through time with consistent versions across all projects
17:51:28 <alagalah> abhijitkumbhare, I like the nightly build idea, would this be a git tag ? We could script that, and it may slow down merges (since I assume the gerrit system wouldn't be using those tags) but that would be a nice quick thing to do
17:52:38 <colindixon> #link https://lists.opendaylight.org/pipermail/release/2015-October/004111.html RPenno's comments on the issue
17:53:45 <alagalah> ^^^^^^^^^^^^^^^^^ THIS
17:54:59 <colindixon> #info edwarnicke says the productive convesation here is to look at how to fix this issue tactically in the short term, e.g., until we get rollback and CR working, which is real work and won't happen immediately
17:55:16 <ebrjohn> +1
17:55:27 <colindixon> #info ebrjohn agrees and says "sometimes shit happens" and what we really need is ways to fix it later
17:55:53 <edwarnicke> #info focus on how to fix shit faster when it happens, reduce the probability of shit happening
17:56:05 <ebrjohn> thanks for literally quoting me on that one ;)
17:56:21 <colindixon> #info rovarga says what offset 0 projects could really use a CSIT red/green test to figure out what is breaking things or not
17:58:21 <rovarga> #link https://git.opendaylight.org/gerrit/17030 shows the way we can see how CSIT reacts to a single patchset
17:58:29 <colindixon> #info integration is working on trying to figure out how to avoid having tests that are failing so that it's easlier to tell whether things are breaking because they always break or because of something new
17:58:37 <abhijitkumbhare> colindixon: I think we may also need the upstream projects in some cases rolling back changes when shit happens - before moving with fixing the issue
17:59:40 <colindixon> abhijitkumbhare: +1
17:59:44 <colindixon> can you say that outloud
17:59:50 <abhijitkumbhare> yes
18:00:47 <colindixon> #info LuisGomez notes that that CSIT doesn't catch everything as many projects don't have very high coverage
18:01:01 <ghall> Offset 0 merges ... shit flies ... revert!
18:01:03 <colindixon> #info colindixon also notes that CSIT without full build, e.g., autorelease, will miss a whoe other category of issues
18:01:17 <rovarga> ghall: and re-try when? :)
18:01:51 <ghall> When Offset 0 & affected folks have a resolution.
18:02:00 <colindixon> #info abhijitkumbhare says that another suggestion is that sometimes offset 0 and offset 1 projects should consider reverting patches when "shit happens"
18:02:04 <ebrjohn> Just want to make sure we dont drop the topic of adding 2-3 weeks onto the end of the project
18:02:16 <rovarga> ghall: sure, which boils down to downstream engagement Ed just mentioned
18:02:20 <ghall> The current approach doesn't seem to be frustrated by the downstream productivity loss ... to put it nicely.
18:03:23 <colindixon> #info edwarnicke asks when we should revert and how to deal with remediation
18:03:50 <dneary> Isn't there a way to do invasive patch integration first on a branch, and then only merge to trunk if nothing breaks?
18:04:08 <alagalah> Actually its more tricky than that
18:04:18 <ebrjohn> dneary: I think the best solution would be to have more/better testing in place
18:04:26 <rovarga> dneary: see that 17030 link -- the problem is unless you know 50 projects and the state of the test suite, you cannot analyze the result of that test
18:04:56 <alagalah> What happens if a upstream change breaks one project in a fixable way but another project in another unfixable way? first project patches, merges, carries on.... but now upstream reverts.... and now that project has to revert etc.. etc... etc..
18:05:13 <colindixon> #info mohnish says that there may be times where this level nuance (e.g., we need to have both projects engaged and a real dialog to decide if we should revert) isn't needed, e.g., when everyone is having issues
18:06:43 <colindixon> #info edwarnicke says there was an example where an upstream project took heisenbugs and made them predictable, that broke downstream people and if they were allowed force upstream projects to never fix it, it woudl have caused real problems
18:06:55 <colindixon> #info phrobb suggests a timeline way to deal with when you roll patches back forward
18:07:37 <dneary> ebrjohn, Testing where, I guess is my question. If there's measurable breakage, then the question is how we can reduce the risk of that breakage stopping everyone else's work
18:08:41 <abhijitkumbhare> fair point rovarga (scaling issue with respect to number of devs)
18:09:11 <colindixon> #info rovarga says that we need to look at how we analyze breakages, i.e., he says there are 12-15 offset 0 developers, and there are 50ish downstream projects, so requiring every breakage be analyzed by offest 0 people won't scale
18:09:49 <colindixon> #info rovarga calls for bettter error reporting, e.g., with logs, and preliminary analysis
18:10:39 <ebrjohn> better error reporting is a very reasonable request
18:11:46 <RPenno> We will probably run out of time without any concrete measures. So, can we get those 2-3 weeks of development back as a short term measure.
18:12:40 <colindixon> #info ChrisPriceAB says that there will always be corner case, and we can talk about them and they may or may not help the general case
18:12:50 <colindixon> #info ChrisPriceAB says he like to a see a cuture over process here
18:13:06 <ebrjohn> dneary: for starters, maybe the upstream projects could test with all the downstream YANG files
18:13:23 <colindixon> #Info edwarnicke suggests that at the very least we need to have instructions to reproduce the bug for it to be taken seriously
18:14:10 <colindixon> #info edwarnicke says that absolutely, if the world is broken, revert the patch quickly
18:14:18 <ChrisPriceAB> that would be a useful CI test case ebrjohn
18:14:56 <colindixon> #info edwarnicke also says that if the patch turns up bugs, and peopel don't engage to fix them downstream, then we shouldn't hold back because they don't engage
18:15:20 <abhijitkumbhare> +1 ChrisPriceAB about the culture over process
18:16:23 * ChrisPriceAB contemplates Ed communicating poorly...
18:16:39 <ebrjohn> 2 weeks sounds like a long time to me
18:17:08 <colindixon> #Info rovarga says that if the world breaks, he's wllling to try to revert as long as there's a time limit on how long the patch stays reverted
18:17:27 <rovarga> ebrjohn: yeah, it's on the long end for my taste, I would like 1 week better
18:17:32 <colindixon> #info two weeks is suggested, but others say maybe that should be shorter or longer depending on teh bug and projects involved
18:17:34 <ChrisPriceAB> ebrjohn: comes back to being able to build against a label (+ patches)
18:17:41 <ebrjohn> if the reporter doesnt offer to help out in 4-5 days, I suggest going ahead and put the patch in
18:18:33 * ChrisPriceAB wants to write "#info colindixon asks the community for a world of trouble."
18:18:34 <rovarga> #info a good trade-off is need for time -- two weeks is probably the most tolerable without affecting upstream schedule
18:20:07 <phrobb_> pan-project defect resolution best practices
18:20:35 <edwarnicke> Is amused by pan :)
18:20:51 <colindixon> keith, mohnish, tony, anil, robert
18:21:14 <colindixon> ebrjohn, RPenno
18:21:20 <colindixon> abhijitkumbhare:
18:21:22 * ebrjohn I was thinking bread-project, in spanish pan=bread
18:22:48 <colindixon> #actoin rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
18:22:57 <colindixon> #action rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
18:23:03 <colindixon> missspelled action the first time
18:23:32 <colindixon> #info ebrjohn asks what about technical solutions again
18:24:05 <colindixon> #info ebrjohn asks if there was a way to take all the yang files in ODL and do some sanity check for offset 0, really yangtools
18:24:22 * ChrisPriceAB loves boiling the ocean, I'll bring tea-bags! :)
18:24:31 <phrobb_> we should let this new group also contemplate the tools/processes that we should add to reduce the frequency of bug/issue cascading from upstream to downstream projects
18:24:37 <ChrisPriceAB> Can we make sure that if an ODL model fails it generates a ticket of some sort
18:24:39 <ChrisPriceAB> ?
18:24:48 <colindixon> #info rovarga says in boron, the idea woudl be to have system test for yangtools that pulls in as many models as they can including both ODL yang files as well as from outside
18:25:40 <colindixon> #action rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare  should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages
18:26:28 <colindixon> #topic delaying the beryllium release
18:26:34 <edwarnicke> phrobb_: yep, and lets bias first towards what we can do most easily
18:26:46 <edwarnicke> like the revert stuff
18:26:50 <phrobb_> edwarnicke yep
18:26:56 <edwarnicke> without loosing the rest of it
18:26:59 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2015-October/003999.html
18:27:22 <edwarnicke> after all, we are engineers, architecting the technical stuff is more fun :)
18:28:08 <colindixon> edwarnicke: to be clear, the only point I wanted to make is that we really need a best practices document we can look at
18:28:18 <vina_ermagan> +1 for getting back the 1.5-2 weeks
18:28:21 <edwarnicke> colindixon: damn straight :)
18:28:35 <phrobb_> Can we get a guage of the impact of this delay?... what key features are now in jeapardy and are any of those features also relied upon by further down stream?
18:29:01 <edwarnicke> Its the balance of : do the best practices doc first because that looks fast and high return
18:29:12 <edwarnicke> But don't loose the other good ideas
18:29:54 <colindixon> #info colindixon and vishnoianil ask what are the consequences going to be if we *don't* grant the extension
18:30:17 <vina_ermagan> instability of API after the API freeze
18:30:35 <colindixon> #info alagalah says in his case, he thinks there will be real consequences, vina_ermagan and ebrjohn all say yes
18:30:50 <ebrjohn> I think that at least warants a vote
18:31:02 <phrobb_> colindixon yea that was my question as well?  Not just impact per project but also any cascading impacts from dependent features not getting done
18:31:46 <dfarrell07> It would be surprising to to me if the poll said "no more time"
18:31:54 <alagalah> Sure
18:31:57 <alagalah> 2 weeks
18:31:58 <ebrjohn> dfarrell07: +1
18:32:10 <vina_ermagan> colindixon: 2 weeks is good
18:32:11 <alagalah> M4 +2 weeks, everything water falls from there
18:33:31 <vina_ermagan> :))
18:34:22 <ebrjohn> I really need to drop off now
18:34:24 <colindixon> #info ChrisPriceAB says that the B release of OPNFV is shipping on Feburary 2nd regardless, ODL ships on February 5th
18:34:27 <colindixon> ebrjohn: thank you so much
18:34:34 <ebrjohn> Thanks for discussing this colindixon :)
18:34:39 <ebrjohn> talk to ya tomorrow
18:34:45 <alagalah> rovarga, Doesn dneary run that ?
18:35:23 <colindixon> #info rovarga asks do we have other downstream projects? if so we need a fast way to poll them?
18:37:08 <colindixon> #info phrobb_ says that we could also drop an RC (actually two) and keep the release date
18:37:29 <colindixon> #link https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan#Schedule the schedule for people's use
18:38:55 <colindixon> #info abhijitkumbhare asks if 2 weeks will be enough, will we have another breakage and have to delay again
18:39:59 <colindixon> startvote shall we delay the Beryllium release and it's relevant milestones by 2 weeks, -1 no, 0 not sure or need more information, +1 yest? -1, 0, +1
18:40:24 <colindixon> #startvote shall we delay the Beryllium release and it's relevant milestones by 2 weeks, -1 no, 0 not sure or need more information, +1 yest? -1, 0, +1
18:40:24 <odl_meetbot> Begin voting on: shall we delay the Beryllium release and it's relevant milestones by 2 weeks, -1 no, 0 not sure or need more information, +1 yest? Valid vote options are -1, 0, +1.
18:40:24 <odl_meetbot> Vote using '#vote OPTION'. Only your last vote counts.
18:40:27 <edwarnicke> Likes yest :)
18:40:28 <ChrisPriceAB> #vote 0
18:40:31 <colindixon> #vote 0
18:40:34 <dfarrell07> #vote 0
18:40:34 <mohnish> #vote 0
18:40:38 <edwarnicke> #vote +1
18:40:46 <LuisGomez> #vote 0
18:40:52 <jmedved> #vote  +1
18:41:07 * ChrisPriceAB thinks it's funny that Ed yests in public places...
18:41:10 <colindixon> #endvote
18:41:10 <odl_meetbot> Voted on "shall we delay the Beryllium release and it's relevant milestones by 2 weeks, -1 no, 0 not sure or need more information, +1 yest?" Results are
18:41:10 <odl_meetbot> 0 (5): mohnish, colindixon, LuisGomez, ChrisPriceAB, dfarrell07
18:41:10 <odl_meetbot> +1 (2): edwarnicke, jmedved
18:41:15 <edwarnicke> LOL
18:41:18 <ChrisPriceAB> :D
18:41:36 <alagalah> colindixon, No
18:44:01 <colindixon> #action phrobb_ to coordinate getting input from PTLs, OPNFV, ODL AG, and Marketing Group, by tomorrow ideally and Monday at the latest
18:44:18 <ChrisPriceAB> in transit to Tokyo, hound me there on Tuesday...
18:44:32 <phrobb_> yup
18:44:50 <vina_ermagan> So is two weeks a binary decision?
18:45:01 <colindixon> #info edwarnicke and jmedved prevote for extending by two weeks unless they actively retract it
18:45:10 <vina_ermagan> or of two weeks doesnt get approved, we can look at more moderate delay?
18:45:23 <dneary> Do I run what?
18:45:25 <ghall> If we extend ... are we increasing the window for core changes with all the risks?
18:45:28 <dneary> Catching up with backlog
18:45:40 <colindixon> ghall: offset 0 is already API frozen and will stay that way
18:45:51 <edwarnicke> ghall: I think it would push out M5 for offset 0
18:46:41 <rovarga> +1
18:47:06 <rovarga> offset-0 are effectively at API freeze already, so this would be longer M5, which is very welcome
18:47:39 <colindixon> #info ghall asks if this extends the window of change for the core and the associated risks, colindixon says that API freeze has already happened and that the current plan woudl extend offest 0 M5
18:48:05 <colindixon> #info ghall is worried that most major breakages haven't been API changes, but have been changes in the implementation of the API
18:48:28 <colindixon> #info rovarga says that his plan (speaking for YANG tools) is not to bring anything more in because of the extension
18:49:37 * dfarrell07 would love to get to the OVSDB scope question today
18:49:46 <rovarga> dfarrell07: +1
18:49:58 <mohnish> dfarrell07: +1
18:50:34 <vina_ermagan> colindixon: phrobb: thanks. To reiterate, API Freeze is in 1 week for offset 1. Not meeting the API freeze by at least one week is most likely in the case of the projects who requesting the delay. so it is a matter of TSC making this official, and plan to delay release, or consume it elsewhere, or let the projects deal with it themselves..
18:50:57 <colindixon> #Info ghall says that publicly slipping our release is bad for business, like abhijitkumbhare he worries about a second slippage and would like to see actions take to make sure we don't slip again if we allow it slip in the first place
18:51:02 <colindixon> #topic OVSDB scope revision
18:51:29 <colindixon> vina_ermagan: understood, if we get a decision on Monday by the end of the day does that work?
18:51:40 <colindixon> if not, I think we can wrangle people decide later
18:52:14 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2015-October/004017.html the OVSDB project is asking to change their scope to include the network virtualization part of the project
18:52:28 <vina_ermagan> colindixon: yes. Monday is good. Just saying that we wont be able to majically make the deadline if TSC disagrees with at least 1 week delay of M4.
18:52:40 <vina_ermagan> *magically
18:53:53 <colindixon> #info from above, vina_ermagan says that lispflowmapping will not be able to hit M4 unles they get a 1 week delay regardless of what the TSC says
18:55:18 <colindixon> #info afredette and dfarrell07 note that this is more of aligning the "official" scope on the wiki with the well-understood scope of the project in code and in the community
18:55:46 <colindixon> #info edwarnicke asks if they've consulted their downstream projects
18:56:18 <dneary> edwarnicke, "Now it's going to be something else"? My understanding is that the request is that the scope be updated to reflect the status quo
18:56:21 <colindixon> #info afredette says no, but alagalah points out he saw it, is a downstream consumer, and is fine with it
18:58:14 <alagalah> #info colindixon, Well.... I'm ok with the scope change in principal but was clear I would prefer we address the split since I consume OVSDB SB, but not NetVirt, so it makes sense to me two projects, OVSDB SB Offset1, NetVirt Offset 2... it was just a opinion but please reflect what I said :)
18:58:50 <colindixon> #info rovarga says the bgpcep has addressed similar issues, he also thinks that splitting instead of revising the scope woudl potentially avoid a cycle between OVSDB and SFC
18:59:02 <dneary> alagalah, Earlier you asked if I was running "that" - I missed the context - what were you referring to? The ODL-OPNFV call, or the marketing team?
18:59:34 <colindixon> #info mohnish agrees with afredette and dfarrell07 that this is more about aliigning a phrase on the wiki with reality
19:01:48 <colindixon> #info afredette says he thinks it does make sense to split the project, he just doesn't think Beryliium is the right time, he just wants to make sure the description matches reality
19:02:37 <colindixon> #info rovarga and abhijitkumbhare say that maybe the right idea is to change the scope and then split in Boron
19:02:56 <colindixon> #Info rovarga asks if the scope change could come with a plan to split in the future
19:05:02 <alagalah> colindixon, Is there a link to the new scope ?
19:05:18 <alagalah> colindixon, afredette dfarrell07 do you have a link to the new scope proposal ? That may clear this up
19:05:28 <mohnish> https://wiki.opendaylight.org/view/Project_Proposals:OVSDB_NetVirt
19:05:50 <rovarga> #link https://wiki.opendaylight.org/view/Project_Proposals:OVSDB_NetVirt
19:05:54 <alagalah> dfarrell07, apologies, I didn't scroll up enough
19:06:36 <colindixon> #startvote shall the TSC allow for OVSDB scope to include network virtualization assuming they provide a plan to split in Boron? -1, 0, +1
19:06:36 <odl_meetbot> Begin voting on: shall the TSC allow for OVSDB scope to include network virtualization assuming they provide a plan to split in Boron? Valid vote options are -1, 0, +1.
19:06:36 <odl_meetbot> Vote using '#vote OPTION'. Only your last vote counts.
19:06:58 <ChrisPriceAB> #vote 0
19:06:59 <dfarrell07> #vote +1
19:07:01 <mohnish> #vote +1
19:07:02 <edwarnicke> #vote 0 - insufficient information
19:07:02 <odl_meetbot> edwarnicke: 0 - insufficient information is not a valid option. Valid options are -1, 0, +1.
19:07:07 <colindixon> #vote +1
19:07:11 <edwarnicke> #vote )
19:07:11 <odl_meetbot> edwarnicke: ) is not a valid option. Valid options are -1, 0, +1.
19:07:16 <edwarnicke> #vote 0
19:07:31 <edwarnicke> #info insufficient information
19:07:40 <jmedved> #vote 0
19:07:43 <LuisGomez> #vote +1
19:07:48 <jmedved> #info insufficient information
19:08:35 <ChrisPriceAB> #info +1
19:08:39 * ChrisPriceAB is swayed
19:08:48 <ChrisPriceAB> #vote +1
19:08:51 <colindixon> #endvote
19:08:51 <ChrisPriceAB> (oops)
19:08:51 <odl_meetbot> Voted on "shall the TSC allow for OVSDB scope to include network virtualization assuming they provide a plan to split in Boron?" Results are
19:08:51 <odl_meetbot> 0 (2): jmedved, edwarnicke
19:08:51 <odl_meetbot> +1 (5): mohnish, colindixon, LuisGomez, dfarrell07, ChrisPriceAB
19:09:09 <colindixon> #info with eric's verbal +1 (in place of Uri) that does carry
19:09:59 * ChrisPriceAB is dropping of. (the split should be handled as per normal processing ) - yes colin
19:10:00 <colindixon> #info edwarnicke asks when he can expect a proposal for the split, afredette says early in Boron
19:10:19 <colindixon> #Info rovarga asks for a propoosal by the tiem Beryllium ships
19:10:49 <colindixon> #info afredette asks for a few weeks after it ships
19:12:10 <dfarrell07> edwarnicke: it's frustrating to not have you on the email threads, just here saying it's rushed. Not mad, but feedback
19:12:29 <abhijitkumbhare> +1 to mohnish
19:13:55 <colindixon> #topic cookies
19:13:59 <colindixon> #endmeeting