Jump to: navigation, search

Simultaneous Release:Lithium Release Plan

Introduction

This is a Simultaneous Release Plan for the Lithium release of OpenDaylight. Note that it is the third release plan and marks a somewhat significant departure from the previous two. As a consequence, please read it carefully to understand the requirements to participate and for each milestone.

Projects may choose to participate or not based upon their readiness and desire to join the Simultaneous Release. This plan is structured as laid out in the OpenDaylight Project Lifecycle.

Definitions

  • APIs: For the purposes of being declared Stable, Provisional, or Tentative, an API is a collection of code that provides some high-level functionality, e.g., flow programming or MD-SAL data store access. When listed on a release plan, APIs should be given a short name, classified into one of the three categories, and have the supporting bundles (if/when they exist) listed as well.
    • Stable API: An API that can be accessed external to your project, existed in a previous version of ODL, and will continue to exist in the current version of ODL with no changes. By definition, all Stable APIs are frozen throughout this entire release cycle. Note that all APIs are assumed to be Stable APIs unless called out as Provisional and/or Tentative in a release plan.
    • Provisional API: An API that can be accessed external to your project and is introduced in the current release, or an externally accessible API that existed in a previous version of ODL but is being modified for the current release.
    • Tentative API: A Provisional API that will be provided in a best effort manner, but which may or may not be delivered in the final release. The Go/NoGo status of Tentative APIs must be made by M3.
  • Functionality Freeze: No new externally visible functionality is to be added to the current release of ODL. All provisional APIs are at least functional (at a beta-quality level) if not yet fully tested.
  • API Freeze: All externally accessible APIs (Stable and Provisional) may not be modified. An API exception process (similar to the one used in helium) will allow for critical changes to APIs after API freeze with the consent of the consuming projects. APIs include, but are not limited to, all Java classes/interfaces declared public and exported from an OSGi bundle, all YANG models, all Karaf feature names/locations, and all REST/RESTCONF calls including the full URL with options.
  • Code Freeze: No new features/functionality are to be allowed into the current release. Only errors/bugs identified in the bugzilla system are allowed. The exceptions to this include new tests, and documentation. Distribution (Karaf) packaging must be complete. Errors/bugs found after Code Freeze are still bugs and they may be created and worked on. This includes packaging bugs found as well.
  • String Freeze: All text strings used within ODL may not be changed. Final documentation and localization teams may rely on these strings not changing for the current release.
  • Release Candidate (RC): A fully-built, complete version of the current ODL release. This includes all code, documentation, and packaging that make up the final user-deliverable set of artifacts. After RC0, new RCs will be continually built, e.g., once per day, to enable rapid testing and fixing of bugs.
    • Note that this definition makes the dates for RCs and the final release as targets, but they may need to be adjusted based on project readiness and any remaining blocking bugs.
    • The notion of RC#s will remain to aid in planning when bug fixes are expected.
    • During the RC process blocking bugs will be tracked both on a spreadsheet and in bugzilla.
    • During the RC process regular, e.g., daily, meetings will be held on IRC to identify and address critical issues as they arise.

Project Offsets

Projects are classified into one of 3 offsets:

  • offset zero: deadlines are at the dates listed
  • offset one: deadlines are generally1 at the listed dates + 2 weeks
  • offset two: deadlines are generally1 at the listed dates + 4 weeks
    • Note that the intent is that offset two projects have no other projects depending on them in this release

This is intentionally flattening the the actual dependency graph

  • The full project-level graph is at least 8 levels
    • e.g., odlparent => yangtools => controller => openflowjava => openflowplugin => sfc => ovsdb => groupbasedpolicy
  • The idea is to hit an 80/20 point where projects can have some lag to get new APIs from those they depend on
    • If projects are in the same offset but need APIs from each other this should be noted and planned (possibly by asking for them sooner than would be required) as part of the API request negotiation at M2

The intent is for projects that form key infrastructure of all other projects (e.g., odlparent, yangtools, and controller) to operate at offset zero, projects which provide key network services (e.g., OpenFlow and OVSDB) to operate at offset one, and projects that others don't depend on to operate at offset two.

1Deadlines for Release Candidates (RC0, RC1 and RC2) and the release are the same regardless of offset. Deadlines for M1 and M2 are offset by +1 week and +2 weeks. Full details can be found in the dates listed in the Schedule table.

Requirements for Participation

