#opendaylight-meeting: TSC

Meeting started by phrobb at 18:00:55 UTC (full logs).

Meeting summary

    1. dlenrow (dlenrow, 18:01:17)

  2. rollcall TSC members please #info in (phrobb, 18:01:26)
    1. colindixon (colindixon, 18:01:33)
    2. dlenrow (dlenrow, 18:01:38)
    3. https://wiki.opendaylight.org/view/TSC:Main#Agenda agenda in it’s normal place (colindixon, 18:01:46)
    4. mohnish anumala (mohnish, 18:02:25)
    5. kwatsen (kwatsen, 18:02:34)
    6. https://meetings.opendaylight.org/opendaylight-meeting/2014/tsc/opendaylight-meeting-tsc.2014-12-18-17.57.html minutes from last TSC meeting (tbachman, 18:02:40)
    7. ACTION: colindixon to start the conversation and collect ideas on how to resolve cross-project version bumping in timely fashion (colindixon, 18:02:55)
    8. edwarnicke (edwarnicke, 18:03:01)
    9. https://wiki.opendaylight.org/view/TSC:Main#Agenda link to TSC agenda (tbachman, 18:03:02)
    10. jmedved (jmedved, 18:03:14)
    11. edwarnicke asks if autorelease should be on the agenda (tbachman, 18:04:15)
    12. colindixon says there was an email to the list, and since autorelease wasn’t creating artifacts for itself, it didn’t need to participate in the release (tbachman, 18:04:40)
    13. ShaunWackerly (ShaunWackerly, 18:04:56)
    14. phrobb looked into non-project wikis, didn't find many, looks pretty good (dfarrell07, 18:05:08)
    15. ACTION: colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC (colindixon, 18:05:23)
    16. ACTION: colindixon will track how VTN and controller are interacting on possible AD-SAL deprecation (colindixon, 18:05:47)
    17. edwarnicke says that there’s been ongoing confusion about the neutron service — it’s no longer an AD-SAL service (tbachman, 18:06:22)
    18. colindixon says the SR1.1 security release was announced (tbachman, 18:08:20)
    19. cdub created a secuity mailing list discussion (tbachman, 18:08:33)
    20. LuisGomez (LuisGomez, 18:09:14)
    21. (RajeevK, 18:09:47)
    22. RajeevK (RajeevK, 18:09:59)
    23. regXboi (regXboi, 18:10:10)
    24. <running late> (regXboi, 18:10:17)

  3. updates (tbachman, 18:11:41)
    1. Youcef Laribi (Youcef, 18:12:11)
    2. Currently in the CFP period for ODL Summit, closes at end of Feb (dfarrell07, 18:12:11)
    3. phrobb says we’re in the middle of CFP for the ODL summit - closes at the beginning of Feb (please submit)! (tbachman, 18:12:13)
    4. Hack fest in mid April being looked into by LF, phrobb (dfarrell07, 18:12:34)
    5. hackfest on April 14th as we close around M5 — venue possibilities should be available sometime this week (tbachman, 18:12:40)
    6. phrobb says that we don’t have project ideas for potential interns — please submit ideas ASAP (tbachman, 18:13:09)
    7. phrobb says they’re working on getting export classification through the govt., and have an outside group going through the code (tbachman, 18:13:41)
    8. phrobb says there are 6 active projects that have encryption technology in it (tbachman, 18:13:57)
    9. phrobb is reaching out to those projects (tbachman, 18:14:13)
    10. phrobb says one of the projects is the netvirt platform (original platform submitted by BigSwitch Networks), which raises the question back to the TSC of whether to archive some code (tbachman, 18:14:45)
    11. https://git.opendaylight.org/gerrit/#/q/project:net-virt-platform note that it has now been exactly 12 months since there was any commit activity (colindixon, 18:15:06)
    12. phrobb suggests that TSC may need to start thinking about archive projects, like on contributed by Big Switch that has no active committers (but encryption tech) (dfarrell07, 18:15:06)
    13. phrobb says another issue related to export is VMs — have to go through all of the source and identify any encryption pieces that require approval for export (tbachman, 18:15:30)
    14. The requirement for Termination is no commits in 18 months (tbachman, 18:17:00)
    15. https://wiki.opendaylight.org/view/InternProjects:Main interns projects (colindixon, 18:17:09)
    16. http://www.opendaylight.org/project-lifecycle-releases (18 months) (kwatsen, 18:17:18)
    17. No updates from LuisGomez on Infra and Test (dfarrell07, 18:17:49)
    18. http://www.opendaylight.org/project/bylaws <== bylaws (gzhao, 18:18:19)
    19. gzhao says that the stable/helium 2.0 is taking over 2hrs, and therefore isn’t available for approval on today’s TSC call (tbachman, 18:18:25)
    20. colindixon says we should consider moving the stable/helium release out by a week (tbachman, 18:19:40)
    21. gzhao suggests bumping two weeks, as no urgent bug fixes atm (dfarrell07, 18:20:43)
    22. AGREED: The Stable/Helium SR2 date has been moved to January 26, 2015 (tbachman, 18:21:32)
    23. AGREED: The SR2 release date has been moved to Jan 26th 2015 (two weeks out) (dfarrell07, 18:21:33)

  4. Infrastructure (tbachman, 18:21:45)
    1. colindixon says that if you are a project that’s not listed on the Li tracking document, then you should contact gzhao to make sure you’re in that document (tbachman, 18:22:35)
    2. https://docs.google.com/spreadsheets/d/1KPpO9LH539Vlcoa4RvLa6PPCdLifi5JD-ihRhlybqeo/edit#gid=0 Document for tracking proejcts that are part of the Li simultaneous release (tbachman, 18:22:51)
    3. ACTION: gzhao will try to make sure sure the list of participating projects on the wiki matches what people have send to the release list (colindixon, 18:22:58)
    4. https://wiki.opendaylight.org/view/Simultaneous_Release:Lithium_Release_Plan#Participating_Projects the list of participating projects is here on the wiki (colindixon, 18:23:48)
    5. https://docs.google.com/spreadsheets/d/1KPpO9LH539Vlcoa4RvLa6PPCdLifi5JD-ihRhlybqeo/edit#gid=1196332566 <== tracking all the projects. (gzhao, 18:24:24)
    6. The release mailing list is the official record for submitting intention to participate in teh Lithium stable release (tbachman, 18:24:31)
    7. sending mail to "release@lists.opendaylight.org" is the official indication of simultaneous release participation (phrobb, 18:24:48)
    8. https://lists.opendaylight.org/pipermail/discuss/2014-November/004024.html (zxiiro, 18:25:07)
    9. zxiiro says that sonar uses the artifact ID from the pom that you pass to maven as the name that will appear in sonar (tbachman, 18:25:45)
    10. zxiiro recommends deciding on a proper naming scheme for these (tbachman, 18:26:06)
    11. zxiiro provided some ideas for this in the email provided in the link above (tbachman, 18:26:27)
    12. colindixon says the short names are already guaranteed to be unique, so he recommends using the short names if that makes sense (i.e. repo name) (tbachman, 18:26:55)
    13. rovarga asks if there’s a way to maintain the history if we rename the projects (tbachman, 18:27:42)
    14. ACTION: zxiiro will reach out to projects to rename soar jobs (colindixon, 18:27:48)
    15. ACTION: zxiiro to investigate if there’s a way to maintain the history if we rename the projects (tbachman, 18:27:58)
    16. tykeal says odlforge is still making headway — puppet module has been released to puppet-forge (tbachman, 18:28:20)
    17. tykeal says odlforge should be up in the next couple of weeks, depending on workload (tbachman, 18:28:33)

  5. Creation Reviews (tbachman, 18:28:50)
    1. colindixon says one creation review (intent) has been posted to the wiki for more than 2 weeks, but the mail to announce it was within the last week (tbachman, 18:29:45)
    2. colindixon notes that the TSC has made exceptions to projects that are posted beyond the specified date, given the circumstances, and this may fall under that (tbachman, 18:32:36)

  6. Device Identification and Driver Management (DIDM) project creation review (dfarrell07, 18:33:08)
    1. https://wiki.opendaylight.org/view/Project_Proposals:Device_Identification_And_Driver_Management project proposal (colindixon, 18:33:37)
    2. https://lists.opendaylight.org/pipermail/project-proposals/2014-December/000221.html re-proposed on 12/5/14 (colindixon, 18:34:01)
    3. https://lists.opendaylight.org/pipermail/project-proposals/2014-October/000176.html originally proposed 10/21/14 (colindixon, 18:34:17)
    4. slides will be posted after the call, but see the recording starting around 30 minutes for the start of the slides (colindixon, 18:38:54)
    5. asks about whether there are other things they want to look at like things UPnP (he says PnP for plug and play, but I think he meails UPnP) (colindixon, 18:41:17)
    6. wondering if YANG is in scope for device data models (RajeevK, 18:42:58)
    7. alagalah asks if this has any overlap with TTP (tbachman, 18:43:45)
    8. the core idea of the project is to have a component that tries to identify the kinds of devices by whatever means it can and then note what the device type is along with what you can do with it given the type (colindixon, 18:44:06)
    9. colindixon says that this is the framework that could take a feature like TTP and do something useful with the information that it got from it (tbachman, 18:45:02)
    10. sdean778 says they’ll deliver documentation and a sample driver, along with possibly some abstract classes (tbachman, 18:45:55)
    11. past that, they also want to provide initial drivers that adapt some functionality based on the kind of device (colindixon, 18:46:18)
    12. sdean778 emphasizes they’re using standard MD-SAL mechanisms to invoke the drivers (RPCs or invoked via data change notifications) (tbachman, 18:46:18)
    13. sdean778 says identification requires a framework component that orchestrates this process (tbachman, 18:46:34)
    14. sdean778 says that standard MD-SAL mechanisms could be used for synchronization and driver registration (tbachman, 18:46:52)
    15. dependencies include a credential manager that reuires AAA, and the SNMP plugin project (tbachman, 18:47:47)
    16. jmedved asks if there are any dependencies on the NETCONF connector (tbachman, 18:48:10)
    17. sdean778 says they don’t see that for the first phase (tbachman, 18:48:23)
    18. There are some MD-SAL enhancement reqeuests: ability to control how much processing is given to a plugin, and finer filter of data change notifications (e.g. only if augmentation equals a specific value) (tbachman, 18:49:57)
    19. https://wiki.opendaylight.org/view/OpenDaylight_Controller:Lithium:Release_Plan#Requests_from_Other_Projects - please record controller requests so they don't get lost: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Lithium:Release_Plan#Requests_from_Other_Projects :) (edwarnicke, 18:50:24)
    20. jmedved asks if it makes sense to introduce the feature models being introduced to the IETF to get more peer review (colindixon, 18:51:41)
    21. sdean778 says he hadn’t thought about it, but it’s an interesting idea (colindixon, 18:51:59)
    22. dbainbri says they’re planning on adding the MD-SAL enhancements as enhancement requests in bugzilla (tbachman, 18:52:40)
    23. colindixon says that the problem with just bugzilla or just the wiki is that there’s no guarantee of bi-directional communication (tbachman, 18:53:55)
    24. sdean778 says they’ll update bugzilla, update the wiki, and send emails for the feature requests. (tbachman, 18:54:25)
    25. ACTION: sdean778 and david bainbridge to list any changes they want from MD-SAL/controller on their project plan, talk via e-mail, and file buzilla bugs (colindixon, 18:54:40)
    26. https://wiki.opendaylight.org/view/DIDM:Lithium Proposed release plan for DIDM (tbachman, 18:56:27)
    27. LuisGomez says you may want to consider NETCONF over SNMP, as NETCONF is more mature in ODL (tbachman, 18:57:04)
    28. LuisGomez makes it clear that he's talking about maturity of ODL projects, not the protocols generally (dfarrell07, 18:58:16)
    29. dbainbri says that he’s discussed merging discovery and DIDM projects, but there’s no official policy in ODL for doing this (tbachman, 18:59:18)
    30. colindixon says that the biggest obstacle here is the committer list (tbachman, 18:59:50)
    31. http://www.opendaylight.org/project-lifecycle-releases#ProjectTypes Wiki page describing project types and life cycles, including project termination (tbachman, 19:00:59)
    32. http://www.opendaylight.org/project-lifecycle-releases ODL lifecycle, for docs on termination review (edwarnicke, 19:01:08)
    33. AGREED: The Device Identification and Driver Management (DIDM) project is approved to Incubation (dfarrell07, 19:03:45)
    34. I messed up #vote syntax, see logs for info (dfarrell07, 19:04:36)

  7. Application-Layer Traffic Optimization (ALTO) project creation review (dfarrell07, 19:04:50)
    1. DIDM project approved, 12 votes +1, 0 votes 0, 0 votes -1 (tbachman, 19:05:01)
    2. https://wiki.opendaylight.org/view/Project_Proposals:Alto Project proposal wiki (dfarrell07, 19:05:08)
    3. https://lists.opendaylight.org/pipermail/project-proposals/2014-December/000220.html Proposed 12/4/2014 (dfarrell07, 19:05:24)
    4. ALTO is RFC 7285, defines high-level abstractions and services to provide network information to applications (tbachman, 19:06:32)
    5. It defines an abstract network maps and cost maps (tbachman, 19:06:45)
    6. It provies a map filtering servie (tbachman, 19:06:56)
    7. It provides an Endpoint Properties Service (tbachman, 19:07:05)
    8. It provides an Endpoint Cost Service (tbachman, 19:07:17)
    9. It provides an Information Resource Directory Service (tbachman, 19:07:29)
    10. additional services such as network graphs are WIP (tbachman, 19:07:38)
    11. RFC7285 is a RESTful design with JSON encoding (tbachman, 19:07:52)
    12. Goals of the ALTO-ODL project include integration the ALTO abstractions into ODL, facilitating ALTO devlopment, and using ODL infrastructure to support the implememtnation of scalable, reliable ALTO servers (tbachman, 19:08:47)
    13. https://wiki.opendaylight.org/view/File:Alto-odl-creation-review-slides.pptx slides are here (colindixon, 19:08:50)
    14. Uses MD-SAL data store to store ALTO data instances (yang models for ALTO network maps, cost maps, and endpoint properties) (tbachman, 19:09:40)
    15. Derive ALTO data from ODL data whenever possible in particular from Inventory, Host Tracker, and Topology Manager (tbachman, 19:10:02)
    16. Revise statically provisioned ALTO data with ODL data (e.g. update ALTO cost maps upon topology changes, flow rule updates) (tbachman, 19:10:24)
    17. NB API to Applications: provide the standard ALTO RESTful/JSON API to ALTO clients, and allow local access through the MD-SAL data store (tbachman, 19:12:35)
    18. Architectural components: ALTO Configuration Manager, configured from Coniguration Settings; ALTO Protocol Manager, which depends on ALTO Data (persited data), which provides data to the RFC7285 ALTO Clients; Related ODL Data provides input to ALTO Data and ALTO Configuration Manager; ODL Components both provide and recieve info with ALTO (tbachman, 19:14:36)
    19. Deliverables inclue: define YANG models for all basic ALTO data; provide ALTO Configuration Manager as a provisioning interface to configure ALTO data instances; Iimplement ALTO Protocol Manager to provide RFC7285 access to ALTO clients; Desogn initial interactions with basic ODL components; Provide an ODL multi-flow scheduling app to demonstrate the use of ALTO data in ODL (tbachman, 19:15:48)
    20. optional deliverables include incremental updates for cost maps (draft-roome-incr) and define and implement ALTO network graphs (tbachman, 19:16:16)
    21. project lead and contact is Y. Richard Yang; test contact is Xiao Shi (tbachman, 19:17:17)
    22. jmedved says this look like a good and useful project (colindixon, 19:18:20)
    23. rovarga asks if they plan to do any interop testing (tbachman, 19:18:26)
    24. rovarga asks if they will be automating the interactions inside the integration project with some other implementation (tbachman, 19:18:48)
    25. Y. Richard says they are definitely going to do interop (tbachman, 19:19:07)
    26. RajeevK asks if there is any information flow from ALTO to ODL (tbachman, 19:19:54)
    27. Y. Richard says there is some feedback, where ALTO information is sent to a client, and the client then does the routing; the client then goes to ODL to set up the flow tables (tbachman, 19:20:33)
    28. Y. Richard says there is also some information provided to other components (e.g. multi-flow scheduler) (tbachman, 19:21:04)
    29. kwatsen asks if the NB plugin would have both the RESTCONF API as well as the ALTO API (tbachman, 19:21:41)
    30. Y. Richard says that it’s an ALTO API, but colindixon notes that since it’s MD-SAL, there will be RESTCONF (tbachman, 19:22:22)
    31. LuisGomez asks if the plugin is also part of the scope for the project (tbachman, 19:23:07)
    32. Y. Richard says it is (tbachman, 19:23:12)
    33. +1 (kwatsen, 19:23:29)
    34. VOTE: Voted on "Shall the TSC approve the Application-Layer Traffic Optimization (ALTO) project to Incubation?" Results are, +1: 9 (dfarrell07, 19:24:04)
    35. AGREED: The Application-Layer Traffic Optimization (ALTO) project is approved to Incubation (dfarrell07, 19:24:12)

  8. Controller Core Functionality Tutorials project creation review (dfarrell07, 19:24:35)
    1. https://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:Project_proposal Project proposal wiki (dfarrell07, 19:24:43)
    2. https://lists.opendaylight.org/pipermail/project-proposals/2014-December/000248.html Proposed 12/4/2014 (dfarrell07, 19:24:48)
    3. alagalah says there was discussion on the MD-SAL hackers call on features for MD-SAL, config subsystem, etc., which led to questions of the features that we currently have and tutorials on how to use them; the need for these things kicked off the creation of this project (tbachman, 19:25:54)
    4. alagalah says that the group came up with the idea of using tutorials in repos that would go through the example step-by-step; at the same time, the scope grew to cover things like inventory, openflowplugin, etc. (tbachman, 19:27:52)
    5. VOTE: Voted on "Shall the TSC approve the Controller Core Functionality Tutorials project to Incubation?" Results are, +1: 11 (dfarrell07, 19:31:09)
    6. AGREED: the Controller Core Functionality Tutorials project is approved to incubation (phrobb, 19:31:12)
    7. ACTION: DIDM and ALTO to get release plans out as soon as possible (tbachman, 19:33:07)

  9. Release Engineering - Autorelease project creation review (dfarrell07, 19:34:06)
    1. https://wiki.opendaylight.org/view/Project_Proposals:Release_Engineering_-_Autorelease Project proposal wiki (dfarrell07, 19:34:10)
    2. https://lists.opendaylight.org/pipermail/project-proposals/2014-November/000202.html Proposed 11/20/2014 (dfarrell07, 19:34:58)
    3. gzhao says that autorelease doesn’t generate any artifacts, so won’t participate in the simultaneous release (tbachman, 19:35:51)
    4. regXboi asks if the project proposal includes “god powers” (tbachman, 19:40:30)
    5. colindixon says this was deferred, due to lack of agreement (tbachman, 19:40:39)
    6. ACTION: gzhao to generate release plan for auto-release (gzhao, 19:40:45)
    7. VOTE: Voted on "Shall the TSC approve the Release Engineering - Autorelease project to Incubation?" Results are, +1: 8 (dfarrell07, 19:41:25)
    8. AGREED: the Release Engineering - Autorelease project is approved to incubation (phrobb, 19:41:27)
    9. http://cdn.fashionablygeek.com/wp-content/uploads/2010/09/calorie-grenade-shirt-590x462.jpg?22a92a ? (tykeal, 19:41:33)

  10. Network Intent Composition (NIC) project creation review (dfarrell07, 19:41:52)
    1. https://wiki.opendaylight.org/view/Project_Proposals:Network_Intent_Composition Project proposal wiki (dfarrell07, 19:41:52)
    2. https://lists.opendaylight.org/pipermail/project-proposals/2015-January/000249.html Proposed 1/5/2015 (dfarrell07, 19:42:01)
    3. NOTE: this is not a creation review (colindixon, 19:42:26)
    4. WE WILL NOT BE VOTING ON THIS TODAY (colindixon, 19:42:36)
    5. Network Intetent Overview: what, now how; Portable across any/all infra; Intent is a form of policy, but not all plicy networking is intent; Intent is completely abstract and contains no references to instances of network resources or to vendor/media/protocol specifics; A pure intent project provides no control (tbachman, 19:43:32)
    6. Scope is to create an implementation of an intent-based NBI; interact with existing ODL modules as needed to translate pure intent via NBI, into allocated and configured network services and protocol/vendor/device specific network state (tbachman, 19:44:18)
    7. (Scope: cont.) develop logic to identify and correct conflicting intent requests and to ensure conflict-free overall network configuration; develop environment for extending Intent “language” in a way that preserves resource sharing/cooperation; Create language, compiler, and similar tooling to optimize intent translation (tbachman, 19:45:21)
    8. Intent is a proposed solution to multiple write problem by becoming the only writer (tbachman, 19:46:08)
    9. dlenrow notes that this is a somewhat radical idea (colindixon, 19:46:21)
    10. thesis is that anything that can be conveyed to the controller via prescription can instead be described as intent (tbachman, 19:46:55)
    11. Role of standards in SDN and NFV: Members of ETSI and ONF include SDN consumers interested in standards-based solutions; open source projects generally have no committment to working with standards orgs and don’t want to be burdened by this overhead (tbachman, 19:48:38)
    12. What is unique about this project: founded with goal of using intent to achieve multi-service SDN cooperation; founded iwth goal of working closely with and creating a reference implementation of NBI definitions from ONF NBI WG and ETSI NFV (tbachman, 19:49:36)
    13. founded to build infra to detect and resolve intent conflicts and to minimize changes to network state in response to changes in intent (tbachman, 19:49:56)
    14. emphasis on ease of use and extending “programming the network” to non-expert users and admins (tbachman, 19:50:21)
    15. regXboi says that by saying it’s the only writer forces it to be it’s own distribution (tbachman, 19:51:00)
    16. colindixon says that the project proposal has to happen next week to allow for the proper 2-week review (tbachman, 19:52:08)
    17. ACTION: dlenrow to post slides for the intent project to the mailing list (tbachman, 19:52:18)
    18. colindixon says TSC needs to decide whether to allow the intent project given that it’s technically late (tbachman, 19:53:17)
    19. colindixon asks TSC whether we should switch back to 1hr meetings now that the creation reviews are complete (tbachman, 19:53:18)

  11. Meeting length (dfarrell07, 19:53:25)
    1. AGREED: the TSC meeting is reduced to 1 hour weekly (phrobb, 19:53:43)

  12. Java 8 (dfarrell07, 19:54:06)
    1. Various projects want to move to Java 8 (dfarrell07, 19:54:40)
    2. colindixon asks rovarga what issues projects should be aware of when moving to Java 8 (tbachman, 19:54:49)
    3. There's a thread on odl-discuss about moving to Java 8 (dfarrell07, 19:55:00)
    4. rovarga says karaf 3.0.1 is not compatible with Java 8, b/c it doesn’t export a platform service that’s needed (tbachman, 19:55:14)
    5. https://lists.opendaylight.org/pipermail/discuss/2015-January/004196.html (colindixon, 19:55:15)
    6. edwarnicke notes that the last update for Java 7 is targeted for March, so the need for Java 8 is becoming more important (tbachman, 19:56:34)
    7. dbainbri asks if openjdk is available on all supported platforms (tbachman, 19:56:48)
    8. tykeal says it’s on EL7.1 (tbachman, 19:57:00)
    9. dfarrell07 notes that he’s seen a fairly large number of questions on ask.odl about issues with Java versions that would be solved by working with Java 8 (tbachman, 19:57:25)
    10. dbainbri asksi if it’s supported in ubuntu (tbachman, 19:57:37)
    11. tykeal and mlemay say that it is (tbachman, 19:57:44)
    12. rovarga says that he believes the Lithium release will be able to support Java 8 (tbachman, 19:58:34)
    13. dbainbri asks when we’ll have a milestone for when Java 8 capabilities can be used (tbachman, 19:59:26)
    14. rovarga says that for yangtools and MD-SAL, we won’t be able to do the binding specification 2, we’ll probably look to do these in the Beryllium time frame (tbachman, 19:59:53)
    15. ACTION: colindixon will add Java 8 to TSC topics for next week (dfarrell07, 20:01:50)


