docs/release-process/milestone-readouts/m2/daexim.rst

   1 ======
   2 DAEXIM
   3 ======
   4
   5 Please provide updates on any previously-incomplete items from prior milestone
   6 readouts.
   7
   8 N/A. No prior incomplete item.
   9
  10
  11 Functionality Freeze:
  12 ---------------------
  13
  14 1. Final list of externally consumable APIs defined: Yes/No
  15
  16    Yes
  17
  18    - If you had Tentative APIs, have they been moved to Provisional or dropped?
  19      (Yes/No) <link to release plan>
  20
  21      No. No provisional API.
  22
  23    - If any of your Tentative APIs were dropped, have you notified all projects
  24      that were expecting them? (Yes/No) <link to e-mail>
  25
  26      N/A
  27
  28    - Also please list all dropped APIs.
  29
  30      N/A
  31
  32
  33 2. Are all your inter-project dependencies resolved (i.e., have the other
  34    projects you were counting on given you what you needed)? (Yes/No)
  35
  36    Yes.
  37
  38    - (If no, please list the features you were expecting that have not been delivered)
  39
  40    N/A
  41
  42    - (The respective project [1]_ you were expecting to receive them from)
  43
  44    N/A
  45
  46
  47 3. Were there any project-specific deliverables planned for this milestone?
  48    Yes/No
  49
  50    No planned deliverables.
  51
  52    - (If so, were they delivered? Yes/No)
  53
  54    N/A
  55
  56
  57 Karaf Features Defined:
  58 -----------------------
  59
  60 1. Are all your project's features that are intended for release added to the
  61    features.xml and checked into integration git repository? (Yes/No)
  62
  63    No new features. All features added in prior release.
  64
  65    - Please provide link to gerrit patch
  66
  67    N/A
  68
  69 2. List all top-level, user-facing, and stable Karaf features for your project.
  70    odl-daexim, odl-daexim-all
  71
  72    - For top-level and user-facing features, please provide a one-sentence
  73      description a developer and/or user would find helpful.
  74
  75     -- odl-daexim: This is the core feature.
  76     -- old-daexim-all: This contains the core and supporting features, like restconf.
  77
  78
  79 Documentation:
  80 --------------
  81
  82 1. List the kinds of documentation you will provide including at least:
  83
  84    - One user/operator guide section per user-facing feature.
  85    - One developer guide per top-level feature.
  86    - An installation guide for any top-level features that require more than
  87      feature:install <feature-name> to install.
  88    - Release notes (mandatory) [2]_.
  89    - Optional tutorials and how-tos.
  90
  91    User and developer guides already exist. No changes needed.
  92
  93
  94 2. Have you checked in a reStructuredText outline to the docs repository? (Yes/No)
  95
  96    Yes. Added in prior release.
  97
  98    - Please provide link to gerrit patch
  99
 100    N/A
 101
 102
 103 Integration and Test:
 104 ---------------------
 105
 106 1. Have you started automated system testing for your top-level features?
 107    (Yes/No)
 108    - (If yes, link to test report)
 109    - (If no, why?)
 110
 111    Yes.
 112    https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/daexim-csit-1node-basic-only-nitrogen/
 113
 114 2. Have you filled out basic system test plan template for each top-level
 115    feature (karaf and not karaf) and a comprehensive system test plan template
 116    including functionality, cluster, scalability, performance,
 117    longevity/stability for each stable feature? (Yes/No)
 118
 119    - (If yes, link to test plans)
 120    - (If no, why?)
 121
 122    Yes.
 123    https://github.com/opendaylight/releng-builder/blob/master/jjb/daexim/daexim-csit-basic.yaml
 124
 125
 126 3. Have you integrated odlparent 3 / yangtools 2? (Yes/No/NA)
 127
 128    - (If yes, link to gerrit patch)
 129
 130    No
 131
 132
 133 Project Specific:
 134 -----------------
 135
 136 1. Were there any project-specific deliverables planned for this milestone?
 137    (Yes/No)
 138    No
 139
 140    - (If so, were they delivered? Yes/No )
 141
 142    N/A
 143
 144
 145 2. Have you updated your project facts with the project type category? (Yes/No)
 146    Yes
 147
 148 3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? (Yes/No)
 149    Yes.
 150
 151 .. [1] Note that you can only reasonably hold a project to something if you
 152        formally asked for it during the release planning process and the project
 153        team members acknowledged that ask saying they would do it.
 154 .. [2] Release notes must be updated prior to a major release. It is a good idea
 155        to keep release notes as a living document when significant changes are
 156        made.
 157 .. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html