In order to participate in the simultaneous release, a project must do the following things.

  1. Planning
    • Projects must declare their intent to participate in the Simultaneous Release by M1. This is accomplished by adding the project to the table in participating projects and sending the first milestone readout mail.
    • Participating projects must publish a candidate Release Plan by M1 and declare their final Release Plan by M2
      • Participating project Release Plans must contain Milestones that minimally line up with the Simultaneous Release Plan Milestones
      • Per-project release plans now include sections for cross-project negotiation of provided APIs and for noting cross-project incompatibilities.
        • Projects are required to negotiate cross-project dependencies for any new or modified APIs.
        • Projects are encouraged to think about and cross-project incompatibilities and how to resolve them, if possible, as part of their release plans.
  2. Leadership & Communication
    • Each project must elect a Project Lead as described in the TSC charter, section 7.
      • Phil Robb will help projects with this process and it must be completed by M1.
      • The results of the election, and other changes to the project lead during this release, should be reported by
        1. Updating the project facts template for the project on its main wiki page
        2. Updating the participating projects table of this release
        3. Sending an e-mail the <project>-dev, release, and tsc lists
    • The Project Lead is expected to be responsible for the the project meeting deadlines, interacting with other projects, and interacting with the TSC
    • The Project Lead will be subscribed to the release mailing list and must respond to requests send to the a timely fashion—defined as 48 hours excluding weekends.
      • If a Project Lead is not be able to do so, they should (i) have somebody else stand in and do this on their behalf, (ii) send a mail to the release mailing list indicating this and the time period, and (iii) note the same information in the participating projects section of the release plan.
    • All release-critical correspondence that requires a response will have a subject line containing "PLEASE RESPOND BY <DATE> <UTC-TIME>"
      • Please limit traffic to correspondence directly relating to the release
      • The TSC should collect response time metrics for projects both to inform our planning and to measure project maturity going forward.
  3. Service Release Participation
    • All projects participating in the release are also required to participate in the two stability releases after the formal release.
  4. Modularity
    • Modules that are not intended to interface with the controller via REST/other non-Java RPC mechanism must be OSGi bundles.
    • OSGi bundles should be reasonably granular.
    • OSGi bundles should be grouped into Karaf features by M3 including possibly defining some features as user-facing.
  5. Quality
    • No later than M2, each project must have a "-verify" Jenkins Job which verifies that the project builds and passes test for each new patch pushed to gerrit.
    • No later than M2 as part of the Gerrit/Jenkins merge process, i.e., the Jenkins "-merge" job, participating projects must push their binary artifacts to the Nexus repository
    • No later than M2, each project must have a Jenkins Job which rebuilds and retests to an appropriate level when a project it depends on publishes new artifacts, i.e., a Jenkins "-integration" job.
    • No later than M2, each project primarily written in Java must be reporting unit test coverage via sonar.
      • Projects, especially ones that form key infrastructure for other projects, are strongly encouraged to set goals for code coverage and reported bugs. Doing so will be seen favorably when evaluating projects for advancement in the [Project Lifecycle].
  6. Testing
    • In addition to setting up appropriate Jenkins -verify, -merge, and -integration jobs by M2, projects are expected to provide adequate unit, integration and system tests.
    • The coverage provided by unit tests and integration tests should be reported to sonar by M2.
    • Participating projects must describe one system test per user-facing feature by M3 and have those system tests running on or after each -merge job by M5.
    • Further details and requirements can be found in the schedule below as well as the Lithium Project Documentation Requirements.
  7. Documentation
    • Each participating project is expected to identify the kinds of documentation that would be useful (e.g., installation guide, user guide, developer guide) and provide them as part of the release.
    • More details on the expectations can be found in the schedule below as well as the Lithium Project Integration Requirements.
  8. Code Hygiene
    • No uses of System.out.println in non-test code.
    • No dependencies on 3rd party (non-ODL) snapshot versions
    • Willing to use agreed-upon versions for dependencies (both 3rd party and ODL), i.e., to eliminate version skew
  9. Distribution
    • All projects must support a Karaf-based distribution model including defining Karaf features no later than M3.
  10. Meeting Deadlines
    • All projects are expected to meet the deadlines laid out in the schedule below.
      • To indicate this, the project lead/contact is expected to provide send a milestone readout to the release mailing list by 23:59:59 UTC on the date listed for the the appropriate offset at each milestone.
      • Most information will be communicated by filling out appropriate information in the release tracking spreadsheet, but a mail should still be sent indicating that the information has been filled in. Any other information or questions can be included in that mail.
    • If a project cannot make a deadline, the project lead/contact must write a summary of what was missed, why, the course correction that will be taken, and it's impact on other projects.
      • For offset two project this is mainly intended to be reflective and to help inform the release process.
      • For offset zero and offset one projects, this should be completed with 24 hours of missing the deadline and must be presented to the TSC at the first TSC meeting after the deadline.
    • All Milestone deliverables will be verified by the Lithium release management staff and/or the TSC.
      • NOTE: For deliverables defined only in the project's release plan—and not as a requirement in this document—the release management staff and/or TSC will verify that the status of the deliverables has been reported. Lithium release management staff and/or the TSC may also, but are not required to, verify the delivered functionality.

Milestones, Release Candidates, and Service Releases

  • Milestones are spaced roughly 4 weeks apart taking into account significant holidays.
  • Release Candidates (RC) are spaced 2 weeks apart
  • Service Releases are roughly 6 weeks and 12 weeks after the Formal Lithium Release.


Schedule Framework

This Simultaneous Release plan has been drafted based on the Schedule Framework


Schedule

2The deadline to meet and report the results of each milestone is at 23:59:59 UTC on the listed day. That corresponds to 4p or 5p pacific time.

Milestone Offset 0 Date2 Offset 1 Date2 Offset 2 Date2 Events
M0 11/11/2014 N/A N/A
  • Lithium Simultaneous Release Open
  • Note: the date for M0 will be the day after the TSC approves the Lithium release plan.
Last date for project proposals 11/27/2014 12/4/2014 12/25/2014

