...
- A deployable ONAP release consists of 'maintained' an 'unmaintained' software modules (used to build the docker container).
- Only 'projects' are managed in the release process
- But a 'project' consists of 1-n repositories. Repositories are not managed in the release process.
- If a project is (un)maintained, are all repositories (un)maintained?
- Only 'maintained' projects are managed in the release process.
- But "unmaintained" software modules (docker container) are added to the list of deployed software modules in the end of the release process (oom)
- Unmaintained, but deployed projects (not repositories!) of the 'Istanbul' release are:
- Application Authorization Framework AAF
- Application Controller APPC
- External API
- External System Register ESR
- Logging
- MUSIC
- Portal
- Virtual Infrastructure Deployment VID
- The management of 'release participation' is limited (projects, not repositories), distributed (relmgr, oom, sec, doc) and is not done in a collaborative, end-to-end manner
- Information about the lifecycle state of projects and repositories and their release participation is distributed, manually maintained and not in sync (, e.g.
- GIT: repository state (active |
- read only; Kenny? LFIT?)
- INFO.YAML
- : project state (inherited to every repo of the project; project lead)
- WIKI: release participation
- (release manager)
- WIKI: project lifecycle state
- (Kenny)
- WIKI: documentation
- tracking per release (doc team)
- WIKI: security vulnerabilities / package updated (sec team)
- OOM: helm charts?
Proposal
The information about software modules included in an ONAP release must be managed ...
...