Meeting ended at 20:01:58 UTC (full logs).

Action items

  1. colindixon to start the conversation and collect ideas on how to resolve cross-project version bumping in timely fashion
  2. colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC
  3. colindixon will track how VTN and controller are interacting on possible AD-SAL deprecation
  4. gzhao will try to make sure sure the list of participating projects on the wiki matches what people have send to the release list
  5. zxiiro will reach out to projects to rename soar jobs
  6. zxiiro to investigate if there’s a way to maintain the history if we rename the projects
  7. sdean778 and david bainbridge to list any changes they want from MD-SAL/controller on their project plan, talk via e-mail, and file buzilla bugs
  8. DIDM and ALTO to get release plans out as soon as possible
  9. gzhao to generate release plan for auto-release
  10. dlenrow to post slides for the intent project to the mailing list
  11. colindixon will add Java 8 to TSC topics for next week


Action items, by person

  1. colindixon
    1. colindixon to start the conversation and collect ideas on how to resolve cross-project version bumping in timely fashion
    2. colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC
    3. colindixon will track how VTN and controller are interacting on possible AD-SAL deprecation
    4. colindixon will add Java 8 to TSC topics for next week
  2. dlenrow
    1. dlenrow to post slides for the intent project to the mailing list
  3. gzhao
    1. gzhao will try to make sure sure the list of participating projects on the wiki matches what people have send to the release list
    2. gzhao to generate release plan for auto-release
  4. zxiiro
    1. zxiiro will reach out to projects to rename soar jobs
    2. zxiiro to investigate if there’s a way to maintain the history if we rename the projects
  5. UNASSIGNED
    1. sdean778 and david bainbridge to list any changes they want from MD-SAL/controller on their project plan, talk via e-mail, and file buzilla bugs
    2. DIDM and ALTO to get release plans out as soon as possible


People present (lines said)

  1. tbachman (199)
  2. dfarrell07 (70)
  3. colindixon (62)
  4. edwarnicke (24)
  5. dneary (23)
  6. regXboi (22)
  7. tykeal (21)
  8. odl_meetbot (20)
  9. alagalah (16)
  10. dlenrow (11)
  11. gzhao (11)
  12. RajeevK (11)
  13. jmedved (9)
  14. mohnish_ (8)
  15. rexpugh (8)
  16. phrobb (8)
  17. dbainbri (8)
  18. kwatsen (7)
  19. LuisGomez (6)
  20. ChrisPriceAB (6)
  21. Youcef (6)
  22. zxiiro (5)
  23. ShaunWackerly (4)
  24. ashaikh (1)
  25. abhijitkumbhare (1)
  26. mohnish (1)
  27. dmentze (1)
  28. hideyuki (1)


Generated by MeetBot 0.1.4.