This is the latest date a project proposal can be sent to the project-proposals list and still have the required two week public comment period before its project creation review at the last TSC meeting before the M1 milestone. Project proposals submitted after this date will not be able to become formal projects by M1 and thus will not be able to participate in the Lithium release.3

M1 12/11/2014 12/18/2014 1/8/2015
  1. Projects must have declared intent to participate in Simultaneous Release
  2. Projects must have elected their Project Leads and specify a Test Contact
  3. Participating Projects must have published a candidate Release Plan for public comment ( Release Plan Template )
    • Note that the release plan includes details about negotiating inter-project dependencies, expectations, and incompatibilities.
New Project Infra 12/18/2014 1/8/2015 1/15/2015

Date that LF Infrastructure must be complete for all new projects: Git/Gerrit/Bugzilla/Mailing List/etc. so that new projects can meet their M2 deliverables.

M2 1/22/2015 1/29/2015 2/5/2015
  1. Participating Projects must have declared their final Release Plan with all sections fully completed.
  2. Project Checklist completed (for all projects, not just new ones).
  3. Projects must specify (in the release plan) whether they are going to use OpenDaylight CI infrastructure for system test. It is recommended to use the OpenDaylight CI infrastructure unless there is some resource that is not available there, e.g., particular hardware or software.
  4. Start Test tools installation in rackspace. Projects that need any extra configuration or resources for test in the OpenDaylight CI infrastructure must have opened helpdesk tickets to add the configuration or resources.
  5. Project must get acknowledged from all projects that it depends on.
M3 2/19/2015 3/5/2015 3/19/2015
  1. Functionality Freeze
    • Final list of externally consumable APIs defined and documented
      • Projects must state for each TENTATIVE API they have (if any) whether they are formally planning to deliver it.
        • If so, it should be noted that it will be delivered.
        • If not projects requesting the API must be informed so that they can take corrective actions.
      • Externally consumable APIs are available at beta-quality
    • All inter-project dependencies are resolved (all project functionality is declared as either "In" or "Out" of this release)
  2. Karaf Features defined
    • Instructions can be found in the Karaf:Step by Step Guide
    • Any feature repositories containing features intended for release must be added to the main features.xml file in the integration git repository
    • Features that are intended to be "user-facing" must be called out in the milestone readout
      • Note: These features will have additional documentation requirements, i.e., for each such feature (or group of intimately related features) must have a user guide section. See Lithium Project Documentation Requirements.
    • Changing the name of a Karaf feature or removing a Karaf feature should be handled via an API freeze waiver after this point
  3. Documentation Started
    • Identified the kinds of documentation to be provided, created AsciiDoc files for them with outlines, and committed those files in an appropriate location
    • More details can be found in the Lithium Project Documentation Requirements
  4. Integration & System Test
M4 3/19/2015 4/2/2015 4/16/2015
  1. API Freeze: See more information in the definition above.
  2. Documentation: Project readouts MUST include a word count of each relevant .adoc file with a goal of draft documentation done.
  3. Projects are encouraged to meet the requirements to be included in maven central
    • Project readout MUST include whether or not this was accomplished
  4. Integration & System Test
    • Participating projects must run a simple system test on a karaf distribution with the project's recommended features installed on Code Merge (e.g. merge job), any upstream project Code Merge (e.g. integration job), as well as Release Creation events, e.g., weekly, RC and formal releases4.
M5 4/16/2015 4/30/2015 5/14/2015
  1. Code Freeze (bug fixes only from here as defined above)
  2. Stability branch, i.e., stable/lithium, must be cut and local project versions bumped on master to avoid overwriting lithium SNAPSHOTS
  3. String Freeze (all externally visible strings frozen to allow for translation & documentation)
  4. Documentation Complete: Only editing and and enhancing should take place after this point.
  5. Integration & System Test
    • The system test for each user-facing feature must be complete and should run on Code Merge (e.g. merge job), any upstream project Code Merge (e.g. integration job), as well as Release Creation events, e.g., weekly, RC and formal releases4.
RC0 (Delayed) 5/28/2015 N/A N/A
  1. The build for RC0 will start at 23:59:59 UTC on 5/28/2015
  2. During the RC process, regular, e.g., daily, IRC meetings will take place to identify and address issues
  3. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
RC0 6/4/2015 N/A N/A
  1. The build for RC0 will start at 23:59:59 UTC on 6/4/2015
  2. During the RC process, regular, e.g., daily, IRC meetings will take place to identify and address issues
  3. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
RC1 6/11/2015 N/A N/A
  1. The build for RC1 will start at 23:59:59 UTC on 6/11/2015
  2. During the RC process, regular, e.g., daily, IRC meetings will take place to identify and address issues
  3. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
RC2 6/18/2015 N/A N/A
  1. Participating Projects must hold their Release Reviews, including User Facing Documentation.
    • The release review should be based on the Sample Release Review include or point to release notes based on Sample Release Notes.
    • The release notes MUST also be translated into AsciiDoc to be included in the Lithium documentation
  2. The build for RC2 will start at 23:59:59 UTC on 6/18/2015
  3. During the RC process, regular, e.g., daily, IRC meetings will take place to identify and address issues
  4. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet
