7 This was an intentionally a verbatim copy of sections from the `Project
8 Lifecycle & Releases Document
9 <http://www.opendaylight.org/project-lifecycle-releases#MatureReleaseProcess>`_
10 which has the following to say about the Release Review Document:
12 *Both the Release Plan and Release review document are intended to be
13 relatively short, simple, posted publicly on the wiki documents to assist
14 projects in coordinating among themselves, and the general world in gaining
17 Insofar as this has been changed, it has kept with in that spirit folding in
18 our experience conducting release reviews.
22 When copying, please remove this entire "About this Document" section and
23 simply fill out the next sections.
27 Please do not remove any sections. Also, short sentences are better than
28 "n/a" or "none" as it is often confusing as to whether that means there are
29 no issues or you simply didn't think about or address anything.
38 For each top-level feature, identify the name, url, description, etc.
39 User-facing features are used directly by end users. Remove this paragraph.
44 * **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sample.git;a=blob;f=features/src/main/features/features.xml
45 * **Feature Description:** This is a sample feature that performs various
46 sample tasks and provides the implementation of RFC 0000.
48 * **User Facing:** Yes
49 * **Experimental:** Yes
50 * **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sample/job/sample-csit-1node-feature-all-carbon/
55 .. Please provide the URL to each document at docs.opendaylight.org. If the
56 .. document is under review, provide a link to the change in Gerrit.
58 * **Installation Guide(s):**
62 .. note: for most projects this should not be needed since it should just
63 be ``feature:install <feature-name>``.
67 * Link to Guide. Should be formatted something like::
69 :ref:`Guide name <guide-label-name>`
71 Where the <guide-label-name> is something like::
79 As described in `Cross-referencing arbitrary locations
80 <http://www.sphinx-doc.org/en/stable/markup/inline.html#cross-referencing-arbitrary-locations>`_.
82 * **Developer Guide(s):**
84 * Link to Guide. Use same format as above.
86 Security Considerations
87 =======================
89 * Do you have any external interfaces other than RESTCONF?
91 * If so, how are they secure?
92 * What port numbers do they use?
94 * Other security issues?
99 * `Link to Sonar Report <URL>`_ (Test coverage percent)
100 * `Link to CSIT Jobs <URL>`_
101 * Other manual testing and QA information
102 * Testing methodology. How extensive was it? What should be expected to work?
103 What has not been tested as much?
108 * Is it possible to migrate from the previous release? If so, how?
110 .. note:: This is asking if somebody can move from an installation of the
111 previous release while keeping data. This isn't currently, natively
112 supported in Opendaylight, so if it's possible, it is because of
113 some project-speicific work and instructions which should be
114 explained here. Remove this note.
119 .. Please include a short description of any changes not just a link to a patch
121 * Is this release compatible with the previous release?
123 * Any configuration changes?
128 .. Please include a short description of any bugs not just the link.
130 * List of bugs fixed since the previous release
135 .. Please include a short description of any bugs not just the link.
137 * List key known issues with workarounds
138 * `Link to Open Bugs <URL>`_
143 * List of features/APIs which are EOLed, deprecated, and/or removed in this
149 * List of standrads implemented and to what extent
154 * `Link to release plan <URL>`_
155 * Describe any major shifts in release schedule from the release plan
157 .. note:: We will also ask about your testing of the latest SR, but that should
158 probably not formally be part of this document. Remove this note.