16:59:20 <phrobb> #startmeeting Weekly TSC Meeting 2014-07-10
16:59:20 <odl_meetbot> Meeting started Thu Jul 10 16:59:20 2014 UTC.  The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:59:20 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:20 <odl_meetbot> The meeting name has been set to 'weekly_tsc_meeting_2014_07_10'
16:59:27 <regXboi> #info regXboi (ryan)
16:59:28 <dmm> #info dmm
16:59:38 <phrobb> #topic Rollcall TSC members please #info in
17:00:55 <edwarnicke> #info edwarnicke
17:00:58 <ChrisPriceAB> #info Chris Price
17:01:31 <kwatsen> #info Kent Watsen
17:03:21 <cdub> #info Chris Wright
17:03:56 <regXboi> cdub: you irc only today?
17:04:15 <dmm> #link https://wiki.opendaylight.org/view/TSC:Main
17:04:39 <regXboi> #info specific agenda at
17:04:43 <cdub> regXboi: no, just transitioning calls
17:04:48 <regXboi> #link https://wiki.opendaylight.org/view/TSC:Main#Meeting_Agenda
17:04:50 <regXboi> cdub: ok
17:05:07 <regXboi> phrobb: can you chair colindixon and I?
17:05:49 <regXboi> #info call for presentations for chicago and for sdn meeting in october (I can't really hear phil)
17:06:09 <regXboi> #info question from dmm: is there a dedicated slot for opendaylight?
17:06:29 <phrobb> #chair regXboi
17:06:29 <odl_meetbot> Current chairs: phrobb regXboi
17:06:29 <regXboi> #info answer there is a track for opendaylight that phrobb is managing
17:06:34 <regXboi> #chair colindixon
17:06:34 <odl_meetbot> Current chairs: colindixon phrobb regXboi
17:06:40 <dlenrow> #info Lenrow
17:06:43 <regXboi> #topic event updates
17:07:00 <regXboi> #info note: previous three infos apply to this topic
17:07:00 <dmm> #info welcome Dave (Lenrow) and other TSC members
17:07:47 <phrobb> thanks regXboi
17:07:47 <regXboi> #topic committer promotions
17:08:10 <regXboi> #info considering Michal Rehak to committer on OpenFlowJavaLibrary
17:09:45 <regXboi> #agreed since Daniel is not around, this discussion is deferred to 7/17
17:10:18 <regXboi> #info looking for a TSC volunteer for drafting guidelines for how to get a committer promoted
17:10:48 <ChrisPriceAB> #info volunteered
17:10:58 <regXboi> #action ChrisPriceAB to draft guidelines for how to get a committer promoted
17:11:20 <regXboi> #topic request to respin stable/hydrogen due to bugs found/fixed
17:11:37 <edwarnicke> #link https://lists.opendaylight.org/pipermail/release/2014-July/000037.html
17:11:56 <edwarnicke> #link https://lists.opendaylight.org/pipermail/release/2014-July/000041.html
17:12:13 <regXboi> #undo
17:12:13 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x2695610>
17:12:16 <edwarnicke> #link https://lists.opendaylight.org/pipermail/release/2014-July/000039.html
17:12:36 <regXboi> #info first link is request to respin stable/hydrogen
17:12:49 <phrobb> #info request from BGPCEP to respin hydrogen stable release.  Discussion occured in M3 developer meeting
17:13:05 <regXboi> #info second link is request to TSC to respin stable/hydrogen
17:14:01 <phrobb> #info folks at M3 dev meeting left the decision to respin to the TSC
17:14:24 <phrobb> #info Q what is the impact on existing projects in Hydrogen by the respin?
17:14:25 <regXboi> #info question from dmm : what is the impact of a respin of stable/hydrogen
17:15:06 <regXboi> #info the short answer from (regXboi) is that all the projects should retest
17:17:09 <phrobb> #info kwatsen notes that full regression test may not be needed if the issue is isolated to BGPCEP
17:17:35 <regXboi> #info edwarnicke comments that the cherry picks include fixes to yangtools which cuts across everything
17:18:15 <regXboi> #info dmm points out that unwanted regressions would be ... disappointing
17:18:45 <phrobb> #info regXboi asks "how quickly will we want to do a second stable hydrogen?"
17:20:24 <phrobb> #info regXboi notes we are sill missing stable documents
17:21:40 <phrobb> #info It is noted that we need to get the first hydrogen relesase out asap with no known bugs...
17:22:28 <phrobb> #info having a future release that includes stable-branch associated documentation can then be done
17:22:32 <edwarnicke> When are we getting the #raisehand ?
17:22:58 <edwarnicke> #raiseshand
17:23:11 <regXboi> I think we can agree to a full regression
17:23:43 <dmm> @regXboi: thx
17:24:30 <phrobb> #info edwarnicke suggests mechanics that say, cut a release In X amount of time,  Allow projects to test then  object to the releaes by date/time X.  If no objections, the TSC will promote to a full release
17:24:58 <edwarnicke> #info We need to decide three dates: When the respin happens, When projects need to have completed testing and raised an objection by, When will artifacts go out if not decided by
17:25:11 <regXboi> #action cdub to send mail with to hydrogen/stable projects about upcoming respin with dates
17:25:19 <edwarnicke> s/When will artifacts go out if not decided by/When release will go live if there are no objections by date 3.
17:26:26 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2014-June/001347.html this is the mail which I sent to project leads to start the hydrogen stable release artifact cutting process (this should help cdub some)
17:26:34 <regXboi> #info edwarnicke's strawman is respin at 7/11 1:00pm CT, complete testing by 7/15 1:00 pm CT, and artifcats push decision at 7/17 meeting
17:27:49 <regXboi> help? I didn't hear that question?
17:28:00 <dmm> artifiCATs [sic] :-)
17:28:05 <regXboi> dmm: I know
17:28:09 <regXboi> #undo
17:28:09 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x24843d0>
17:28:17 <cdub> #info what if we have a regression raised on 7/15 date?
17:28:24 <dlenrow> Is it an unrealistic goal to try to automate and run perpetually "full regression" in our CI process?
17:28:36 <regXboi> #info edwarnicke's strawman is respin at 7/11 1:00pm CT, complete testing by 7/15 1:00 pm CT, and artifacts push decision at 7/17 TSC meeting
17:28:41 <edwarnicke> dlenrow: I don't think its unrealistic, its just not currently real :)
17:28:50 <regXboi> #agreed edwarnicke's strawman proposal for dates
17:29:09 <regXboi> #topic helium documentation issues
17:29:12 <edwarnicke> Has cdub been #actioned for cat herding?
17:29:22 <edwarnicke> (many thanks to cdub for willingness to catherd ;) )
17:29:24 <regXboi> edwarnicke: yes
17:29:35 <cdub> edwarnicke: yeah
17:29:35 <regXboi> action was at 12:25 in the stream - I wrote it
17:29:59 <regXboi> #info issue is lack of resources for working on documentation
17:30:22 <regXboi> #info documentation is looking for TSC to use the "bully pulpit" to encourage projects to help with documentation
17:30:43 <regXboi> #info regXboi notes that this applies to both Helium and stable/Hydrogen
17:31:29 <regXboi> #info request to add a Doc time slot to TSC call
17:31:46 <regXboi> #info question: who owns that agenda item?
17:31:57 <regXboi> #info answer: paulz
17:31:58 <alagalah> edwarnicke: I provided by greenlight update for M3 over email, I
17:32:13 <alagalah> edwarnicke: will do a more formal format update this afternoon
17:33:08 <regXboi> #topic helium packaging
17:33:19 <regXboi> can somebody take the pen?
17:33:25 <phrobb> yea
17:33:30 <regXboi> thanks!
17:35:02 <phrobb> #info LuisGomez notes that we need release vehicles defined for integration team to plan properly, or if we are switching to Karaf, then testing strategy/plan needs to changes substantially and there needs to be tighter integration between projects and the system testing effort
17:36:18 <phrobb> #info also LuisGomez notes that with a real and solid system test environment spin/test of stable branch releases will go more smoothly
17:36:49 <phrobb> #info dmm notes that Helium really hinges on using Karaf or not.
17:38:23 <phrobb> #info regXboi notes that release vehicles are difficult to define…
17:39:38 <phrobb> #info mlemay notes that Karaf implementation has been coming along… some features such as NSF still needs work…
17:40:37 <dlenrow> #info We have more than 9 services that think they independently own the flow tables. They can't run together no matter how flexible Karafe is. Love Karafe direction in general,  Multiple flow writers still a problem...
17:40:38 <phrobb> #info testing infrastructure with integration project is next to be done in matching potential features to component dependencies
17:40:51 * icbts I’m here
17:41:36 <phrobb> #info mlemay notes that addition metadata in karaf needed that is ODL specific to call out the maturity of the feature and also group it by project.
17:41:56 <phrobb> #info allowing for different repos; stable, experimental, etc
17:42:39 <phrobb> #info this gives ability to build an ODL controller by defining the features that the user needs/wants
17:44:04 <phrobb> #info edwarnicke notes there are process/guideline work that needs to be done and agreed to across all projects to make this work properly
17:45:27 <dlenrow> +1 right direction Karafe
17:45:43 <edwarnicke> #info enumeration of thoughts on naming conventions we should work out: feature naming convention, feature artifactId naming convention, etc
17:45:50 <phrobb> #info component level definitions are still important, but feature packaging definitions for user-visible logical features (both dependencies and conflicts) will be very helpful
17:47:47 <phrobb> #info Q: what do we want to do as a TSC about release vehicles for Helium?… define them as we did with Hydrogen, or use an ala-carte method such as Karaf?
17:49:01 <phrobb> #info dlenrow notes that release vehicles require system test for those particular configs, and the Karaf method causes large combinatorial combinations of testing
17:50:13 <phrobb> #info regXboi notes that testing for hydrogen release vehicles allowed bugs to slip through and that the actual release vehicles were not well suited for wide arrays of users
17:51:18 <drizzt_> Are these mutually exclusive? Could you do Karaf then have a set of menus/reference architectures etc.?
17:51:19 <phrobb> #info edwarnicke notes that the goal of karaf is that we don't have to guess what users want.  They can pick their own set of high-level features for their particular needs
17:51:57 <edwarnicke> #link https://wiki.opendaylight.org/view/CrossProject:Helium_Release_Vehicle_Brainstorming:Pure_Karaf - details on the Pure Karaf proposal
17:54:00 <phrobb> #info the testing mode would be to test the feature in isolation, then also test the feature with all other "compatible" features present
17:54:28 <phrobb> #info this is the only "sane" test method, as testing every possible permutation is not plausible
17:55:41 <edwarnicke> cdub: How do Linux Distro's handle the combinatronics of the many packages?
17:55:49 <edwarnicke> cdub: And testing
17:56:27 <phrobb> #info dmm notes that existing HW vendors allow feature enablement that can cause problems for the user.  Karaf has great benefits but also has a cost
17:56:37 <cdub> edwarnicke: a) we do pretty exhaustive testing, b) packages have deps and conflicts, c) we deliver things that users can abuse and screw themselves up with
17:57:21 <phrobb> #info dmm asks the TSC, are we going to define Release Vehicles, or are we going to use Karaf?
17:58:30 <phrobb> #info regXboi notes that he prefers using Karaf because Release Vehicles disappoint some set of users
17:59:54 <phrobb> #info kwatsen notes that we could provide everything with a method to only load what the user wants…. mlemay notes that karaf provides exactly that
18:00:45 <phrobb> #action mlemay to write up the packaging and selection modes for karaf
18:01:51 <dlenrow> In the years I spent selling switch/router code to OEMs  and Web guys, I found a big diifference ($millions) between "it will probably work" and "We tested that config".  I'm just saying we need prominent disclaimer if we auto build untested configs
18:02:19 <phrobb> #info LuisGomez notes that testing helium using karaf we need a decision on karaf, then if karaf, we need to know "what are the features?", what are the dependencies and what is a conflict.  We need new milestone attributes for those also
18:02:24 <ChrisPriceAB> I think it's important that when a user downloads the "platform" it is in itself able to function.
18:02:57 <edwarnicke> ChrisPriceAB: For what value of 'function' ? :)  All the platform can do is deliver one or more features
18:03:54 <edwarnicke> #info would like to apologize to the marketing guys for producing so much cool stuff thats hard to explain in a pretty picture :(
18:04:08 <phrobb> #action Luis Gomez to respond to mlemay karaf outline on what testing and testing milestones are needed for the karaf
18:04:24 <mlemay> @ChrisPriceAB : I agree on that… for example just bringing OF feature on its own doesn’T do much but we should have “meta-features” that makes sense..
18:04:46 <edwarnicke> #info dmm opined that a discussion about karaf would strongly influence the diagram
18:04:59 <phrobb> #endmeeting