Formal Lithium Release 6/25/2015 N/A N/A
  1. Formal Lithium Release
    • NOTE: The build to produce the formal release artifacts is likely to occur before 6/25/2015.
  2. After the release, projects MUST apply the release patch to the stable/lithium branch and bump versions
    • This corresponds to steps 2 and 7 in the instructions on cutting stability branches
    • Projects MUST not merge any patches to stable/lithium prior to applying the release and version bump patches. Patches merged to stable/lithium in this window will have to be reverted before the release and version bump patches can be applied.
SR1 (Service Release 1 aka Lithium.1) 8/20/2015 N/A N/A
  1. First Service Release for Lithium. NOTE: This date is provisional, but will not move earlier. Please note, event based Updates (security/critical bugs) are distinct and may occur at any point.
    • To allow time for testing, a release candidate will be built before the service release and projects are expected to not merge patches except for blocking bugs between that time and the actual service release.
    • Blocking bugs will be tracked via bugzilla and a spreadsheet.
  2. After the release, projects MUST apply the release patch to the stable/lithium branch and bump versions
    • This corresponds to steps 2 and 7 in the instructions on cutting stability branches
    • Projects MUST not merge any patches to stable/lithium prior to applying the release and version bump patches. Patches merged to stable/lithium in this window will have to be reverted before the release and version bump patches can be applied.
SR2 (Service Release 2 aka Lithium.2) 10/8/2015 N/A N/A
  1. Second Service Release for Lithium. NOTE: This date is provisional, but will not move earlier. Please note, event based Updates (security/critical bugs) are distinct and may occur at any point.
    • To allow time for testing, a release candidate will be built before the service release and projects are expected to not merge patches except for blocking bugs between that time and the actual service release.
    • Blocking bugs will be tracked via bugzilla and a spreadsheet.
  2. After the release, projects MUST apply the release patch to the stable/lithium branch and bump versions
    • This corresponds to steps 2 and 7 in the instructions on cutting stability branches
    • Projects MUST not merge any patches to stable/lithium prior to applying the release and version bump patches. Patches merged to stable/lithium in this window will have to be reverted before the release and version bump patches can be applied.
SR3 (Service Release 3 aka Lithium.3) 11/19/2015 N/A N/A
  1. Second Service Release for Lithium. NOTE: This date is provisional, but will not move earlier. Please note, event based Updates (security/critical bugs) are distinct and may occur at any point.
    • To allow time for testing, a release candidate will be built before the service release and projects are expected to not merge patches except for blocking bugs between that time and the actual service release.
    • Blocking bugs will be tracked via bugzilla and a spreadsheet.
  2. After the release, projects MUST apply the release patch to the stable/lithium branch and bump versions
    • This corresponds to steps 2 and 7 in the instructions on cutting stability branches
    • Projects MUST not merge any patches to stable/lithium prior to applying the release and version bump patches. Patches merged to stable/lithium in this window will have to be reverted before the release and version bump patches can be applied.
SR4 (Service Release 4 aka Lithium.4) 3/3/2016 N/A N/A
  1. Second Service Release for Lithium. NOTE: This date is provisional, but will not move earlier. Please note, event based Updates (security/critical bugs) are distinct and may occur at any point.
    • To allow time for testing, a release candidate will be built before the service release and projects are expected to not merge patches except for blocking bugs between that time and the actual service release.
    • Blocking bugs will be tracked via bugzilla and a spreadsheet.
  2. After the release, projects MUST apply the release patch to the stable/lithium branch and bump versions
    • This corresponds to steps 2 and 7 in the instructions on cutting stability branches
    • Projects MUST not merge any patches to stable/lithium prior to applying the release and version bump patches. Patches merged to stable/lithium in this window will have to be reverted before the release and version bump patches can be applied.

3Please note that the TSC reserves the right to allow projects to enter the Simultaneous Release for a reasonable period of time after the M1 date. For example, the TSC may allow additional time if a project is delayed by the IPR Review process.

4Projects running system tests outside the OpenDaylight CI infrastructure are not required to run system tests and report the results on "-merge" and "-integration" Jenkins jobs, although if they can this is ideal. They are required to report system test results in a timely fashion after release creations, e.g., weekly, RC, and formal releases.

Please also note that projects that would like to spin out parts of themselves into additional projects may have those new projects join the Simultaneous Release at any point prior to M3 provided:

  1. The TSC has been informed of this intent prior to M3
  2. The original project's release Release Plan is apportioned between the original and new projects with no parts missing
  3. The new projects have been proposed and approved by the TSC into one of the non-proposed life-cycle states in the normal manner by M3
  4. The new projects have completed the requirements for all milestones before they joined the release, e.g., M1 and/or M2

Lastly, note that as the new projects are joining the release prior to M3, they must meet all the requirements for M3 at the normal time.

Participating Projects

Participating projects should list themselves here prior to M1, with a link to their Project wiki page and their Release Plan.

Offset 0 Projects

