8 This is a Simultaneous Release Plan for the Oxygen release of OpenDaylight.
9 This is the eighth release of OpenDaylight and this release plan has some
10 differences from its predecessors. Please read it carefully to understand the
11 requirements to participate and the requirements for each milestone.
13 Projects may choose to participate or not based upon their readiness and
14 desire to join the Simultaneous Release. This plan is structured as laid
15 out in the OpenDaylight :doc:`project-lifecycle`.
22 :APIs: Application Programming Interface. For the purposes of OpenDaylight an
23 API is any form of interface that is exposed to other ODL apps/services
24 and/or exposed to third party services or external applications. This
25 includes all Java classes/interfaces declared public and exported from an
26 OSGi bundle, all YANG models, all Karaf feature names/locations, all config
27 file YANG schemas, and all REST/RESTCONF calls including the full URL with
30 :API Classifications: For the purposes of being declared **Stable**,
31 **Provisional**, or **Tentative**, an API is a collection of code that
32 provides some high-level functionality, e.g., flow programming or MD-SAL
33 data store access. When listed on a release plan, APIs should be given a
34 short name, classified into one of the three categories, and have the
35 supporting bundles (if/when they exist) listed as well.
37 :Stable API: An API that can be accessed external to your project, existed
38 in a previous version of ODL, and will continue to exist in the current
39 version of ODL with no changes. By definition, all Stable APIs are
40 frozen throughout this entire release cycle. Note that all APIs are
41 assumed to be **Stable APIs** unless called out as **Provisional**
42 and/or **Tentative** in a release plan.
43 :Provisional API: An API that can be accessed external to your project and
44 is introduced in the current release, or an externally accessible API
45 that existed in a previous version of ODL but is being modified for the
47 :Tentative API: A **Provisional API** that will be provided in a best
48 effort manner, but which may or may not be delivered in the final
49 release. The Go/NoGo status of Tentative APIs must be made by M2.
54 :Functionality Freeze (M2): *(used to be called feature freeze)*
55 No new externally visible functionality is to be added to the current
56 release of ODL. All provisional APIs are at least functional (at a
57 beta-quality level) if not yet fully tested.
59 :API Freeze (M3): All externally accessible APIs (Stable and Provisional) may
60 not be modified. An API exception process (similar to `the one used in
61 helium <https://wiki.opendaylight.org/view/Simultaneous_Release:Helium:Suggestions_for_Post_API_Freeze_Exception_Handling>`__)
62 will allow for critical changes to APIs after API freeze with the consent of
63 the consuming projects. APIs include, but are not limited to, all Java
64 classes/interfaces declared public and exported from an OSGi bundle, all
65 YANG models, all Karaf feature names/locations, all config file YANG
66 schemas, and all REST/RESTCONF calls including the full URL with options.
68 :Code Freeze (M4): No new features/functionality are to be allowed into the
69 current release. Only errors/bugs identified in the bugzilla system are
70 allowed. The exceptions to this include new tests, and documentation.
71 Distribution (Karaf) packaging must be complete. Errors/bugs found after
72 Code Freeze are still bugs and they may be created and worked on. This
73 includes packaging bugs found as well.
75 :String Freeze (M4): All text strings used within ODL may not be changed. Final
76 documentation and localization teams may rely on these strings not changing
77 for the current release.
79 :Release Candidate (RC): A fully-built, complete version of the current ODL
80 release. This includes all code, documentation, and packaging that make up
81 the final user-deliverable set of artifacts. After RC0, new RCs will be
82 continually built, e.g., once per day, to enable rapid testing and fixing
85 - Note that this definition makes the dates for RCs and the final
86 release as targets, but they may need to be adjusted based on
87 project readiness and any remaining blocking bugs.
88 - While we will build daily release candidates, the notion of RC#s
89 (increasing in number at a longer cadence, e.g., weekly) will
90 remain to aid in planning when bug fixes are expected.
91 - During the RC process blocking bugs will be tracked both on a
92 spreadsheet and in bugzilla.
93 - During the RC process regular, e.g., daily, meetings may be held
94 on IRC to identify and address critical issues as they arise.
95 - Projects not in the autorelease and the distribution feature index
96 by RC0 cutoff will be dropped from the Oxygen release.
101 :Feature: A logical grouping of code and functionality in a project. While a
102 Feature is usually a Karaf feature, it could also be any other component or
105 :Top-Level Feature: A Feature that provides one of the major pieces of
106 functionality delivered by a project. In general, this should not require
107 an understanding of the project's internals to know when/how to install it.
108 Most projects will have a small number of, maybe even only one, Top-Level
109 Features. In many cases the Top-Level Feature will actually only be a
110 meta-feature grouping together lower-level features, which would be less
111 obvious for an outsider to consume.
113 :User-Facing Feature: A Top-Level Feature that somebody looking to install and
114 run OpenDaylight should know about. They should be able to install the
115 Feature and should be able to tell that it's been installed in the form of
116 new user interface elements, support for new southbound devices, or other
117 mechanisms. For example, ``odl-mdsal-broker`` is not a user-facing feature
118 as it does nothing on its own. However, ``odl-mdsal-apidocs`` likely is as
119 it generates a user interface. Features that don't provide explicit user
120 interfaces can still be user-facing. For example, ``odl-bgpcep-bgp``
121 provides no explicit user interface, but does enable BGP support that
122 a user might care about.
124 Stable and Extended Features
125 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
127 :Stable Feature: A Top-Level Feature that meets the following criteria. The TSC
128 is expected to review each potentially stable feature during the project's
129 release review and ensure that it meets these requirements.
133 Any of these requirements can be waived by the TSC for a given feature.
134 However, the TSC is encouraged to find a way to make the test fit the
135 situation before granting a waiver.
137 - The feature must lie within the declared scope of the project.
138 - The feature is part of a Mature project (as defined in the project
140 - The feature was present in the previous release.
141 - The feature is only dependent on other stable features (or
142 sub-components of other stable features).
143 - The feature and its dependencies must meet the `criteria for being
145 Central <http://central.sonatype.org/pages/requirements.html>`__.
146 - The feature provides adequate documentation.
147 - The feature has 75% or higher test coverage as reported by Sonar.
151 You can find individual module/feature test coverage
152 numbers by: (i) going to a sonar report, (ii) click on the
153 percentage under “Overall Coverage”, (iii) use the scrollable
154 list on the left to find the relevant module/bundle. It helps
155 if your feature's code is all under a single subdirectory and
156 that there is nothing else in that directory.
158 - All externally-facing, i.e., accessible from outside the JVM, APIs
159 in the feature must be protected by community-accepted
160 authentication/authorization mechanisms, e.g., using ``aaa-authn``
161 to protect RESTCONF APIs
162 - The feature must have at least one automated test for each of:
164 - *functionality* (previously called a system test) to show the
165 basic functionality works
166 - *cluster compatibility* to show the feature works in a 3-node
167 cluster using the clustered data store
168 - *scalability* to show how large a system, e.g., number of
169 hosts, switches, or links, the feature can handle
170 - *performance* to show how many operations, e.g., transactions,
171 flows, linkstate events, per second the feature can handle
172 - *longevity/stability* to show the feature can run for a period
173 of time under load without ill effect
174 - In each case, the tests must show no unexplained regressions
175 from previous releases.
177 - The feature is backward compatible with the previous release of
178 the feature, e.g., any APIs that were not deprecated in the
179 previous release still exist with the same signatures.
183 This does not prohibit adding new functions, REST URLs, or data
184 items, but typically would prohibit removing or changing existing
187 - The feature has no known vulnerabilities that are older than a
188 week and classified as `important by the security response
189 team <https://wiki.opendaylight.org/view/Security:Vulnerability_Management#Risk_Assessment>`__
190 or `high by their CVSS score in a
191 CVE <https://nvd.nist.gov/cvss.cfm>`__. If a fix for such a
192 vulnerability lies outside of OpenDaylight, the TSC may choose to
193 relax the requirement on a case-by-case basis.
194 - The feature commits to providing a migration strategy from the
195 previous release. This will ideally take the form of scripts or
196 automatic upgrade support, but could also come in the fom of
199 :Extended Feature: A top-level feature that is a part of the Oxygen release and
200 does not meet the Stable Feature criteria.
202 Release Distributions
203 ---------------------
205 :Oxygen Stable Distribution: A Karaf distribution containing the collection of
206 Stable Features as they are compiled into the Oxygen Stable Release Feature
207 Repository hosted in the Integration project.
209 :Oxygen Extended Distribution: A Karaf distribution containing the collection
210 of both Stable and Extended Features as they are compiled in the Oxygen
211 Extended Release Feature Repository hosted in the Integration project.
216 Projects are classified into one of 3 offsets:
218 :offset zero: deadlines are at the dates listed
219 :offset one: deadlines are *generally*\ :sup:`1`\ at the listed dates + 1 week
220 :offset two: deadlines are *generally*\ :sup:`1`\ at the listed dates + 2 weeks
224 The intent is that offset two projects have no other projects depending on them in this release.
226 This is intentionally flattening the actual dependency graph
228 - The full project-level graph is at least 10 levels
230 - e.g., odlparent => yangtools => controller => openflowjava =>
231 openflowplugin => ovsdb => sfc => groupbasedpolicy => nic =>
232 integration/distribution
234 - The idea is to hit an 80/20 point where projects can have some lag to
235 get new APIs from those they depend on
237 - If projects are in the same offset but need APIs from each other this
238 should be noted and planned (possibly by asking for them sooner than
239 would be required) as part of the API request negotiation at M1
241 The intent is for projects that form key infrastructure of all other projects
242 (e.g., odlparent, yangtools, and controller) to operate at **offset zero**,
243 projects which provide key network services (e.g., OpenFlow and OVSDB) to
244 operate at **offset one**, and projects that others don't depend on to operate
247 \ :sup:`1`\ Deadlines for **Release Candidates** (RC0, RC1 and RC2) and the
248 release are the same regardless of offset. Deadlines for M1 through M4 are
249 offset by +1 week and +2 weeks. Full details can be found in the dates listed
250 in the `Schedule`_ table.
252 .. _reqs-for-participation:
254 Requirements for Participation
255 ==============================
257 In order to participate in the simultaneous release, a project must do the
262 - Projects must declare their intent to participate in the
263 Simultaneous Release by M0. This is accomplished by sending the
264 first milestone readout mail and adding the project to the table
265 in `Participating Projects`_.
266 - Participating projects must publish a candidate Release Plan
267 shortly after M0, and declare their final Release Plan by M1.
269 - Participating project Release Plans must contain Milestones
270 that minimally line up with the Simultaneous Release Plan
272 - Release plans should contain a complete list of the exposed
273 :ref:`APIs <api>` including the properties defined above,
274 e.g., the name of the Java interface or YANG-file, a short
275 name, and the list of supporting bundles.
276 - Per-project release plans now include sections for
277 cross-project negotiation of provided APIs and for noting
278 cross-project incompatibilities.
280 - Projects are required to negotiate cross-project
281 dependencies for any new or modified APIs.
282 - Projects are encouraged to think about any cross-project
283 incompatibilities and how to resolve them, if possible, as
284 part of their release plans.
286 #. Leadership & Communication
288 - Each project must elect a Project Lead as described in the `TSC
289 charter <https://www.opendaylight.org/about/governance/tsc-charter>`__,
292 - Phil Robb or Casey Cain will help projects with this process
293 and it must be completed by M0.
294 - The results of the election, and other changes to the project
295 lead during this release, should be reported by
297 #. Updating the project facts template for the project on its
299 #. Updating the `Participating Projects`_ table of this release
300 #. Sending an e-mail to the -dev,
301 `release <mailto:release@lists.opendaylight.org>`__, and
302 `tsc <mailto:tsc@lists.opendaylight.org>`__ lists
304 - The Project Lead is expected to be responsible for the the project
305 meeting deadlines, interacting with other projects, and
306 interacting with the TSC
307 - The Project Lead will be subscribed to the `release mailing
308 list <mailto:release@lists.opendaylight.org>`__ and must respond
309 to requests sent to the project in a timely fashion—defined as
310 **two business days**.
312 - If Project Leads are not be able to do so, they should (i) have
313 somebody else stand in and do this on their behalf, (ii) send a
314 mail to the `release mailing
315 list <mailto:release@lists.opendaylight.org>`__ indicating this
316 and the time period, and (iii) note the same information in the
317 participating projects section of the release plan.
319 - The project lead is expected to, at a minimum, read the `release
321 list <https://lists.opendaylight.org/mailman/listinfo/release>`__,
322 read the `TSC meeting minutes <https://wiki.opendaylight.org/view/TSC:Main#Meeting_Minutes>`__, and
323 read the minutes from the IRC release
324 meetings - see `Simultaneous Release Developer Meetings`_. The
325 project lead is strongly encouraged to attend these meetings if at
326 all possible and some representative from the project is expected
327 to attend each IRC meeting if at all possible.
328 - In addition to the Project Lead, each project must designate a
329 Test Contact and Documentation Contact to handle test related
331 - All release-critical correspondence that requires a response will
332 have a subject line containing “PLEASE RESPOND BY ” or “URGENT
333 RESPONSE REQUIRED/NEEDED”
335 - Please limit traffic to correspondence directly relating to the
337 - The TSC collects response time metrics for projects both to
338 inform our planning and to measure project maturity going
341 #. Service Release Participation
343 - All projects participating in the release are also required to
344 participate in the stability releases described in the
345 `schedule`_ after the formal release.
349 - Modules that are not intended to interface with the controller via
350 REST/other non-Java RPC mechanism must be OSGi bundles.
351 - OSGi bundles should be reasonably granular.
352 - OSGi bundles should be grouped into Karaf features by M2 including
353 possibly defining some features as user-facing.
355 - Each feature should be tested in every appropriate jenkins job
356 (at least -verify, -merge, and -integration) using the
357 “SingleFeatureTest” as defined in the `Karaf step-by-step
358 guide <https://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide>`__
362 - No later than M1, each project must have a “-verify” Jenkins Job
363 which verifies that the project builds and passes test for each
364 new patch pushed to gerrit.
365 - No later than M1 as part of the Gerrit/Jenkins merge process,
366 i.e., the Jenkins “-merge” job, participating projects must push
367 their binary artifacts to the Nexus repository
368 - No later than M1, each project must have a Jenkins Job which
369 rebuilds and retests to an appropriate level when a project it
370 depends on publishes new artifacts, i.e., a Jenkins “-integration”
372 - No later than M1, each project primarily written in Java must be
373 reporting unit and/or integration test coverage via sonar. (See
374 `instructions on reporting test code
375 coverage <https://wiki.opendaylight.org/view/CrossProject:HouseKeeping_Best_Practices_Group:Integration_Test>`__)
377 - Projects, especially ones that form key infrastructure for
378 other projects, are strongly encouraged to set goals for code
379 coverage and reported bugs. Doing so will be seen favorably
380 when evaluating projects for advancement in the `Project
381 Lifecycle <http://docs.opendaylight.org/en/latest/release-process/project-lifecycle.html>`__.
382 - Stable Features must have appropriate unit and/or integration
383 test coverage of at least 75% prior to M4.
387 - In addition to setting up appropriate Jenkins -verify, -merge, and
388 -integration jobs by M1, projects are expected to provide adequate
389 unit, integration and system tests.
391 - Stable Features must have established integration and system
392 tests as required for Mature project Stable Features.
394 - The coverage provided by unit tests and integration tests should
395 be reported to sonar by M1. (See `instructions on reporting test
397 <https://wiki.opendaylight.org/view/CrossProject:HouseKeeping_Best_Practices_Group:Integration_Test>`__)
398 - Participating projects must describe a basic system test per
399 top-level feature and a comprehensive system test including
400 functionality, cluster, scalability, performance,
401 longevity/stability per stable feature prior on M2.
402 - Participating projects must run at least one basic automated
403 system test for each top-level feature and several automated
404 system tests including functionality, cluster, scalability,
405 performance, longevity/stability for each stable feature by M4.
409 The system test requirements can be waived by the TSC for a given
410 feature if for example the top-level feature is tested through another
414 Projects running system test outside OpenDaylight (external Lab) are
415 required to report system test results in a timely fashion after
416 release creations, e.g., weekly, RC, and formal releases.
418 - System tests are expected to reliably pass. If a system test turns
419 out to be unstable and intermittently fails, it must be fixed or
420 disabled. If intermittent system tests are seen as having value to
421 the project, they can be written and run on-demand by the project,
422 but won't be run as part of the automated CSIT suite.
423 - Further details and requirements can be found in the
424 `schedule`_ and `Oxygen project integration and test requirements
425 <https://wiki.opendaylight.org/view/Integration/Oxygen_Traditional_Release_Project_Integration_Requirements>`__
430 - Each participating project is expected to identify the kinds of
431 documentation that would be useful (e.g., installation guide, user
432 guide, developer guide) and provide them as part of the release.
433 - More details on the expectations can be found in the
434 `schedule`_ and `Oxygen project documentation requirements
435 <https://wiki.opendaylight.org/view/Documentation/Oxygen/Project_Documentation_Requirements>`__
440 - No uses of System.out.println in non-test code.
441 - No dependencies on 3rd party (non-ODL) snapshot versions
442 - Willing to use agreed-upon versions for dependencies (both
443 3rd-party and ODL), i.e., to eliminate version skew
444 - Willing to find source code for 3rd-party dependencies and/or move
445 to versions or alternatives for which source code can be found.
449 - All projects must support a Karaf-based distribution model
450 including defining Karaf features and adding them to integration
451 repository no later than M2.
452 - No later than M2, each project must have a “distribution-check"
453 Jenkins Job to verify changes in the code do not break integration
458 - All projects are expected to meet the deadlines laid out in the
461 - To indicate this, the project lead/contact is expected to
462 provide and send a milestone readout to the `release mailing
463 list <https://lists.opendaylight.org/mailman/listinfo/release>`__
464 by 23:59:59 UTC on the date listed for the the appropriate
465 offset at each milestone.
466 - Most information will be communicated by filling out
467 appropriate information in the `Oxygen Tracking
468 Spreadsheet <https://docs.google.com/spreadsheets/d/1dYOY99twqHV_Q0YorAOOxmL0aFc3icNXg8qA_zGwKyA/>`__,
469 but a mail should still be sent indicating that the information
470 has been filled in. Any other information or questions can be
471 included in that mail.
473 - If a project cannot make a deadline, the project lead/contact must
474 write a summary of what was missed, why, the course correction
475 that will be taken, and its impact on other projects.
477 - For **offset two** project this is mainly intended to be
478 reflective and to help inform the release process.
479 - For **offset zero** and **offset one** projects, this should be
480 completed within 24 hours of missing the deadline and must be
481 presented to the TSC at the first TSC meeting after the
484 - All Milestone deliverables will be verified by the Oxygen release
485 management staff and/or the TSC.
489 For deliverables defined only in the project's release plan—and not as
490 a requirement in this document—the release management staff and/or TSC
491 will verify that the status of the deliverables has been reported.
492 Oxygen release management staff and/or the TSC may also, but are not
493 required to, verify the delivered functionality.
497 {{:Integration/Oxygen_Traditional_Release_Project_Integration_Requirements}}
501 {{:Documentation/Oxygen/Project Documentation Requirements}}
503 Milestones, Release Candidates, and Service Releases
504 ====================================================
506 - Milestones are spaced roughly 4 weeks apart taking into account
507 significant holidays.
508 - Release Candidates (RC) are spaced roughly 1 week apart
509 - Service Releases are roughly 4, 12, 20, and 30 weeks after the Formal
510 Oxygen Release and are intended to continue at least until the after
511 the next formal release of the OpenDaylight, presumably Oxygen.
516 This Simultaneous Release plan has been drafted based on the `Schedule Framework
517 <https://wiki.opendaylight.org/view/Simultaneous_Release:Release_Schedule_Framework>`__
523 \ :sup:`2`\ The deadline to meet and report the results of each
524 milestone is at 23:59:59 UTC on the listed day. That corresponds to 4p
527 Official release template is: `Release Plan Template <https://wiki.opendaylight.org/view/Simultaneous_Release:Per-Project_Oxygen_Release_Plan_Template>`__
529 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
530 | Milestone | Offset 0 Date\ :sup:`2`\ | Offset 1 Date\ :sup:`2`\ | Offset 2 Date\ :sup:`2`\ | Events |
531 +========================================+========================================+========================================+========================================+====================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+
532 | M0 | 2017/9/7 | N/A | N/A | **Oxygen Simultaneous Release Open** |
534 | | | | | #. Contact Freeze |
536 | | | | | - Projects must have declared intent to participate in Simultaneous Release |
537 | | | | | - Projects must have elected their Project Leads and specify a Test Contact |
538 | | | | | - Participating Projects must have published a candidate Release Plan for public comment ( `Release Plan Template <https://wiki.opendaylight.org/view/Simultaneous_Release:Per-Project_Oxygen_Release_Plan_Template>`__ ) |
540 | | | | | - *Note: the date for M0 will normally be at least one day after the TSC approves the Oxygen release plan.* |
541 | | | | | - *Note that the release plan includes details about negotiating inter-project dependencies, expectations, and incompatibilities.* |
542 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
543 | Last call for project proposals | 2017/9/14 | 2017/9/21 | 2017/9/28 | #. This is the latest date a project proposal can be sent to the `project-proposals list <mailto:project-proposals@lists.opendaylight.org>`__ and still have the required two week public comment period before its project creation review at the last TSC meeting before the M1/M2/M3 milestone. Project proposals submitted after this date will not be able to become formal projects by M1/M2/M3 and thus will not be able to participate in the Oxygen release.\ :sup:`3`\ |
544 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
545 | M1 | 2017/10/7 | 2017/10/14 | 2017/10/21 | #. Participating Projects must have declared their final Release Plan with all sections fully completed. |
546 | | | | | #. Projects that need extra configuration or resources other than those available in the OpenDaylight CI infrastructure must have opened helpdesk tickets to add them. |
547 | | | | | #. `Project Checklist <https://wiki.opendaylight.org/view/GettingStarted:Project_Main#New_Project_Checklist>`__ completed (for *all* projects, not just new ones). |
548 | | | | | #. Projects may apply for a system test waiver if they think they have top-level features not requiring system test or covered by other top-level features test. |
549 | | | | | #. Projects must specify whether they plan to use OpenDaylight CI infrastructure for system test. It is recommended to use the OpenDaylight CI infrastructure unless there is some HW or SW resource that cannot be installed there. Projects running system test in external Labs are required to report system test results in a timely fashion after release creations, e.g., weekly, RC, and formal releases. |
550 | | | | | #. Project must get acknowledged from all projects that it depends on. |
551 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
552 | M2 | 2017/11/7 | 2017/11/14 | 2017/11/21 | #. Feature/Functionality Freeze |
554 | | | | | - Final list of externally consumable :ref:`APIs <api>` defined and documented |
556 | | | | | - Projects must state for each **TENTATIVE API** they have (if any) whether they are formally planning to deliver it. |
558 | | | | | - If so, it should be noted that it will be delivered. |
559 | | | | | - If not projects requesting the API must be informed so that they can take corrective actions. |
561 | | | | | - Externally consumable APIs are available at beta-quality |
563 | | | | | - All inter-project dependencies are resolved (all project functionality is declared as either “In” or “Out” of this release) |
565 | | | | | #. Karaf Features defined |
567 | | | | | - Instructions can be found in the `Karaf:Step by Step Guide <http://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide>`__ |
569 | | | | | - Each feature should be tested in every appropriate jenkins job (at least -verify, -merge, and -integration) using the “SingleFeatureTest” as defined in the `Karaf step-by-step guide <http://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide>`__ |
571 | | | | | - Any feature repositories containing features intended for release must be added to the main features.xml file in the integration git repository as explained in the `Karaf step-by-step guide <http://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide>`__ |
573 | | | | | - Projects must have a distribution job to verify changes in code do not impact the integration distribution (this will be automatically setup by the releng/builder group). |
575 | | | | | - Features that are intended to be “top-level”, “user-facing” and/or “stable” must be called out in the milestone readout. These features will have additional requirements: |
577 | | | | | - Each “top-level” feature must have a developer guide section (See the `Oxygen Project Documentation Requirements <https://wiki.opendaylight.org/view/Documentation/Oxygen/Project_Documentation_Requirements>`__) and a system test (See the `Integration and Test Requirements <https://wiki.opendaylight.org/view/Integration/Oxygen_Traditional_Release_Project_Integration_Requirements>`__). |
578 | | | | | - Each “user-facing” feature must have a user guide section (See the `Oxygen Project Documentation Requirements <https://wiki.opendaylight.org/view/Documentation/Oxygen/Project_Documentation_Requirements>`__) |
579 | | | | | - Each “stable” feature must meet the requirements explained in the `definitions`_ above. above. |
581 | | | | | - Changing the name of a Karaf feature or removing a Karaf feature should be handled via an API freeze waiver after this point |
583 | | | | | #. Documentation Started |
585 | | | | | - Identified the kinds of documentation to be provided, created reStructuredText files for them with outlines, and committed those files in an appropriate location. (See the `Oxygen Project Documentation Requirements <http://wiki.opendaylight.org/view/Documentation/Oxygen/Project_Documentation_Requirements>`__ for more details.) |
587 | | | | | #. Feature Test Started |
589 | | | | | - Instructions can be found in the `System Test Step by Step Guide <https://wiki.opendaylight.org/view/CrossProject:Integration_Group:System_Test:Step_by_Step_Guide>`__. |
590 | | | | | - Projects must have filled out a basic `system test plan template <https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Feature_Integration_System_Test_Template>`__ for each top-level feature (karaf and not karaf). Stable features have `additional requirements <https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Feature_Integration_System_Test_Template#Additional_Requirements_To_Meet_Test_Requirements_Of_A_Stable_Feature>`__ for functionality, cluster, scalability, performance, longevity/stability. |
591 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
592 | M3 | 2017/12/7 | 2017/12/14 | 2017/12/21 | #. API Freeze: See more information in the `definitions`_ above. |
593 | | | | | #. Documentation: |
595 | | | | | - Project readouts MUST include a word count of each relevant .adoc file with a goal of draft documentation done. |
597 | | | | | #. Projects are encouraged to meet the `requirements to be included in maven central <http://central.sonatype.org/pages/requirements.html>`__ |
599 | | | | | - Project readout MUST include whether or not this was accomplished |
601 | | | | | #. Feature Test Continues |
603 | | | | | - Participating projects Projects must have all extra SW configuration and resources required for system test installed in the OpenDaylight CI\ :sup:`4`\. More information in `How To Install SW in CI <https://wiki.opendaylight.org/view/CrossProject:Integration_Group:How_To_Install_test_SW>`__. |
604 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
605 | M4 | 2018/1/7 | 2018/1/14 | 2018/1/21 | #. Code Freeze (bug fixes only from here as defined above) |
606 | | | | | #. Stability branch, i.e., stable/oxygen, must be cut and local project versions bumped on master to avoid overwriting Oxygen SNAPSHOTS |
608 | | | | | - Follow steps 1–4 from the instructions on `cutting stability branches <https://wiki.opendaylight.org/view/Simultaneous_Release:Cutting_Stability_Branches>`__ |
609 | | | | | - *Note:* Branch cutting will occur sometime between offset 0 M4 and offset 2 M4 and may be either staggered by offsets or done all at once. `See TSC meeting minutes from 7/9/2015 item 5.ac <https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-07-09-17.00.html>`__. |
611 | | | | | #. String Freeze (all externally visible strings frozen to allow for translation & documentation) |
612 | | | | | #. Documentation Complete: Only editing and and enhancing should take place after this point. |
613 | | | | | #. Feature Test Complete |
615 | | | | | - Stable features should fulfill quality requirements listed in `definitions`_ section |
616 | | | | | - Projects must run at least one basic automated system test job for each top-level feature and several automated system test jobs including functionality, cluster, scalability, performance, longevity/stability for each stable feature\ :sup:`4` \. |
617 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
618 | RC0 | 2018/2/7 | N/A | N/A | #. The build for RC0 will start at 23:59:59 UTC |
620 | | | | | - At the start of the build for RC0, all projects must be in the distribution and autorelease. |
622 | | | | | - Between M4 for offset 2 projects and RC0 is a two week period for projects to finish adding to Oxygen Integration Distribution and Oxygen Autorelease and for projects to fix any errors in the Oxygen Autorelease Jenkins Build Job. At the beginning of this two week period, projects are given two week notice of potential drop. Projects that have not been successfully added to the Integration Distribution and Autorelease are dropped from the release. At the end of this two week period, we release RC0 for projects to begin their initial testing. At this time, all projects participating in the release must be in the distribution and autorelease. |
624 | | | | | #. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues |
625 | | | | | #. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet |
626 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
627 | RC1 | 2018/2/14 | N/A | N/A | #. The build for RC1 will start at 23:59:59 UTC |
629 | | | | | - At the start of the build for RC1, all stable/oxygen branches will be locked and only release engineering staff will be able to merge patches. |
631 | | | | | #. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues |
632 | | | | | #. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet |
633 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
634 | RC2 | 2018/2/21 | N/A | N/A | #. The build for RC2 will start at 23:59:59 UTC |
636 | | | | | - At the start of the build for RC2, the release engineering staff will only merge patches that fix blocking bugs. All stable/oxygen branches will remain locked and only release engineering staff will be able to merge patches and will only do so for patches that fix blocking bugs. |
638 | | | | | #. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues |
639 | | | | | #. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet |
640 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
641 | RC3 | 2018/2/28 | N/A | N/A | #. Participating Projects must hold their Release Reviews, including User Facing Documentation. |
643 | | | | | - The release review should be based on the `Sample Release Review <https://wiki.opendaylight.org/view/Sample_Release_Review>`__ and should point to release notes based on `Sample Release Notes <https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/sample-release-notes.rst>`__. |
645 | | | | | #. The build for RC3 will start at 23:59:59 UTC |
646 | | | | | #. All stable/oxygen branches will remain locked and only release engineering staff will be able to merge patches and will only do so for patches that fix blocking bugs. |
647 | | | | | #. During the RC process, regular, e.g., daily, IRC meetings may take place to identify and address issues |
648 | | | | | #. During the RC process, blocking bugs will be tracked in bugzilla and a common spreadsheet |
649 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
650 | Formal Oxygen Release | 2018/3/7 | N/A | N/A | #. Formal Oxygen Release |
652 | | | | | - *NOTE: The build to produce the formal release artifacts is likely to occur before the formal release date.* |
654 | | | | | #. After the release, except for projects that have opted-out, the release engineering staff will apply the release patch to the stable/oxygen branch and bump versions. |
656 | | | | | - *Note:* Any patches merged to stable/oxygen after the auto-release build that produces the formal release artifacts, but before the release patch and version bumps are applied will have to be reverted and re-applied after the release and version bump patches. This shouldn't happen in Oxygen as the stable/oxygen branches will have been locked since RC1. |
657 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
658 | SR1 (Service Release 1 aka Oxygen.1) | 2018/4/7 | N/A | N/A | #. First Service Release for Oxygen. 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. |
660 | | | | | - 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. |
661 | | | | | - Blocking bugs will be tracked via bugzilla and a spreadsheet. |
663 | | | | | #. After the release, projects MUST apply the release patch to the stable/oxygen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release. |
665 | | | | | - *Note:* Any patches merged to stable/oxygen after the auto-release build that produces the formal release artifacts, but before the release patch and version bumps are applied will have to be reverted and re-applied after the release and version bump patches. |
666 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
667 | SR2 (Service Release 2 aka Oxygen.2) | 2018/6/7 | N/A | N/A | #. Second Service Release for Oxygen. 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. |
669 | | | | | - 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. |
670 | | | | | - Blocking bugs will be tracked via bugzilla and a spreadsheet. |
672 | | | | | #. After the release, projects MUST apply the release patch to the stable/oxygen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release. |
674 | | | | | - *Note:* Any patches merged to stable/oxygen after the auto-release build that produces the formal release artifacts, but before the release patch and version bumps are applied will have to be reverted and re-applied after the release and version bump patches. |
675 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
676 | SR3 (Service Release 3 aka Oxygen.3) | 2018/8/7 | N/A | N/A | #. Third Service Release for Oxygen. 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. |
678 | | | | | - 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. |
679 | | | | | - Blocking bugs will be tracked via bugzilla and a spreadsheet. |
681 | | | | | #. After the release, projects MUST apply the release patch to the stable/oxygen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release. |
683 | | | | | - *Note:* Any patches merged to stable/oxygen after the auto-release build that produces the formal release artifacts, but before the release patch and version bumps are applied will have to be reverted and re-applied after the release and version bump patches. |
684 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
685 | SR4 (Service Release 4 aka Oxygen.4) | 2018/9/21 - 2018/11/7 | N/A | N/A | #. Fourth Service Release for Oxygen. 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. |
687 | | | | | - 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. |
688 | | | | | - Blocking bugs will be tracked via bugzilla and a spreadsheet. |
690 | | | | | #. After the release, projects MUST apply the release patch to the stable/oxygen branch and bump versions. Unless a project opts out, this will be done automatically by the release team after the release. |
692 | | | | | - *Note:* Any patches merged to stable/oxygen after the auto-release build that produces the formal release artifacts, but before the release patch and version bumps are applied will have to be reverted and re-applied after the release and version bump patches. |
693 +----------------------------------------+----------------------------------------+----------------------------------------+----------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
695 \ :sup:`3`\ Please note that the TSC reserves the right to allow
696 projects to enter the Simultaneous Release for a reasonable period of
697 time after the M0 date. For example, the TSC may allow additional time
698 if a project is delayed by the IPR Review process.
700 \ :sup:`4`\ Projects running system tests outside the OpenDaylight CI
701 infrastructure are not required to run system tests and report the
702 results on “-merge” and “-integration” Jenkins jobs, although if they
703 can this is ideal. They are required to report system test results in a
704 timely fashion after release creations, e.g., weekly, RC, and formal
707 Please also note that projects that would like to spin out parts of
708 themselves into additional projects may have those new projects join the
709 Simultaneous Release at any point prior to M3 provided:
711 #. The TSC has been informed of this intent prior to M2
712 #. The original project's release Release Plan is apportioned between
713 the original and new projects with no parts missing
714 #. The new projects have been proposed and approved by the TSC into one
715 of the non-proposed life-cycle states in the normal manner by M2
716 #. The new projects have completed the requirements for all milestones
717 before they joined the release, e.g., M0 and/or M1
719 Lastly, note that as the new projects are joining the release prior to
720 M2, they must meet all the requirements for M2 at the normal time.
722 Participating Projects
723 ======================
725 The list of participating projects can be found on the `Oxygen Tracking
726 Spreadsheet <https://docs.google.com/spreadsheets/d/1dYOY99twqHV_Q0YorAOOxmL0aFc3icNXg8qA_zGwKyA/>`__
731 Project table with release plan, main page, and PTL/Project/Test/Doc
732 contact information can be found on the `Oxygen Tracking
733 Spreadsheet <https://docs.google.com/spreadsheets/d/1dYOY99twqHV_Q0YorAOOxmL0aFc3icNXg8qA_zGwKyA/>`__
738 Project table with release plan, main page, and PTL/Project/Test/Doc
739 contact information can be found on the `Oxygen Tracking
740 Spreadsheet <https://docs.google.com/spreadsheets/d/1dYOY99twqHV_Q0YorAOOxmL0aFc3icNXg8qA_zGwKyA/>`__
745 Project table with release plan, main page, and PTL/Project/Test/Doc
746 contact information can be found on the `Oxygen Tracking
747 Spreadsheet <https://docs.google.com/spreadsheets/d/1dYOY99twqHV_Q0YorAOOxmL0aFc3icNXg8qA_zGwKyA/>`__
752 The status of projects is being tracked on the `Oxygen Tracking
753 Spreadsheet <https://docs.google.com/spreadsheets/d/1dYOY99twqHV_Q0YorAOOxmL0aFc3icNXg8qA_zGwKyA/>`__
758 See sections below for RC0, RC1, RC2, etc.
780 Service Release Download
781 ========================
808 Project Dependency Diagram
809 ==========================
813 .. _communication-channels:
815 Communication Channels
816 ======================
822 list <https://lists.opendaylight.org/mailman/listinfo/release>`__
823 (release@lists.opendaylight.org) is the formal channel for communication
824 about the Simultaneous Release.
826 Please limit mail to this list to things that directly concern the
827 release as our goal is to keep its volume at a level that allows the
828 project lead/contact to read all of it.
830 Per-project Simultaneous Release Contact
831 ----------------------------------------
833 Each project participating in the Simultaneous Release should designate
834 a committer to be the contact for that project for that Simultaneous
835 Release. It is expected that this be the project lead for most projects.
836 Even though a primary contact other than the project lead can be
837 designated, the project lead is still expected to be ultimately
838 responsible for the project's participation in the release.
840 Cross Project Milestone and Release Candidate Reporting
841 -------------------------------------------------------
843 At each milestone, each project is expected to send a readout to the
845 list <https://lists.opendaylight.org/mailman/listinfo/release>`__ by
846 23:59:59 UTC on the date listed for the given milestone and offset. Most
847 information will be reported via the release tracking spreadsheet, which
848 can be found in the `supporting documents`_
849 section. While most information will be reported via the spreadsheet,
850 projects should still send a mail indicating the information has been
851 filled in, reporting any extra information, and possibly asking
852 additional questions. Reported information will include things like
853 links to gerrit patches, pointers to continuous integration Jenkins
856 Negative statuses should be reported promptly. If a project is under
857 threat of, or does miss an element on its release plan, the project
858 contact/lead should report this as soon as it is known. They should not
859 wait until the next milestone's readout.
861 It is the responsibility of each project's lead to report both positive
862 and negative statuses. While they can delegate the task, the project
863 lead is still ultimately responsible for the project's participation in
866 Simultaneous Release Developer Meetings
867 ---------------------------------------
869 One week prior to each Milestone or Release Candidate starting at M1, an
870 IRC meeting for developer interested in the Simultaneous Release will be
871 organized for real time coordination and check in. The Project for each
872 project (or their delegate) should minimally be in attendance. This
873 meeting should happen for each offset at each milestone.
875 The meeting will be held in #opendaylight-meeting on
876 `freenode <https://freenode.net/>`__. You can use an IRC client of your
877 choice or the `freenode web client
878 <https://webchat.freenode.net/?url=irc://irc.freenode.net/opendaylight-meeting>`__
884 `Bugzilla <https://bugs.opendaylight.org/>`__ is used to track all bugs
885 in OpenDaylight. Bugs must be filed for the appropriate project. General
886 guidelines and sample searches can be found on the `OpenDaylight
887 Bugs <https://wiki.opendaylight.org/view/OpenDaylight_Bugs>`__ page.
889 During the release candidate process, all blocking bugs must be both
890 logged on a bug-tracking spreadsheet (to be provided) and filed
891 appropriately, e.g., with severity set to BLOCKING, in Bugzilla.
896 To track current ongoing issues and upcoming possible issues, it's worth
897 checking and updating the `Weather <https://wiki.opendaylight.org/view/Weather>`__ page since it provides
898 an easier to find location for ongoing things than the mailing list.
900 Cross Project Meetings
901 ----------------------
903 To track cross project items.
908 OpenDaylight will have 3 active releases: 2 in production and 1 in
909 development. Exceptions to this EOL plan will be discussed and approved
910 by TSC. Oxygen, being the 8th release, will officially EOL when we
911 publish the 11th release - Sodium.
917 Spreadsheet <https://docs.google.com/spreadsheets/d/1dYOY99twqHV_Q0YorAOOxmL0aFc3icNXg8qA_zGwKyA/>`__
918 - `Per-project Release Plan
919 Template <https://wiki.opendaylight.org/view/Simultaneous_Release:Per-Project_Oxygen_Release_Plan_Template>`__
920 - `API Freeze Exception
921 Process <https://wiki.opendaylight.org/view/Simultaneous_Release/Oxygen/Waiver/API>`__
924 Records <https://wiki.opendaylight.org/view/Simultaneous_Release/Oxygen/Waiver/API/Records>`__
927 Checklist <https://wiki.opendaylight.org/view/GettingStarted:Project_Main#New_Project_Checklist>`__
928 - `Oxygen Project Integration
929 Requirements <https://wiki.opendaylight.org/view/Integration/Oxygen_Traditional_Release_Project_Integration_Requirements>`__
930 - `Oxygen Project Documentation
931 Requirements <https://wiki.opendaylight.org/view/Documentation/Oxygen/Project_Documentation_Requirements>`__
932 - `Living Release Schedule
933 Framework <https://wiki.opendaylight.org/view/Simultaneous_Release:Release_Schedule_Framework>`__
934 - `Bug Tracking Guidelines <https://wiki.opendaylight.org/view/OpenDaylight_Bugs>`__
935 - `Karaf Step by Step Guide <https://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide>`__
936 - `Cutting Stability Branches and Bumping
937 Versions <https://wiki.opendaylight.org/view/Simultaneous_Release:Cutting_Stability_Branches>`__
939 Requirements <http://central.sonatype.org/pages/requirements.html>`__
941 Notes <https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/sample-release-notes.rst>`__
942 - `Sample Release Review <https://wiki.opendaylight.org/view/Sample_Release_Review>`__
944 Template <https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Feature_Integration_System_Test_Template>`__
946 .. _milestone-readout-templates:
948 Milestone Readout Templates
949 ===========================
951 Note that any deliverable missed in a previous milestone should be
952 reported on in all subsequent milestone readouts until the deliverable
953 is completed. Also note that additional questions may be added if we
954 need to gather it from all projects, e.g., in Lithium we asked about
955 issues with the migration to Karaf 3.0.3.
961 .. literalinclude:: milestone-readouts/m0_template.rst
963 M1: Final Release Plan
964 ----------------------
966 .. literalinclude:: milestone-readouts/m1_template.rst
968 M2: Functionality Freeze
969 ------------------------
971 .. literalinclude:: milestone-readouts/m2_template.rst
976 .. literalinclude:: milestone-readouts/m3_template.rst
981 .. literalinclude:: milestone-readouts/m4_template.rst
983 RCX: Release Candidate Testing
984 ------------------------------
988 #. Have you tested your code in the release candidate? *Yes/No (provide
989 a link to the release candidate you tested)*
991 - If yes, did you find any issues?
992 - If you have found issues, do you believe any of them should block
993 this release of OpenDaylight until they are resolved?
994 - Please list all the issues and note if they are blocking.
999 During the Oxygen release
1000 -------------------------
1004 During the Nitrogen release
1005 ---------------------------
1009 During the Carbon release
1010 -------------------------
1012 - Clustering breakage, see 6.b-d in the `3/24/17 TSC meeting
1013 minutes <https://meetings.opendaylight.org/opendaylight-meeting/2017/tsc/opendaylight-meeting-tsc.2017-03-24-03.30.html>`__
1015 - Need more details and to figure out if there are lesson's learned
1016 beyond “it took 2 days to get a response and it hurt our jenkins
1019 - An accelerated release plan helps new projects, as they often need
1020 more time to ramp up on technology, process, and setup. Recommend
1021 that the simultaneous release plan be approved earlier than M0
1024 During the Beryllium release
1025 ----------------------------
1027 - \ `Do we need enhanced requirements to be in a release and when to
1029 them? <https://lists.opendaylight.org/pipermail/release/2015-November/004419.html>`__\
1030 **I don't think that we really need new requirements as much as we
1031 should probably start to more rigorously enforce the ones we
1032 have—predominantly around projects being responsive.**
1033 - If you're planning to develop major new functionality or replace the
1034 implementation of major current functionality, be cognizant of your
1035 downstream consumers
1037 - have a migration plan for how people will start using the new
1038 functionality (or implementation)
1039 - understand how to help them deal with bugs as they come up
1040 - if you will have two different simultaneous implementations, make
1041 they can both be run at the same time
1043 - or ideally, don't do this, make sure everyone can make the jump
1044 to the new implementation
1046 - upgradability is critical, there's no sane way to do this without
1048 #. a per-project requirement to be upgradable **This is already baked
1049 into the concept of stable features, which are probably the right
1050 lever for this now.**
1051 #. tests to confirm that this actually works
1053 - there have been requests to have upgrades work with hops between
1054 versions, e.g., Helium => Boron
1055 - we need stronger testing for upgradeablity between SRs
1056 - projects should have only stable tests, if we need to ask them about
1057 test failures consistently, they need to:
1060 - have a well known and clearly visible (in the test automation) bug
1062 - remove it **Added an extra bullet to testing requirements noting that
1063 system tests are expected to reliably pass.**
1065 - projects should be required to generate a maven site with javadoc,
1066 and ideally REST API doc generated from YANG models
1068 - ideally this should be done in a way that autorelease can generate
1069 one big maven site **added as a documentation requirement at M4 with
1072 - projects don't do system test even when they say they do
1074 - **possibly mandate that projects w/o system test be
1075 experimental** <https://lists.opendaylight.org/pipermail/tsc/2016-February/004648.html>
1077 - System Test is not very visible
1078 - We need to update release reviews and release notes to make us have
1079 to ask fewer questions
1081 - features (with links to the features.xml file and the right line
1082 for each feature to avoid listing non-existent features)
1084 - if there are any experimental features
1085 - user-facing features (with a clear definition of user-facing)
1088 - compatibility (which is different from migration)
1089 - documentation (both wiki and AsciiDoc)
1090 - Ideally also add the wiki template to produce lists of release
1091 notes, release plans, and release reviews
1093 - It would be good to have `documentation peer-review in a structured
1094 way <https://lists.opendaylight.org/pipermail/release/2016-February/005708.html>`__
1096 - Maybe pairing up projects (or even forming small groups, e.g., 3
1097 projects that have to do cross-review) **Added to the documentation
1098 requirements that the documentation team will ask for projects to
1099 do peer review and preferentially review and merge patches that
1100 have been peer reviewed.**
1102 - We need to start testing earlier, the observation seems to be that we
1103 don't start testing in earnest until RC0 (or sometimes RC1), which
1104 leaves 2-3 weeks for testing and fixing bugs.
1106 - How to do this isn't exactly clear. Some people call for having a
1107 longer RC time-frame. Others just say that we should be stricter
1108 and more disciplined with hitting functionality freeze (M3) and
1111 - We need more formalism around how to ship things that aren't Karaf
1112 features, e.g., NeXt, OpFlex and some of VTN
1114 - It seems like learning from VTN which is distributed inside the
1115 Karaf zip file might be a good thing
1116 - If not, we need to understand where the extra downloads will be
1117 listed on the downlaod page, how many there will be, etc.
1119 - We need minimum expectations for projects to be in and stay in
1120 autorelease (and thus be part of the release), e.g.,
1122 - respond to failed builds in a timely fashion. **This is already in
1123 the** :ref:`reqs-for-participation`, **we can just start enforcing it
1126 - Should we require projects to meet the minimum requirements for
1127 inclusion in maven central?
1130 - for stable features?
1132 During the Hydrogen, Helium and Lithium releases
1133 ------------------------------------------------
1135 A comment will follow as
1136 to how it was addressed in **bold** if it seems like the right approach and
1137 in *italics* if there may still be debate or questions.
1139 - Do we want to require system tests for all top-level features (and
1140 thus one per project) instead of just user-facing features? **done,
1141 it's for top-level features**
1142 - The release notes and release review templates need to be revised
1144 - Likely combined and to use a wiki template to make them more
1145 uniform and easier to suck out **For now, the release notes have
1146 been updated to be more clearly per-project. The release review
1147 template is specified by the lifecycle document and so has been left
1148 the same and separate.**
1150 - We need to track items that weren't green from previous milestone
1151 readouts so that they get reported in subsequent ones until they are
1154 - A key example is getting features into integration
1156 - We need to require project feedback on RCs as part of the release
1158 - Service releases should likely continue until some future release
1159 (either one or two releases in the future) rather than after a fixed
1160 number of releases. **we've moved to four SRs with the note that the
1161 should go for at least one release in the future**
1163 - How long after the new release do we wait?
1164 - Do we want to have a specified amount of overlap? 2 weeks? 6
1167 - We desperately need pre-made templates for each milestone that make
1168 verifying requirements easy. We just missed things in Lithium M1 to
1170 - We need to mandate source jars generated in a canonical way, i.e., to
1171 be consumed by releng/autorelease.
1172 - We should also mandate javadoc generated in a canonical way, i.e., to
1173 be consumed by releng/autorelease. **Thanh says releng is already doing
1174 this both in JJB for projects and auto-release.**
1175 - We need to mandate that no projects can pull in 3rd-party
1176 dependencies without source jars.
1177 - Migration **migration and backward compatibility requirements have been
1178 put out as part of mature projects and/or stable features,** *but could
1179 maybe use to be made more concrete*
1181 - Do we want to require data schema translations?
1184 - The paperwork for M3 was substantial (and not easy see in advance)
1185 and should be streamlined or spread out **to dos have been added above
1186 to copy documentation and integration requirements into this document
1187 to keep them from sneaking up on people**
1189 - Consolidating all the requirements into one place would likely
1192 - We should make sure that people know where to produce and document
1193 known issues. In general, it's three places:
1195 - The release mailing list.
1196 - The `Weather <https://wiki.opendaylight.org/view/Weather>`__ page.
1197 - The weekly IRC sync during the last part of the release. **This is
1198 called out in** :ref:`communication-channels` **and any more forceful call
1199 out will likely have to happen not in this document**.
1201 - Make it clear what is expected of projects in terms of tracking
1202 what's going on in ODL.
1204 - Reading the release list.
1205 - Reading tsc list or at least the TSC meeting minutes.
1206 - Attending release IRC meetings or at least reading the minutes.
1207 **This is called out in the Communication & Leadership requirement
1208 above and that is pointed out in the M1 milestone readout template**
1210 - Adding a way to deal with docs-like projects that don't provide
1211 code-level negative interactions
1213 - This includes at least docs, toolkit (now mostly defunct), and
1215 - Ideally, they might have laxer requirements **for now, I think
1216 leaving these projects as leaf projects with minimal requirements
1219 - Deal with cutting branches and version bumps with offsets *TODO: for
1220 now we've left the exact timing of branch cutting open to sometime
1221 between offset 0 M5 and offset 2 M5 as well as leaving open whether
1222 we'll do a synchronized cut or a cut staggered by offset.*
1224 - If we cut branches and version bump at the same time, the only
1225 issue we have is slow projects that can hold things up, which has
1226 been fixed by automated version bumping that should happen for
1228 - However, if we cut branches and version bump at M5, there is an
1229 offset between different projects where upstream projects can
1230 merge patches that break downstream projects (regardless of
1231 whether the breakage is a bug in the upstream or downstream
1232 project) causing the version bump for downstream projects to fail.
1233 - The options seem to be:
1235 #. cut branches all at the same time at or near M5-offset2 or RC0,
1236 which has the disadvantage that offset 0 and offset 1 projects
1237 have somewhere between a 2-week and 6-week period after code
1238 freeze where they can't add new features.
1239 #. cut branches all at the same time at M5-offset0, which has the
1240 disadvantage that offset 1 and offset 2 projects will have to
1241 “double merge” patches to both branches during times that would
1242 normally have heavy coding.
1243 #. figure out how to deal with the issue that offset 1 and offset
1244 2 projects may get hit with incompatibilities on version bumps
1246 - Also, cascading tests during staggered branch cutting breaks
1247 because the way JJB is set up right now it's not possible to
1248 trigger jobs across branches even when logically master of an
1249 offset 1 project is dependent on stable/lithium of an offset 0
1254 - We'd really like to be able to put project-specific docs in their
1257 - This will allow us to easier iterate on docs as patches go in,
1258 and allow committers to +2/-2 doc changes. (alagalah)
1259 - This should include the ability to directly pull code fragments
1262 - We'd really like HTML versions of the docs that aren't so
1263 fragmented **This will be folded in to the docs project's
1266 During the Hydrogen/Helium releases
1267 -----------------------------------
1269 A comment will follow as to how it was addressed in **bold** if it seems like
1270 the right approach and in *italics* if there may still be debate or questions.
1272 - The Release plan doesn't take into account project dependencies. e.g.
1273 M4 API Freeze. If a project is waiting on API freeze for a project it
1274 is dependent on, then that reduces the amount of time the “dependee”
1275 has to execute. - alagalah (Keith) **Done, mainly by moving deadlines
1276 up by one step, e.g., M2 component free, M3 API freeze, M4 code
1279 - We had offsets in Hydrogen, spaced at 2 days. We need 2-3 weeks
1280 between offsets for them to make sense,
1281 - With 6 offsets 2 weeks each we need additional 10 weeks to reach
1282 RC0 on all projects,
1284 - *Can we can do it in 3 offsets: +0, +2 weeks, +4 weeks*
1286 #. odlparent, yangtools, and controller
1287 #. openflowjava, openflowplugin, ovsdb, aaa
1290 - Which means lower-offset projects can (and need) to start their
1291 next-release while the SR process is finishing
1293 - We need a Feature Freeze milestone before the API freeze
1295 - It should occur at M3 with beta-quality APIs, so downstream
1296 projects can start consuming *Currently at M2 instead, it will be
1297 ~M2.5 and ~M3 for most projects*
1299 - We're using release@lists.opendaylight.org instead of discuss
1300 - We should make it easy for projects to convey and understand what
1301 APIs they are intending to make available vs. which ones are intended
1302 to be internal *attempted as part of component/API freeze*
1303 - We should make it clear that participation in Service Releases is not
1304 optional **done**, see :ref:`reqs-for-participation`.
1305 - We should make it clear what we expect in terms of timely responses
1306 from project primary contacts for a release **done**, see
1307 :ref:`reqs-for-participation`.
1309 - This involves identifying what mails that people should pay
1310 attention to, e.g., ones sent to release@lists.opendaylight.org
1311 with “PLEASE RESPOND” in the subject
1312 - It also involves identifying a time frame in which they should
1313 respond, e.g., two business days
1315 - One concrete stab at making this formal would be: “Technically,
1316 two business days will be defined as 48 hours not counting 2a
1317 UTC on Friday until 2a UTC on Sunday. This corresponds to 48
1318 hours starting at 4p on Friday in the furthest ahead time zone
1319 (UTC+14). Note that this means if you want a response \*this\*
1320 week, you must send it before 2a UTC on Wednesday. That’s 6/7p
1321 pacific time on Tuesday in the Pacific time zone.” *The formal
1322 definition is currently left out*
1324 - We need a longer time between code freeze and release candidates
1325 because developers don't focus on tests (especially system and
1326 integration tests) until after code freeze
1327 - Status reports for each milestone should include more than a Boolean
1330 - In general, the templates for status reports should probably be
1331 developed more in advance. See :ref:`milestone-readout-templates`.
1333 - We need to make it clear what tasks need to be done for docs, where
1334 and when **handled by the deliverable from M2 from docs**
1336 - Understanding the kinds of documentation we want to generate and
1337 who the audience is for each kind is going to be critical
1339 - \ *e.g., one person's user is likely another's developer*\
1341 - The same is true about tests. **handled by the deliverable from M2
1344 - We really need somebody who groks the things that need to be
1345 accomplished at each milestone and can take a glance at the code and
1346 jenkins jobs for each project to get an idea of whether they're on
1347 track or not. We need to make sure we do this for deadlines M3 and
1348 later, e.g., functionality freeze, karaf features defined, API
1349 freeze, and code freeze **milestone readout templates make this more
1351 - Requirements to meet at different stages (and especially RCs) should
1352 be set and enforced with clearly explained consequences for missing
1353 them **ways to fix missed deadlines are now discussed by the TSC for
1354 offset zero and offset one projects as described in**
1355 :ref:`reqs-for-participation`.
1357 - Release throttle branch needs to be cut at RC0 at the latest **done
1360 - We need a standard way to track blocking issues: *TODO: we still need
1361 this, but it's loosely defined in the* `Helium blocking bugs
1362 section <https://wiki.opendaylight.org/view/OpenDaylight_Bugs#Helium_Blocking_Bugs_.28all_projects.29>`__.
1364 - One suggestion is to treat them as bugs in bugzilla for easy
1365 tracking and querying
1367 - Projects would file bugs with severity as “critical”, “blocker”
1368 with the target milestone being appropriate
1369 - Appropriate milestones are sometimes annoying, but generally,
1370 it should be “anything but the next release”
1372 - We need to pre-declare when RCs and final release artifacts will be
1373 cut (both dates and times for clarity) **done at M5 and RCs**
1374 - Need to add an EOL-plans section to release plan to understand user
1375 impact of EOLed features/components/APIs at the start of a
1376 development cycle **done in release plan**
1378 - What requirements do we want to place on projects? e.g.,
1379 deprecated in one release and can remove in another?
1380 - plans for dealing with EOLed features should be incorporated into
1383 - We should reconsider when we set a release date **done, there is a
1384 month of slack between the release and the ODL summit and the dates
1385 for RCs after RC0 and the formal release are stated to be tentative
1386 based on testing in the definition of RCs**
1388 - Especially to the press, but also in other environments
1389 - For example, do we want to have a booked event giving us
1390 effectively zero wiggle room on the back end?
1392 - Maybe, because hard deadlines help get things done, but they
1393 also make for sub-optimal
1395 - We could use more automated release processes
1397 - For example, the auto-release is really, really nice as compared
1398 to spending 14+ hours on IRC cutting everything.
1399 - A similar process for post-release branch cutting and version
1400 bumping would be very helpful, e.g., take a 10+ day process and
1401 turn it into one that takes a few hours.
1402 - One problem is figuring out how to do this w/o requiring
1403 involvement from every project (at least on the critical path).
1405 - Solutions are (i) allowing for some scripts to commit changes
1406 to projects, which is likely bad, or (ii) automatically pushing
1407 patches for projects to review
1408 - Another solution is to switch to continuous delivery **resolved
1409 thanks to Thanh and the autorelease project**
1411 - We should avoid scheduling any major events, e.g., a design forum or
1412 summit, immediately after the release so that we can have some room
1413 for slippage without having to pull many developers out of the event
1414 into a “war” room. **done. there is a month between the release and the
1416 - More automated features testing *TODO: yes, but this is technical
1417 debt, not directly related to the release plan*
1419 - to really test things, we need to blow away the m2 repo before
1420 testing every features.xml file
1422 - Cyclic dependencies *TODO: yes, but this is technical debt, not
1423 directly related to the release plan*
1425 - We need to decide if we want to allow them, and if so what kind to
1427 - We need to provide documentation (or ideally scripts) that show
1428 how to build the code despite the circular dependencies (if we
1430 - We need tests to check for circular dependencies (either at all or
1431 new ones) so that we know about them
1433 - The simplest way to do this would be to have an offline
1434 auto-release which first clone all the repos and then tried to
1435 build them linearly without access to the nexus repos.
Code Review / docs.git / blob