docs/release-process/project-lifecycle.rst

   1 *****************
   2 Project lifecycle
   3 *****************
   4
   5 This page documents the current rules to follow when adding and removing
   6 a particular project to Simultaneous Release (SR).
   7
   8 List of states
   9 ==============
  10
  11 The state names are short negative phrases describing what is missing to
  12 progress to the following state.
  13
  14 - **non-existent**
  15   The project is not recognized by Technical Steering Committee (TSC) to be
  16   part of OpenDaylight (ODL).
  17 - **non-participating**
  18   The project is recognized byt TSC to be an ODL project, but the project has
  19   not confirmed participation in SR for given release cycle.
  20 - **non-building**
  21   The recognized project is willing to participate, but its current codebase is
  22   not passing its own merge job, or the project artifacts are otherwise
  23   unavailable in Nexus.
  24 - **failing-distribution-check**
  25   Merge job passes, but project distribution-check job is either not defined
  26   or failing.
  27 - **not-in-autorelease**
  28   Project distribution-check passes, but the project is not added to
  29   autorelease (git submodule, maven module)
  30 - **repo-not-in-integration**
  31   Project is added do autorelease, but integration/distribution:features-index
  32   is not listing all its feature repositories.
  33 - **feature-not-in-integration**
  34   Feature repositories are referenced, but some user-facing features are absent
  35   from integration/distribution:features-test
  36 - **feature-is-experimental**
  37   All user-facing features are in features-test, but at least one corresponding
  38   functiona CSIT jobs does not meet integration/test requirements.
  39 - **ready**
  40
  41 .. note::
  42
  43    A project may change its state in both directions, this list is to make sure
  44    a project is not left in an invalid state, for example present in
  45    autorelease but without passing distribution-check job.
  46
  47 .. todo::
  48
  49    - Add links to documents concerning project lifecycle from TSC point of view.
  50    - Add links to M# templates, test requirements and other relevant info.
  51    - Mention other jobs involved in verification (verify, validate-autorelease, ... releng-check-poms).
  52    - Add back-references to this document (from integration/distribution, job definition templates, ...).
  53    - Do we need a special rules applicable at Release Review?
  54    - By adding features to integration, distribution-check job may start failing on issues
  55      that were not visible before. Document a workaround or create a specialized verify-like job.
  56    - Mention that some rules do not make sense for Integration/Distribution project, provide substitute rules.