Project Status Release Plan Offset Project Lead/Contact Contact Email Test Contact Docs Contact
Controller GREEN Release Plan 0 Tony Tkacik ttkacik@cisco.com Tony Tkacik (ttkacik@cisco.com) Tony Tkacik (ttkacik@cisco.com)
ODL Parent GREEN Release Plan 0 Surekha Bejgam sbejgam@cisco.com Surekha Bejgam (sbejgam@cisco.com) Surekha Bejgam (sbejgam@cisco.com)
YANG Tools GREEN Release Plan 0 Robert Varga rovarga@cisco.com Tony Tkacik (ttkacik@cisco.com) Surekha Bejgam (sbejgam@cisco.com)

Offset 1 Projects

Project Release Plan Offset Project Lead/Contact Contact Email Test Contact Docs Contact
AAA Release Plan 1 Wojciech Dec wdec@cisco.com Jamo Luhrsen (jluhrsen@redhat.com) John Borz (john.borz@hp.com)
BGPCEP Release Plan 1 Dana Kutenicsova
Robert Varga
dkutenic@cisco.com Vratko Polak (vrpolak@cisco.com) Dana Kutenicsova (dkutenic@cisco.com)
DLUX Release Plan 1 Harman Singh harmasin@cisco.com Harman Singh Harman Singh (harmasin@cisco.com)
L2 Switch Release Plan 1 Amit Mandke ammandke@cisco.com Alex Fan (alefan@cisco.com) Amit Mandke or Alex Fan
Lisp Flow Mapping Service Release Plan 1 Vina Ermagan
Lori Jakab
vermagan@cisco.com
lojakab@cisco.com
Lori Jakab (lojakab@cisco.com) Vina Ermagan (vermagan@cisco.com)
Neutron Nourthbound Release Plan 1 Ryan Moats rmoats@us.ibm.com Ryan Moats (rmoats@us.ibm.com) Ryan Moats (rmoats@us.ibm.com)
ODL SDNi App Release Plan 1 Shahid Shaik shahid.b@tcs.com Shravani N(shravani.n@tcs.com) Swetha(swetha.s8@tcs.com)
Openflow Java Release Plan 1 Michal Polkorab michal.polkorab@pantheon.sk Michal Polkorab (michal.polkorab@pantheon.sk) Michal Polkorab (michal.polkorab@pantheon.sk)
Openflow Plugin Release Plan 1 Abhijit Kumbhare abhijitkoss@gmail.com Jamo Luhrsen (jluhrsen@redhat.com) Abhijit Kumbhare (abhijitkoss@gmail.com)
Persistence Store Service Release Plan 1 Fabiel Zuniga fabiel.zuniga@hp.com Fabiel Zuniga (fabiel.zuniga@hp.com) Fabiel Zuniga <fabiel.zuniga@hp.com>
SNBI Release Plan 1
SNMP4SDN Release Plan 1 Christine Hsieh ylhsieh@itri.org.tw Yi-Ling (Christine) Hsieh Christine Hsieh (ylhsieh@itri.org.tw)
SNMP Plugin Release Plan 1 Adam Dierkens adam@dierkens.com Adam Dierkens (adam@dierkens.com) Adam Dierkens (adam@dierkens.com)
Source-Group Tag eXchange Protocol (SXP) Release Plan 1 Matthew Robertson mrobertson@lancope.com Matthew Robertson (mrobertson@lancope.com) Matthew Robertson (mrobertson@lancope.com)
TCP-MD5 Release Plan 1 Robert Varga rovarga@cisco.com Robert Varga <rovarga@cisco.com> Dana Kutenicsova (dkutenic@cisco.com)
Topology Processing Framework Release Plan 1 Michal Polkorab michal.polkorab@pantheon.sk Michal Polkorab (michal.polkorab@pantheon.sk) Michal Polkorab (michal.polkorab@pantheon.sk)

Offset 2 Projects

