These meetings were initiated in response to ongoing discussions in the TSC and PTL meetings about dealing with dependencies on unmaintained projects, as well as documentation.
Meeting Minutes
May 16, 2022
Attendees: David McBride , Amy Zwarico , Muddasar Ahmed , Fiachra Corcoran , Maggie C, Andreas Geissler , Tony Hansen , Robert Heinemann
- Amy to present unmaintained project process document to the TSC this week
- Docker Version Evolution tool
- Appears that there may still be some errors. Fiachra will investigate.
- May not be showing every docker image. Only shows images that are deployed by default.
- Amy suggests that we identify a subset of repos, using the gray filter in the docker version tool, to resolve for the Kohn release
- Do we want to pursue projects (e.g., portal) or components or both?
- Tool evaluates to N-2 (includes maintenance releases). Is that sufficient?
- Consensus is that N-2 is fine for now.
- Amy to propose some components for evaluation in the Kohn release, using the list generated by the docker version tool (gray filter)
May 2, 2022
Meeting canceled.
Apr 25, 2022
...
- Need list of new committers for repo
- David, Tony, Thomas
- Propose to the TSC in an email
- David McBride to send email to TSC with list of proposed committers for new RM repo
- General consensus on process documented here
- PTL develops plan for resolution of dependency. Arch SC reviews and approves.
- PTL requests exception from TSC
- Documentation
- Last available release notes and doc should be included for unmaintained project that is required for release due to dependencies
- Add note that project is a) unmaintained; and b) included due to PTL request and TSC approval of exception
- updated: Branching I: Branching is required for every repo
that is planned to be included into the release - regardless if it is "maintained" or "unmaintained" (Important Note: "unmaintained" repos/projects are added to a release only with exception of the TSC; this exception also includes a plan how to resolve the dependencies to the "unmaintained" repo/project; see above). - updated: Branching of unmaintained projects by LFIT/supercommitter?
- updated: Branching II: If we follow this rule (Branching I) we do not need the "included_in:" section in repos.yaml
- updated: There is still a information gap: By branching every repo that is part of the release we still do not know reliably, what version of the repo was used to build the container (which are going to be deployed in the ONAP release). How to solve this?
- updated: We should remove all "latest" documentation links for unmaintained projects. (This requires the described TSC exceptions and branches for the respective, unmaintained repos/projects).
- Check list for project becoming unmaintained
- PTL available
- PTL not available
- Kenny Paul draft checklist for review in this meeting.
...
- Consensus that repo yaml file proposal is a good start. May want to add additional data later.
- repos.yaml
- Create new repository called "release management" or similar for file
- Maybe a repo in the integration space if OK with the PTL.
- should not create ongoing work for the Integration team (beyond initial repo creation)
- Release Manager would need to have +2 rights for the repo.
- if in a existing repo committer privs should be decoupled from the privs of the parent repo
- May cause more issues than it is worth
- stand alone may be more appropriate even if more initial work to create.
- Envision this as being the authoritative source for this info.
- Start with just capturing which repos are in use for a particular release in the file - once established it can then be leveraged by other tooling.
- Who ends up being responsible for updating INFO.yaml and repos.yaml files if the PTL is gone?
- can rely on RelEng super committer rights if need be
- Request for a json version to also be generated from the repos.yaml
- Kenny Paul David McBride discuss a project proposal for stand alone repo creation.
...