17:00:08 <colindixon> #startmeeting
17:00:08 <odl_meetbot> Meeting started Wed Jan 15 17:00:08 2014 UTC.  The chair is colindixon. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:08 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:25 <colindixon> ok, I'm going to delay attendance for now since we'll give people a few minutes to come
17:01:18 <colindixon> we're still missing RobDolin and chrisprice
17:02:13 <colindixon> #info copyright/license headers
17:02:33 <colindixon> #info dual_regXboi wants to know about files that don't allow fro comments
17:02:51 <colindixon> #info tykeal believes that phrobb sent out the LICESE file to use in that case
17:02:54 <tykeal> #link https://docs.google.com/spreadsheet/ccc?key=0AoSzir1BfjyWdDQyVElWNG9mcWxhblREckZjbjFxUVE#gid=1 for the release spread sheet / agenda
17:03:07 <colindixon> #action phrobb to clarify this explicitly
17:03:13 <colindixon> thanks tykeal
17:03:16 <tykeal> sure
17:03:35 <tykeal> I always think it's handy to have in the notes ;)
17:03:40 <colindixon> #topic overview of meeting and attendance
17:03:57 <colindixon> #info I'm going to focus on things with a deadline before today that aren't done yet first
17:04:12 <colindixon> also, can everyone pound info with their attendance here and what projects (if any they represent)
17:04:18 <edwarnicke> #info Ed Warnicke is in attendance
17:04:19 <tykeal> #info tykeal in attendance for infrastructure support
17:04:27 <abhijitkumbhare> #info abhijitkumbhare is present: Openflowplugin
17:04:28 <cdub> #info Chris Wright is here
17:04:34 <Konstantin> Konstantin for defense4all
17:04:40 <Madhu> #info Madhu for ovsdb
17:04:41 <tykeal> #info notes tykeal == Andrew Grimberg
17:04:44 <michal_rehak> #info michal_rehak is present: Openflowplugin
17:04:47 <edwarnicke> #info Ed Warnicke is in attendance for controller
17:04:47 <dkutenic> #info dkutenic present for bgpcep
17:04:50 <LuisGomez> #info Luis for Integration test
17:04:51 <dual_regXboi> #info dual_regXboi opendove
17:04:55 <ashaikh> #info Anees Shaikh
17:05:02 <Konstantin> #info Konstantin defense4all
17:05:02 <suchiraman> Suchi for affinity
17:05:11 <colindixon> #info suchiraman for affinity
17:05:24 <colindixon> #info Konstantin for defense4all
17:05:28 <colindixon> getting those in the minutes
17:05:33 <colindixon> good attendance
17:05:44 <lori> #info lori for lispflowmapping
17:06:01 <colindixon> moving to the next topic
17:06:06 <colindixon> #topic Write recommendation for cutting Release Branches and laying Release labels
17:06:15 <colindixon> can we mark this as dead Madhu and LuisGomez
17:06:25 <colindixon> I think we can, but I want to make sure and cross it off
17:06:27 <Madhu> colindixon: yes. should be DONE.
17:06:29 <Madhu> will mark it
17:06:45 <colindixon> #action Madhu to mark this as DONE in the spreadsheet
17:06:48 <edwarnicke> QQ: What is the link for the recommendation?
17:07:00 * Madhu finding
17:07:10 <colindixon> https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2014:DependencyConvergence
17:07:12 <colindixon> is that it?
17:07:19 <colindixon> then pound link that
17:07:27 <oflibMichal> #info oflibMichal is present for openflowjava
17:07:35 <edwarnicke> Madhu, could you take an action to make sure the link is in the in the spreadsheet in case folks look for it there
17:07:36 <colindixon> note that pound link has to be the first non-other-command on a line to work I thinkg
17:07:50 <tykeal> colindixon: you're correct on that
17:08:00 <ttkacik> #info ttkacik is present for yangtools
17:08:18 <tykeal> all of the #commands work that way
17:08:34 <colindixon> Madhu: is that the right link so we can move on?
17:08:49 <Madhu> #info https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2014:ReleaseRecommendations
17:09:10 <colindixon> #info #link https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2014:ReleaseRecommendations (same link as above)
17:09:11 <Madhu> i will pretty it up
17:09:12 <colindixon> thanks
17:09:17 <tykeal> lol
17:09:22 <edwarnicke> Madhu: Can you add the link to the spreadsheet?
17:09:28 <Madhu> edwarnicke: sure.
17:09:36 <edwarnicke> Madhu: thanks :)
17:09:43 <Madhu> #action Madhu to add the link to spreadsheet
17:09:44 <colindixon> #action Madhu to pretty up those instructions some (he's a glutton for punishment, that one)
17:09:55 <tykeal> Madhu: you can #link and #info. Those are non-chair commands
17:10:05 <LuisGomez> Madhu: thanks, you did all the work here
17:10:09 <Madhu> tykeal: learning :) thanks
17:10:18 <colindixon> #topic user manual and developer guide
17:10:19 <tykeal> it's ok, I think we're all learning how the bot works
17:10:38 <colindixon> has anyone heard from Chris Price and RobDolin about this?
17:10:48 <colindixon> its a really big task, but it's importand
17:11:21 <Madhu> Yes. Rob sent an email
17:11:27 <Madhu> but didn't get a chance to think it through.
17:11:51 <edwarnicke> Madhu: Has he asked for more help?
17:12:00 <colindixon> link to the e-mail?
17:12:02 <colindixon> where is it?
17:12:04 <Madhu> yes.
17:12:13 <Madhu> email to the team volunteered to help
17:12:20 <colindixon> ah
17:12:49 <tykeal> ah, so not on any of the lists
17:12:54 <colindixon> #action colindixon to reach out to the doc team and ask them to provide an e-mail to discuss with progress
17:13:02 <colindixon> that's about the best we can do there
17:13:05 <edwarnicke> or attend one of the meetings :)
17:13:25 <tykeal> edwarnicke: that's like hearding cats!
17:13:45 <colindixon> #topic log level guidelines
17:13:51 <colindixon> dual_regXboi: anything to report?
17:14:04 <dual_regXboi> draft was in place in last meeting minutes
17:14:12 <dual_regXboi> i.e. west coast minutes
17:14:13 <colindixon> sweet
17:14:17 <colindixon> I should have read that
17:14:23 <dual_regXboi> #link https://wiki.opendaylight.org/view/Draft_Syslog_Level_Settings
17:14:25 <edwarnicke> We got some feedback from the 5:45pm PST crowd
17:14:36 <dual_regXboi> and that page was updated accordingly
17:14:39 <colindixon> any other feedback from this crowd would be nice
17:14:46 <edwarnicke> dual_regXboi: Could we also add to debug block entry and exit (like if statment blocks etc)
17:15:08 <dual_regXboi> um
17:15:09 <dual_regXboi> sure
17:15:19 <colindixon> isn't there a trace level? or am I crazy?
17:15:25 <dual_regXboi> no there isn't
17:15:32 <colindixon> ok, good to know
17:15:35 <dual_regXboi> at least I couldn't find one
17:15:41 <edwarnicke> I also have some concern about the INFO being used for missing parameter being set to default
17:15:45 <edwarnicke> Because that happens a lot
17:15:51 <edwarnicke> But I suspect we don't usually log it
17:15:54 <edwarnicke> So it may be OK
17:16:03 <dual_regXboi> well... i'd rather log it info than error
17:16:07 <dual_regXboi> which is what i was seeing
17:16:16 <edwarnicke> ya'll don't set all your parameters... ever ;)
17:16:19 <tykeal> definitely more of an INFO than an ERROR
17:16:29 <edwarnicke> Cool... lets go with INFO there
17:17:01 <colindixon> this is, missing some general advice on how many lines of logging should be generated in normal operatiojn
17:17:02 <edwarnicke> QQ: What should our default log level be for the controller overall?
17:17:05 <edwarnicke> In production
17:17:07 <colindixon> yeah
17:17:08 <tykeal> though maybe more of a DEBUG, dunno ;)
17:17:09 <dual_regXboi> block entrance/exit added
17:17:15 <dual_regXboi> I put that at the bottom
17:17:18 <edwarnicke> dual_regXboi: Thank you :)
17:17:20 <colindixon> the doc says default should be notice
17:17:27 <dual_regXboi> that was my proposal
17:17:28 <edwarnicke> Excellent :)
17:17:31 <edwarnicke> I tend to agree
17:17:32 <Madhu> notice ?
17:17:33 <dual_regXboi> I'm not tied to it though
17:17:43 <colindixon> do we want to say that basically in normal operation bundles should log being loaded and unloaded only?
17:17:58 <dual_regXboi> I think so
17:18:05 <edwarnicke> I tend to think so as well
17:18:09 <colindixon> and I pound agreed to that?
17:18:10 <abhijitkumbhare> should the default be warning?
17:18:11 <Madhu> edwarnicke: question
17:18:13 <colindixon> any objections
17:18:21 <edwarnicke> Madhu: please ask :)
17:18:27 <dual_regXboi> warning?
17:18:27 <edwarnicke> the more opinions the better the end result :)
17:18:28 <abhijitkumbhare> I think notice will be a little too chatty
17:18:28 <Madhu> are these recognized level in log back configuration ?
17:18:39 <cdub> warning?  you mean default recorded?
17:18:43 <Madhu> debug info error warn error.
17:18:50 <colindixon> abhijitkumbhare, if they only thing logged in notice is bundle loading and unloading, then I think notice is better than warning
17:18:52 <edwarnicke> abhijitkumbhare: I don't much mind telling folks that things have started up or shut down by default... those are rare occurences and useful to see
17:18:59 <Madhu> I haven't seen alert emergency notice etc.
17:19:48 <abhijitkumbhare> ok - looking into ryan's recommendation - notice is only for bundle start/stop - so notice sounds fine
17:19:50 <Madhu> dual_regXboi: can u pls point me the documentation where these log levels are defined ?
17:19:50 <colindixon> Madhu: if notice is only used for bundle startup/shutdown, fixing that should be easy
17:20:01 <dual_regXboi> Madhu: man syslog?
17:20:04 <Madhu> colindixon: my question is not that :)
17:20:15 <edwarnicke> Apparently not in logback: http://logback.qos.ch/manual/architecture.html
17:20:25 <Madhu> yes. we shud worry only about logback
17:20:27 <Madhu> not syslog
17:20:35 <colindixon> #info there is a lot of useful discussion happening about this topic and if interested people should consult the full logs
17:20:36 <dual_regXboi> well now that's rather annoying
17:20:42 <edwarnicke> TRACE < DEBUG < INFO <  WARN < ERROR
17:20:46 <Madhu> exactly
17:20:52 <Madhu> those are the only 5 levels we have
17:20:56 <dual_regXboi> ok... so give me back the action to remap
17:20:58 <Madhu> so i don't quite understand all others
17:21:14 <colindixon> #info #link https://wiki.opendaylight.org/view/Draft_Syslog_Level_Settings is the page being discussed
17:21:26 <dual_regXboi> #action dual_regXboi to remap to logback levels
17:21:36 <dual_regXboi> I should be able to do that this afternoon
17:21:38 <edwarnicke> Madhu: thanks for bringing that up... could have been ugly to discover late
17:21:40 <tykeal> colindixon: do that as #link and not #info #link
17:21:56 <Madhu> edwarnicke: lol. my mistake that I didn't sync up with dual_regXboi yest
17:22:01 <colindixon> #link https://wiki.opendaylight.org/view/Draft_Syslog_Level_Settings is the page being discussed
17:22:02 <edwarnicke> #link http://logback.qos.ch/manual/architecture.html
17:22:02 <Madhu> crazy work hours.
17:22:04 <colindixon> tykeal: I think both work
17:22:18 <edwarnicke> Madhu: I feel you :)
17:22:20 <colindixon> but we'll see in these logs :p
17:22:28 <colindixon> ok
17:22:33 <dual_regXboi> have we run this one down?
17:22:34 <colindixon> this has been really useful
17:22:39 <tykeal> a #info never hyperlinks a #link does. but only the first command (as the start of a line) is recognized by the bot
17:23:45 <colindixon> so, did we decide how wanted to structure logging
17:23:59 <colindixon> I think that cdub was about to suggest that we log more to the file than to stdout
17:23:59 <dual_regXboi> how do you mean structure?
17:24:00 <edwarnicke> I think we decided dual_regXboi would revisit and come back tomorrow
17:24:15 <colindixon> I meant the default log level and what we were expecting to come there
17:24:23 <dual_regXboi> colindixon: will add that to the page
17:24:31 <dual_regXboi> definitely should log to file
17:24:33 <colindixon> there was a suggestion that the log be only bundle startup, bundle teardown, warnings, and errors
17:24:48 <dual_regXboi> and file should be downloadable via web
17:24:52 <colindixon> but i think cdub was going to say that logging more to a logfile would be a good idea, but I'm not sure
17:24:53 <cdub> default log level (cut off things below) and send them all (>= default) to file
17:24:56 <edwarnicke> By default, obviously folks can tweak that up
17:25:15 <edwarnicke> I don't think we should, by default, be logging debug and trace though
17:25:17 <dual_regXboi> so... next question on this
17:25:19 <edwarnicke> Even to file
17:25:20 <edwarnicke> Thats a lot
17:25:29 <dual_regXboi> (1) access via opendaylight web?
17:25:33 <dual_regXboi> (2) rotation?
17:25:42 <Madhu> rotation is already there
17:25:42 <colindixon> #info cdub suggests "default log level (cut off things below) and send them all (>= default) to file"
17:25:48 <Madhu> access via web is optional
17:26:05 <dual_regXboi> ok, but would should explain where the file is
17:26:07 <colindixon> #info edwarnicke thinks this may be a lot to log to even file, and we should not do debug and trace there
17:26:15 <dual_regXboi> so that people know how to get to it
17:26:23 <colindixon> #info dual_regXboi suggests providing log file access via the web UI as well
17:26:28 <Madhu> dual_regXboi: it is documentation work :) to say look @ logs folder
17:26:37 <Madhu> lets not add more development work around this.
17:26:44 <edwarnicke> debug and trace are very volumnious and woudl be expected to adversely effect performance
17:26:49 <colindixon> #info will follow up with this later today and or tomorrow
17:26:59 <colindixon> edwarnicke: I agree
17:27:01 <dual_regXboi> edwarnicke: agreed
17:27:07 <janmedved> even info affects performance as it is right now
17:27:20 <colindixon> lets let dual_regXboi try to capture this and go over it again tonight or tomorrow
17:27:21 <edwarnicke> true, but we abuse info right now, we need to stop that ;)
17:27:22 <Madhu> yes. info is abused today
17:28:00 <colindixon> I'm going to move on to the next topic unless anyone objects
17:28:03 <Madhu> personally to me, bundle coming up and going down
17:28:03 <janmedved> agreed. we use #info a lot of times when #debug should be used. but we can't clean it all up now
17:28:04 <dual_regXboi> please
17:28:05 <colindixon> #topic Identify differing versions of dependencies on external artifacts and negotiate a recommended version
17:28:07 <Madhu> are not interesting.
17:28:19 <colindixon> cdub and Madhu, is this done
17:28:29 <colindixon> it's not make the version happen
17:28:38 <colindixon> but it's negotiate the version
17:28:44 <colindixon> or recommended version
17:28:48 <Madhu> cdub: u want to take this up ?
17:28:52 <cdub> Madhu's take is that it's unrealistic
17:29:08 <Madhu> yes :( after spending some time on this.
17:29:14 <cdub> I'm willing to try, the issue is deps of deps.
17:29:19 <edwarnicke> Madhu: Could you elaborate, not disagreeing, but curious
17:29:22 <cdub> so...first level external dpes...maybe
17:29:22 <Madhu> it is not as easy as the internal dependancy
17:29:26 <Madhu> beause
17:29:34 <Madhu> let me give a simple example
17:29:35 <cdub> 2nd level external deps is not really reasible
17:29:45 <colindixon> well, certain dependencies are bad to have multiple version, netty in particular
17:30:00 <edwarnicke> cdub: If we agree on direct deps, second level deps should follow, correct?
17:30:01 <cdub> yes, and that's why i'm wiling to try for our first level external deps
17:30:02 <Madhu> open daylight bundle A -> depends  on external dependency B depends on external dependency C
17:30:06 <colindixon> could we indentify external dependencies that it's critical to agree on
17:30:11 <Madhu> edwarnicke: not necessary
17:30:13 <cdub> edwarnicke: no
17:30:19 <edwarnicke> (except where two first level deps disagree on their own deps)
17:30:29 <Madhu> that is quite common
17:30:36 <cdub> edwarnicke: 2 projects...each a different direct dep...which in turn have same (differen version) next dep
17:30:49 <Madhu> and many of the dependency convergence is pointing to such 2nd level dep conflicts
17:31:13 <edwarnicke> Yes
17:31:23 <Madhu> so trying to get a clean dependency convergence for external dependency is not practical
17:31:23 <edwarnicke> OK, get it :)
17:31:25 <cdub> we can publish where we diverge...that's easy
17:31:27 <edwarnicke> thank you for the explanation
17:31:33 <cdub> and discuss what is improtant to converge on
17:31:35 <cdub> that work?
17:31:42 <edwarnicke> Madhu: Would convergence on direct external deps be doable?
17:31:53 <colindixon> #info Madhu believes that converging on external dependencies is likely to be not doable for this release
17:31:53 <ttkacik> tony we need also to manage 2level if there are conflicts
17:32:16 <Madhu> edwarnicke: even if possible, am actually starting to question the value of that
17:32:23 <Madhu> i am at a stage now
17:32:26 <Madhu> don't break what is working
17:32:44 <colindixon> #info possible suggestion is to identify external dependencies that might cause problems with different versions and just focus on those
17:32:48 <colindixon> Madhu: are we there now?
17:32:52 <Madhu> if anyone complains the inconsistent external dependency causing issues, then we can address that particular one
17:32:53 <colindixon> I agree with you
17:33:11 <colindixon> that doesn't sound like a horrible suggestion
17:33:25 <colindixon> assume that we're ok and see if things fall out in test?
17:33:35 <colindixon> fix this post-release?
17:33:44 <Madhu> yes. lets consider it for post-release
17:33:46 <colindixon> it's a bit scary but maybe less scary than introducing lots of flux right now
17:33:49 <Madhu> if we all agree on it
17:33:52 <colindixon> cdub, edwarnicke: thought?
17:33:55 <cdub> ok
17:34:00 <Madhu> thats my biggest concern
17:34:05 <cdub> i see no harm in publishing what we know now
17:34:17 <colindixon> it's a trying to pick the lesser of two evils for sure
17:34:20 <cdub> if something jumps out...deal w/ it now, else post-release sounds ok
17:34:20 <ttkacik> we should at least converge on OSGI framework... I noticed several different declarations as dependency
17:34:29 <cdub> ttkacik: osgi.core...yes
17:34:36 <cdub> that's a good example, as is netty
17:34:38 <colindixon> netty also
17:34:52 <Madhu> converge means ? :)
17:34:54 <Madhu> latest ?
17:34:57 <ttkacik> guava and apache commons
17:34:59 <Madhu> it calls for testing effort
17:35:07 <ttkacik> all projects using same version of third-party
17:35:29 <colindixon> yeah, latest doesn't matter as much as same version throughout
17:36:00 <ttkacik> madhu it seems that it calls for the testing effort
17:36:09 <ttkacik> but in distro you have allways highest one
17:36:13 <janmedved> unless there is a project that needs latest (e.g. netty for OF 1.3)
17:36:32 <edwarnicke> I think we are synced on netty versions, correct?
17:36:51 <Madhu> i think i saw 5.x now
17:36:54 <colindixon> edwarnicke: I don't know that we *need*, but not having them will introduce multiple thread pools and other things
17:36:58 <Madhu> ovsdb at least is in 4.0.10
17:37:05 <ttkacik> 5.x is not feasible now
17:37:14 <colindixon> I thought there were mails to converge on a 4.x a while back
17:37:19 <Madhu> ttkacik: that is my exact concern
17:37:22 <colindixon> 5.x seems like a bad idea
17:37:28 <ttkacik> to put it more correctly same version through ODL...not latest one
17:37:52 <janmedved> agree
17:37:52 <Madhu> ttkacik: can someone suggest the absolutely minimum 3rd party bundle that needs convergence ?
17:37:56 <Madhu> lets deal with that only ?
17:38:08 <colindixon> is there consensus that we need to identify a few critical external dependencies that we need to agree on the version for the release?
17:38:12 <colindixon> and then deal with those
17:38:13 <colindixon> yese
17:38:14 <Madhu> to me, this is extremely risky at this point
17:38:20 <Madhu> but if you feel we shud do it... sure :)
17:38:32 <colindixon> I think every agrees on osgi.core
17:38:45 <colindixon> do we have experience with running two version of netty simultaneously?
17:38:49 <colindixon> does it work?
17:38:50 <edwarnicke> I think the question to me is this: do we have cases where the skew for third party dependencies is causing problems?
17:38:55 <Madhu> colindixon: lets not go there :)
17:38:55 <edwarnicke> If so, we should fix it
17:39:05 <colindixon> yeah
17:39:19 <ttkacik> my suggestion is: osgi.core - API (5.x), netty (4.x), google guava, apache commons, jersey
17:39:19 <Madhu> unless the libraries are embedded into the bundle.
17:39:22 <Madhu> it is a bad idea
17:40:00 <Madhu> guys. if it is not broken, lets not fix it :)
17:40:14 <colindixon> #info the consensus seems to be that we need to try to find external dependencies where different versions can/are causing problems and focus only on those for version convergence
17:40:17 <Madhu> sorry. i have to drop off now.
17:40:20 <edwarnicke> Madhu: Do we know what's broken?
17:40:26 <Madhu> i dont :)
17:40:32 <colindixon> #info it's not clear which, if any, are breaking anything now
17:40:42 <colindixon> can somebody take the action to figure that out?
17:40:43 <janmedved> and do we know that things that appear to be ok are not broken?
17:40:49 <edwarnicke> It strikes me as highly likely that osgi.core, and netty could lead to issues
17:40:50 <colindixon> ttkacik?
17:40:54 <Madhu> jersey was. and we fixed that already
17:40:59 <colindixon> could != is
17:41:15 <Madhu> janmedved: testing shud have brought it out by now :)
17:41:23 <colindixon> yeah
17:41:27 <Madhu> if not... enough testing is not done ?
17:41:33 <colindixon> I'm inclined to agree with Madhu here
17:41:49 <ttkacik> osgi.core is 5.0 for equinox we are using
17:41:58 <ttkacik> but AD-SAL is compiled against 4.2
17:42:07 <colindixon> but is that an issue?
17:42:28 <ttkacik> that is what I noticed with AD-SAL
17:43:21 <ttkacik> issue is...that 5.0 OSGI has more type-safe APIs, which are hidden when compiling against AD-SAL
17:43:22 <colindixon> ttkacik: but is that noticed skew or noticed problems?
17:43:24 <edwarnicke> Is it a good idea to be out of sync with our OSGI container?
17:43:53 <janmedved> we do not have great test coverage yet. and my concern is (like with osgo 4.2 vs. 5.0) there will be corner cases that will manifet themselves as soon as we start a havier load
17:43:57 <janmedved> heaiver
17:44:00 <colindixon> edwarnicke: nobody's asking if it's a good idea, that's clearly false, the question is it a *worse* I idea to change things
17:44:14 <janmedved> heavier (more involved)
17:44:17 <colindixon> yeah
17:44:19 <edwarnicke> colindixon: definitely.  Compared to what? is always the question
17:44:34 <colindixon> so, can somebody take an action item to figure out if this is worth doing?
17:44:39 <ttkacik> with osgi core 4.2 vs 5.0 is more of technical debt
17:44:48 <colindixon> that would involve seeing if 5.0 breaks things
17:45:23 <colindixon> and doing some due diligence about issues between 4.2 and 5.0 working together?
17:45:33 <edwarnicke> QQ: Is anyone using a non 4.10 netty that we know of?
17:45:38 <ttkacik> 5.0 does not break things (we are already using it - equinox is OSGIv5)
17:45:45 <janmedved> ttkacik: do you any issues with modules from md-sal (osgi 5.0) interacting with modules from ad-sal (4.2 based)? loading, API version management, etc...
17:45:53 <Madhu> sorry folks. have to drop off. tty in the evening. bye
17:45:53 <colindixon> changing the AD-SAL to use 5.0
17:45:54 <colindixon> does that work
17:45:56 <ttkacik> but will introduce a lot of warnings code coded against 4.2
17:45:59 <colindixon> Madhu: you're all good
17:46:01 <colindixon> thanks for the help
17:46:10 <ttkacik> because contracts are type-safe and use generics
17:47:07 <ttkacik> janmedved: there is no issue in runtime, but some edge cases in compile time
17:47:11 <colindixon> I really want somebody to take the time to reach out to the projects using 4.2 and help them evaluate if 5.0 is going to break everything, preferably by doing the test on their own before reaching out
17:47:16 <ttkacik> and basicly will create technical debt
17:47:53 <colindixon> otherwise, I'm pretty much entirely with Madhu_offline that we should avoid fixing things that aren't broken
17:47:57 <janmedved> if it's not runtime i would tend to argue for not changing it...
17:48:11 <colindixon> and I don't seen anyone jumping up to do that work
17:49:29 <colindixon> #help if somebody was willing to see if moving all projects to osgi.core 5.xo breaks things, then we could be more confident in deciding to enforce using that for the release
17:49:32 <colindixon> ok
17:49:46 <edwarnicke> colindixon: What's next?
17:49:48 <dual_regXboi> are we done?
17:49:57 <colindixon> we're done with things with deadllines for now
17:49:59 <tykeal> we're way past that iron fist of 30 minutes ;)
17:50:04 <colindixon> I think we follow up with project specific things
17:50:07 <colindixon> tomorrow
17:50:10 <dual_regXboi> then I'm going to motion that we are done
17:50:17 <colindixon> I think we're done
17:50:17 <edwarnicke> OK
17:50:23 <tykeal> I second that motion
17:50:25 <colindixon> #topic for next meeting
17:50:43 <colindixon> #info we'll start with project specific take up of the recommendations that we've hashed out tomorrow AM
17:50:50 <colindixon> #endmeeting