Project Release Plan Offset Project Lead/Contact Contact Email Test Contact Docs Contact
ALTO Release Plan 2 Y. Richard Yang yry@cs.yale.edu Y. Richard Yang (yry@cs.yale.edu) Y. Richard Yang (yry@cs.yale.edu)
CAPWAP Release Plan 2 Sajan Liyon sliyon@brocade.com Mahesh Govind (vu3mmg@gmail.com)
Controller Core Function Tutorial Release Plan 2 Tom Pantelis
Keith Burns
tpanteli@Brocade.com
alagalah@gmail.com
Jan Medved (jmedved@cisco.com)
Defense4All Release Plan 2 Benny Rochwerger bennyr@radware.com Gershon Sokolsky (gershons@radware.com)
DIDM Release Plan 2 Gunjan Patel gupatel@ciena.com Gunjan Patel (gupatel@ciena.com) Gunjan Patel (gupatel@ciena.com)
Documentation Release Plan 2 Colin Dixon
Manny Set
colin@colindixon.com
eset@cisco.com
N/A
Group Based Policy (GBP) Release Plan 2 Keith Burns alagalah@gmail.com Thomas Bachman (tbachman@yahoo.com) Thomas Bachman (tbachman@yahoo.com)
Integration Group Release Plan 2 Luis Gomez ecelgp@gmail.com Luis Gomez (ecelgp@gmail.com)
IoTDM Release Plan 2 John Burns
Lionel Florit
johnburn@cisco.com
lflorit@cisco.com
John Burns (johnburn@cisco.com )
LACP Release Plan 2 C Venkataraghavan C_Venkataraghavan@DELL.com C Venkataraghavan (C_Venkataraghavan@DELL.com) C Venkataraghavan (C_Venkataraghavan@DELL.com)
Network Intent Composition (NIC) Release Plan 2 David Bainbridge
Raphael Amorim
dbainbri@ciena.com
raphael.amorim@hp.com
OpenvSwitch Database Integration Project Release Plan 2 Sam Hague shague@redhat.com Flavio Fernandes (ffernand@redhat.com) Eric Multanen (eric.w.multanen@intel.com)
Gabriel Montpetit
Opflex Release Plan 2 Rob Adams
Keith Burns
readams@readams.net
alagalah@gmail.com
Keith Burns (alagalah@gmail.com)
PacketCable PCMM Release Plan 2 Kevin Kershaw k.kershaw@cablelabs.com Kevin Kershaw (k.kershaw@cablelabs.com) Kevin Kershaw (k.kershaw@cablelabs.com)
Release Engineering - autorelease Release Plan 2 Thanh Ha
George Zhao
thanh.ha@linuxfoundation.org
george.y.zhao@huawei.com
Thanh Ha (thanh.ha@linuxfoundation.org) George Zhao (george.y.zhao@huawei.com)
Reservation Release Plan 2 Mathieu Lemay mlemay@inocybe.com Gabriel Robitaille Montpetit ( grmontpetit@inocybe.com )
SFC Release Plan 2 Brady Johnson brady.allen.johnson@ericsson.com brady.allen.johnson@ericsson.com Chris Price (chrispriceab@gmail.com)
Table Type Patterns (TTP) Release Plan 2 Curt Beckmann beckmann@brocade.com Colin Dixon ( colin@colindixon.com ) Curt Beckmann ( beckmann@brocade.com )
TSDR Release Plan 2 Yuling C Yuling_C@Dell.com Yuling C <Yuling_C@Dell.com> Yuling C <Yuling_C@Dell.com>
Unified Secure Channel Release Plan 2 Helen Chen helen.chen@huawei.com Helen Chen (helen.chen@huawei.com) An Ho (an.ho@huawei.com)
VPN Service Release Plan 2 Prem Sankar G prem.sankar.g@ericsson.com Kanagasundaram.K (Kanagasundaram@ericsson.com)
VTN Release Plan 2 Hideyuki Tai Hideyuki.Tai@necam.com Hideyuki Tai (Hideyuki.Tai@necam.com)

Project Status

Lithium Project Status

RC Download

Lithium SR1 Download

Lithium SR2 Download

Lithium SR3 Download

Lithium SR4 Download

Release Reviews

  • The schedule is listed in this Google sheet
  • Action items from release reviews are tracked in this Google sheet
  • 6/17/2015
    • LACP
    • Neutron
  • 6/22/2015
    • BGPCEP
    • TCPMD5
    • SNBI
    • controller
    • yangtools
    • TTP
    • SNMP
  • 6/23/2015
    • OpenFlow Protocol Library (openflowjava)
    • Topology Processing Framework (topoprocessing)
    • SDN Interface (sdninterfaceapp)
    • OVSDB Integration (ovsdb)
    • OpFlex
    • SXP
    • L2switch
    • OpenFlow Plugin (openflowplugin)
    • DLUX
    • USC
    • CAPWAP
    • VTN
    • IoTDM
  • 6/23/2015
    • VPN Service
    • SNMP4SDN
    • LISP Flow Mapping
    • ALTO
    • SFC
    • odlparent
    • Reservation
    • Group Based Policy
    • Persistence
    • TSDR
    • DIDM
    • PCMM/PacketCable
  • AAA Release Review over e-mail

Project Dependency Diagram

Diagram Source


Opendaylight Lithium Project Dependency Diagram.jpg

Communication Channels

Mailing List

The release mailing list (release@lists.opendaylight.org) is the formal channel for communication about the Simultaneous Release.

Please limit mail to this list to things that directly concern the release as our goal is to keep it's volume at a level that allows the project lead/contact to read all of it.

Per-project Simultaneous Release Contact

Each project participating in the Simultaneous Release should designate a committer to be the contact for that project for that Simultaneous Release. It is expected that this be the project lead for most projects. Even though a primary contact other than the project lead can be designated, the project lead is still expected to be ultimately responsible for the project's participation in the release.

Cross Project Milestone and Release Candidate Reporting

At each milestone, each project is expected to send a readout to the release mailing list by 23:59:59 UTC on the date listed for the given milestone and offset. Most information will be reported via the release tracking spreadsheet, which can be found in the supporting documents section. While most information will be reported via the spreadsheet, projects should still send a mail indicating the information has been filled in, reporting any extra information, and possibly asking additional questions. Reported information will include things like links to gerrit patches, pointers to continuous integration Jenkins Jobs, and the like.

Negative statuses should be reported promptly. If a project is under threat of, or does miss an element on its release plan, the project contact/lead should report this as soon as it is known. They should not wait until the next milestone's readout.

It is the responsibility of each project's lead to report both positive and negative statuses. While they can delegate the task, the project lead is still ultimately responsible for the project's participation in the release.

Simultaneous Release Developer Meetings

