==================================================== #opendaylight-meeting: Weekly TSC Meeting 2014-07-10 ==================================================== Meeting started by phrobb at 16:59:20 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-meeting/2014/weekly_tsc_meeting_2014_07_10/opendaylight-meeting-weekly_tsc_meeting_2014_07_10.2014-07-10-16.59.log.html . Meeting summary --------------- * regXboi (ryan) (regXboi, 16:59:27) * dmm (dmm, 16:59:28) * Rollcall TSC members please #info in (phrobb, 16:59:38) * edwarnicke (edwarnicke, 17:00:55) * Chris Price (ChrisPriceAB, 17:00:58) * Kent Watsen (kwatsen, 17:01:31) * Chris Wright (cdub, 17:03:21) * LINK: https://wiki.opendaylight.org/view/TSC:Main (dmm, 17:04:15) * specific agenda at (regXboi, 17:04:39) * LINK: https://wiki.opendaylight.org/view/TSC:Main#Meeting_Agenda (regXboi, 17:04:48) * call for presentations for chicago and for sdn meeting in october (I can't really hear phil) (regXboi, 17:05:49) * question from dmm: is there a dedicated slot for opendaylight? (regXboi, 17:06:09) * answer there is a track for opendaylight that phrobb is managing (regXboi, 17:06:29) * Lenrow (dlenrow, 17:06:40) * event updates (regXboi, 17:06:43) * note: previous three infos apply to this topic (regXboi, 17:07:00) * welcome Dave (Lenrow) and other TSC members (dmm, 17:07:00) * committer promotions (regXboi, 17:07:47) * considering Michal Rehak to committer on OpenFlowJavaLibrary (regXboi, 17:08:10) * AGREED: since Daniel is not around, this discussion is deferred to 7/17 (regXboi, 17:09:45) * looking for a TSC volunteer for drafting guidelines for how to get a committer promoted (regXboi, 17:10:18) * volunteered (ChrisPriceAB, 17:10:48) * ACTION: ChrisPriceAB to draft guidelines for how to get a committer promoted (regXboi, 17:10:58) * request to respin stable/hydrogen due to bugs found/fixed (regXboi, 17:11:20) * LINK: https://lists.opendaylight.org/pipermail/release/2014-July/000037.html (edwarnicke, 17:11:37) * LINK: https://lists.opendaylight.org/pipermail/release/2014-July/000039.html (edwarnicke, 17:12:16) * first link is request to respin stable/hydrogen (regXboi, 17:12:36) * request from BGPCEP to respin hydrogen stable release. Discussion occured in M3 developer meeting (phrobb, 17:12:49) * second link is request to TSC to respin stable/hydrogen (regXboi, 17:13:05) * folks at M3 dev meeting left the decision to respin to the TSC (phrobb, 17:14:01) * Q what is the impact on existing projects in Hydrogen by the respin? (phrobb, 17:14:24) * question from dmm : what is the impact of a respin of stable/hydrogen (regXboi, 17:14:25) * the short answer from (regXboi) is that all the projects should retest (regXboi, 17:15:06) * kwatsen notes that full regression test may not be needed if the issue is isolated to BGPCEP (phrobb, 17:17:09) * edwarnicke comments that the cherry picks include fixes to yangtools which cuts across everything (regXboi, 17:17:35) * dmm points out that unwanted regressions would be ... disappointing (regXboi, 17:18:15) * regXboi asks "how quickly will we want to do a second stable hydrogen?" (phrobb, 17:18:45) * regXboi notes we are sill missing stable documents (phrobb, 17:20:24) * It is noted that we need to get the first hydrogen relesase out asap with no known bugs... (phrobb, 17:21:40) * having a future release that includes stable-branch associated documentation can then be done (phrobb, 17:22:28) * 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 (phrobb, 17:24:30) * 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 (edwarnicke, 17:24:58) * ACTION: cdub to send mail with to hydrogen/stable projects about upcoming respin with dates (regXboi, 17:25:11) * 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) (colindixon, 17:26:26) * what if we have a regression raised on 7/15 date? (cdub, 17:28:17) * 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 (regXboi, 17:28:36) * AGREED: edwarnicke's strawman proposal for dates (regXboi, 17:28:50) * helium documentation issues (regXboi, 17:29:09) * issue is lack of resources for working on documentation (regXboi, 17:29:59) * documentation is looking for TSC to use the "bully pulpit" to encourage projects to help with documentation (regXboi, 17:30:22) * regXboi notes that this applies to both Helium and stable/Hydrogen (regXboi, 17:30:43) * request to add a Doc time slot to TSC call (regXboi, 17:31:29) * question: who owns that agenda item? (regXboi, 17:31:46) * answer: paulz (regXboi, 17:31:57) * helium packaging (regXboi, 17:33:08) * 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 (phrobb, 17:35:02) * also LuisGomez notes that with a real and solid system test environment spin/test of stable branch releases will go more smoothly (phrobb, 17:36:18) * dmm notes that Helium really hinges on using Karaf or not. (phrobb, 17:36:49) * regXboi notes that release vehicles are difficult to define… (phrobb, 17:38:23) * mlemay notes that Karaf implementation has been coming along… some features such as NSF still needs work… (phrobb, 17:39:38) * 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... (dlenrow, 17:40:37) * testing infrastructure with integration project is next to be done in matching potential features to component dependencies (phrobb, 17:40:38) * 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. (phrobb, 17:41:36) * allowing for different repos; stable, experimental, etc (phrobb, 17:41:56) * this gives ability to build an ODL controller by defining the features that the user needs/wants (phrobb, 17:42:39) * edwarnicke notes there are process/guideline work that needs to be done and agreed to across all projects to make this work properly (phrobb, 17:44:04) * enumeration of thoughts on naming conventions we should work out: feature naming convention, feature artifactId naming convention, etc (edwarnicke, 17:45:43) * component level definitions are still important, but feature packaging definitions for user-visible logical features (both dependencies and conflicts) will be very helpful (phrobb, 17:45:50) * 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? (phrobb, 17:47:47) * dlenrow notes that release vehicles require system test for those particular configs, and the Karaf method causes large combinatorial combinations of testing (phrobb, 17:49:01) * 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 (phrobb, 17:50:13) * 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 (phrobb, 17:51:19) * LINK: https://wiki.opendaylight.org/view/CrossProject:Helium_Release_Vehicle_Brainstorming:Pure_Karaf - details on the Pure Karaf proposal (edwarnicke, 17:51:57) * the testing mode would be to test the feature in isolation, then also test the feature with all other "compatible" features present (phrobb, 17:54:00) * this is the only "sane" test method, as testing every possible permutation is not plausible (phrobb, 17:54:28) * 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 (phrobb, 17:56:27) * dmm asks the TSC, are we going to define Release Vehicles, or are we going to use Karaf? (phrobb, 17:57:21) * regXboi notes that he prefers using Karaf because Release Vehicles disappoint some set of users (phrobb, 17:58:30) * kwatsen notes that we could provide everything with a method to only load what the user wants…. mlemay notes that karaf provides exactly that (phrobb, 17:59:54) * ACTION: mlemay to write up the packaging and selection modes for karaf (phrobb, 18:00:45) * 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 (phrobb, 18:02:19) * would like to apologize to the marketing guys for producing so much cool stuff thats hard to explain in a pretty picture :( (edwarnicke, 18:03:54) * ACTION: Luis Gomez to respond to mlemay karaf outline on what testing and testing milestones are needed for the karaf (phrobb, 18:04:08) * dmm opined that a discussion about karaf would strongly influence the diagram (edwarnicke, 18:04:46) Meeting ended at 18:04:59 UTC. Action items, by person ----------------------- * cdub * cdub to send mail with to hydrogen/stable projects about upcoming respin with dates * ChrisPriceAB * ChrisPriceAB to draft guidelines for how to get a committer promoted * mlemay * mlemay to write up the packaging and selection modes for karaf * Luis Gomez to respond to mlemay karaf outline on what testing and testing milestones are needed for the karaf People present (lines said) --------------------------- * regXboi (45) * phrobb (39) * edwarnicke (18) * odl_meetbot (7) * dlenrow (5) * dmm (5) * cdub (5) * ChrisPriceAB (3) * alagalah (2) * icbts (1) * kwatsen (1) * colindixon (1) * mlemay (1) * drizzt_ (1) Generated by `MeetBot`_ 0.1.4