5 This page documents the current rules to follow when adding and removing
6 a particular project to Simultaneous Release (SR).
11 The state names are short negative phrases describing what is missing to
12 progress to the following state.
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.
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
24 - **not-in-autorelease**
25 Project merge job passes, but the project is not added to
26 autorelease (git submodule, maven module, validate-autorelease job passes).
27 - **failing-autorelease**
28 The project is added to autorelease (git submodule, maven module, validate-autorelease job passes),
29 but autorelease build fails when building project's artifact.
30 Temporary state, timing out into not-in-autorelease.
31 - **repo-not-in-integration**
32 Project is succesfully built within autorelease, but integration/distribution:features-index
33 is not listing all its public feature repositories.
34 - **feature-not-in-integration**
35 Feature repositories are referenced, distribution-check job is passing,
36 but some user-facing features are absent from integration/distribution:features-test
37 (possibly because adding them does not pass distribution SingleFeatureTest).
38 - **distribution-check-not-passing**
39 Features are in distribution, but distribution-check job is either not running,
40 or it is failing for any reason. Temporary state, timing out into feature-not-in-integration.
41 - **feature-is-experimental**
42 All user-facing features are in features-test, but at least one of the corresponding
43 functional CSIT jobs does not meet Integration/Test requirements.
44 - **feature-is-not-stable**
45 Feature does meet Integration/Test requirements, but it does not meed all requirements for stable features.
46 - **feature-is-stable**
50 A project may change its state in both directions, this list is to make sure
51 a project is not left in an invalid state, for example distribution referencing
52 feature repositories, but without passing distribution-check job.
56 - Add links to documents concerning project lifecycle from TSC point of view.
57 - Add links to M# templates, test requirements and other relevant info.
58 - Mention other jobs involved in verification (verify, validate-autorelease, ... releng-check-poms).
59 - Add back-references to this document (from integration/distribution, job definition templates, ...).
60 - Do we need a special rules applicable at Release Review?
61 - Mention that some rules do not make sense for Integration/Distribution project, provide substitute rules.