One week prior to each Milestone or Release Candidate starting at M1, an IRC meeting for developer interested in the Simultaneous Release will be organized for real time coordination and check in. The Project for each project (or their delegate) should minimally be in attendance. This meeting should happen for each offset at each milestone.

Bugs

Bugzilla is used to track all bugs in OpenDaylight. Bugs must be filed for the appropriate project. General guidelines and sample searches can be found on the OpenDaylight Bugs page.

During the release candidate process, all blocking bugs must be both logged on a bug-tracking spreadsheet (to be provided) and filed appropriately, e.g., with severity set to BLOCKING, in Buzilla.

Cross Project Meetings

Cross project meetings are held on #opendaylight-meeting (with no audio) at 7:30a pacific time. In general, past meeting minutes can be found here: https://meetings.opendaylight.org/opendaylight-meeting/2015/weekly_lithium_irc_sync/

Agenda: 3/4/15 Wed 7:30am PST

  • Action Items From Previous Meeting
  • Topics of general concern
    • Build failures on the night of 3/3/15 from what looks like git clone issues (Keith Burns for 3/4/15 meeting)
    • <Insert topics here>
  • Any questions about Integration and Test requirements
    • <Insert question here>
  • Any questions from one project to another (Enter your questions here anytime prior to the meeting)
    • <Insert question here>
  • Announcements of any potential changes from a project that may affect other projects
    • <Insert Announcement Here>

Agenda Items for Past Cross-Project Meetings

  • Any questions on what should, or should not be in a release plan
    • <Insert question here>
  • If you would like to have the TSC and other Project Leaders review your release plan and provide feedback to you, please include it below.
    • <Insert URL of release plan to review>

Information from Past Cross-Project Meetings

Note: There is a link to full logs at the top of the minutes page. If you would like to see the minutes in plaintext replace .html with .txt. If you would like to see the full logs in plaintext replace the .html with .log.txt.

  • May Lithium Cross-Project Syncs

Supporting Documents

Lessons from Hydrogen, Helium and Lithium for future releases

  • Service releases should likely continue until some future release (either one or two releases in the future) rather than after a fixed number of releases.
    • How long after the new release do we wait?
    • Do we want to have a specified amount of overlap? 2 weeks? 6 weeks?
  • We desperately need pre-made templates for each milestone that make verifying requirements easy. We just missed things in Lithium M1 to M3 without that.
  • We need to mandate source jars generated in a canonical way, i.e., to be consumed by releng/autorelease.
  • We should also mandate javadoc generated in a canonical way, i.e., to be consumed by releng/autorelease.
  • Migration
    • Do we want to require data schema translations?
    • Other issues?
  • The paperwork for M3 was substantial (and not easy see in advance) and should be streamlined or spread out
    • Consolidating all the requirements into one place would likely help.
  • We should make sure that people know where to produce and document known issues. In general, it's three places:
    • The release mailing list.
    • The Weather page.
    • The weekly IRC sync during the last part of the release.
  • Make it clear what is expected of projects in terms of tracking what's going on in ODL.
    • Reading the release list.
    • Reading tsc list or at least the TSC meeting minutes.
    • Attending release IRC meetings or at least reading the minutes.
  • Adding a way to deal with docs-like projects that don't provide code-level negative interactions
    • This includes at least docs, toolkit (now mostly defunct), and coretutorials
    • Ideally, they might have laxer requirements
  • Deal with cutting branches and version bumps with offsets
    • If we cut branches and version bump at the same time, the only issue we have is slow projects that can hold things up, which has been fixed by automated version bumping that should happen for Helium.
    • However, if we cut branches and version bump at M5, there is an offset between different projects where upstream projects can merge patches that break downstream projects causing the version bump for downstream projects to fail.
    • The options seem to be:
      1. cut branches all at the same time, which has the disadvantage that offset 0 and offset 1 projects have a 4-week and 2-week period after code freeze where they can't add new features
      2. figure out how to deal with the issue that offset 1 and offset 2 projects may get hit with incompatibilities on version bumps
    • Also, cascading tests during staggered branch cutting breaks because the way JJB is set up right now it's not possible to trigger jobs across branches even when logically master of an offset 1 project is dependent on stable/lithium of an offset 0 project.
  • Docs improvements
    • We'd really like to be able to put project-specific docs in their repo
      • This should include the ability to directly pull code fragments from real code
    • We'd really like HTML versions of the docs that aren't so fragmented

Lessons from Hydrogen/Helium that Should be Applied

Items that are stuck out have been addressed. A comment will follow as to how it was addressed in blue if it seems like the right approach and in red if there may still be debate or questions. Similarly, comments in goldenrod note things that still need to be addressed, but are not blocking certifying the release plan.

  • The Release plan doesn't take into account project dependencies. e.g. M4 API Freeze. If a project is waiting on API freeze for a project it is dependent on, then that reduces the amount of time the "dependee" has to execute. - alagalah (Keith) Done, mainly by moving deadlines up by one step, e.g., M2 component free, M3 API freeze, M4 code freeze
    • We had offsets in Hydrogen, spaced at 2 days. We need 2-3 weeks between offsets for them to make sense,
    • With 6 offsets 2 weeks each we need additional 10 weeks to reach RC0 on all projects,
      • Can we can do it in 3 offsets: +0, +2 weeks, +4 weeks
        1. odlparent, yangtools, and controller
        2. openflowjava, openflowplugin, ovsdb, aaa
        3. everyone else
    • Which means lower-offset projects can (and need) to start their next-release while the SR process is finishing
  • We need a Feature Freeze milestone before the API freeze
    • It should occur at M3 with beta-quality APIs, so downstream projects can start consuming Currently at M2 instead, it will be ~M2.5 and ~M3 for most projects
  • We're using release@lists.opendaylight.org instead of discuss
  • We should make it easy for projects to convey and understand what APIs they are intending to make available vs. which ones are intended to be internal attempted as part of component/API freeze
  • We should make it clear that participation in Service Releases is not optional done, see #Requirements for Participation
  • We should make it clear what we expect in terms of timely responses from project primary contacts for a release done, see #Requirements for Participation
    • This involves identifying what mails that people should pay attention to, e.g., ones sent to release@lists.opendaylight.org with "PLEASE RESPOND" in the subject
    • It also involves identifying a time frame in which they should respond, e.g., two business days
      • One concrete stab at making this formal would be: "Technically, two business days will be defined as 48 hours not counting 2a UTC on Friday until 2a UTC on Sunday. This corresponds to 48 hours starting at 4p on Friday in the furthest ahead time zone (UTC+14). Note that this means if you want a response *this* week, you must send it before 2a UTC on Wednesday. That’s 6/7p pacific time on Tuesday in the Pacific time zone." The formal definition is currently left out
  • We need a longer time between code freeze and release candidates because developers don't focus on tests (especially system and integration tests) until after code freeze
  • Status reports for each milestone should include more than a Boolean for tests
    • In general, the templates for status reports should probably be developed more in advance. see milestone readout templatesabove
  • We need to make it clear what tasks need to be done for docs, where and when handled by the deliverable from M2 from docs
    • Understanding the kinds of documentation we want to generate and who the audience is for each kind is going to be critical
      • e.g., one person's user is likely another's developer
    • The same is true about tests. handled by the deliverable from M2 from integration
  • We really need somebody who groks the things that need to be accomplished at each milestone and can take a glance at the code and jenkins jobs for each project to get an idea of whether they're on track or not. We need to make sure we do this for deadlines M3 and later, e.g., functionality freeze, karaf features defined, API freeze, and code freezeM milestone readout templates make this more doable
  • Requirements to meet at different stages (and especially RCs) should be set and enforced with clearly explained consequences for missing them ways to fix missed deadlines are now discussed by the TSC for offset zero and offset one projects as described in requirements for participation
    • Release throttle branch needs to be cut at RC0 at the latest done at M5 now
  • We need a standard way to track blocking issues: TODO: we still need this, but it's loosely defined in the Helium blocking bugs section here.
    • One suggestion is to treat them as bugs in bugzilla for easy tracking and querying
      • Projects would file bugs with severity as "critical", "blocker" with the target milestone being appropriate
      • Appropriate milestones are sometimes annoying, but generally, it should be "anything but the next release"
  • We need to pre-declare when RCs and final release artifacts will be cut (both dates and times for clarity) done at M5 and RCs
  • Need to add an EOL-plans section to release plan to understand user impact of EOLed features/components/APIs at the start of a development cycle done in release plan
    • What requirements do we want to place on projects? e.g., deprecated in one release and can remove in another?
    • plans for dealing with EOLed features should be incorporated into the release plan
  • We should reconsider when we set a release date done, there is a month of slack between the release and the ODL summit and the dates for RCs after RC0 and the formal release are stated to be tentative based on testing in the definition of RCs
    • Especially to the press, but also in other environments
    • For example, do we want to have a booked event giving us effectively zero wiggle room on the back end?
      • Maybe, because hard deadlines help get things done, but they also make for sub-optimal
  • We could use more automated release processes
    • For example, the auto-release is really, really nice as compared to spending 14+ hours on IRC cutting everything.
    • A similar process for post-release branch cutting and version bumping would be very helpful, e.g., take a 10+ day process and turn it into one that takes a few hours.
    • One problem is figuring out how to do this w/o requiring involvement from every project (at least on the critical path).
      • Solutions are (i) allowing for some scripts to commit changes to projects, which is likely bad, or (ii) automatically pushing patches for projects to review
      • Another solution is to switch to continuous delivery resolved thanks to Thanh and the autorelease project
  • We should avoid scheduling any major events, e.g., a design forum or summit, immediately after the release so that we can have some room for slippage without having to pull many developers out of the event into a "war" room. done. there is a month between the release and the ODL summit
  • More automated features testing TODO: yes, but this is technical debt, not directly related to the release plan
    • to really test things, we need to blow away the m2 repo before testing every features.xml file
  • Cyclic dependencies TODO: yes, but this is technical debt, not directly related to the release plan
    • We need to decide if we want to allow them, and if so what kind to allow
    • We need to provide documentation (or ideally scripts) that show how to build the code despite the circular dependencies (if we allow them)
    • We need tests to check for circular dependencies (either at all or new ones) so that we know about them
      • The simplest way to do this would be to have an offline auto-release which first clone all the repos and then tried to build them linearly without access to the nexus repos.