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
Apr 18, 2022
Attendees: David McBride , Amy Zwarico , Muddasar Ahmed
- Amy Zwarico shares slide describing process flow leading to deprecation (archived) for different starting conditions.
- Muddasar Ahmed : https://wiki.onap.org/x/Pw_LBQ
- Follow up on actions:
- TSC meeting was canceled last week, so unable to request exception to GR process
- Thomas sent email to LFIT and followed up with meeting.
- We will discuss the outcome of the meeting next week.
Apr 11, 2022
Attendees: David McBride , Amy Zwarico , Muddasar Ahmed , Fiachra Corcoran , Paweł Pawlak, Maggie C, Thomas Kulik , Andreas Geissler
- Need to ask TSC for an exception to the Global Requirement process so that we can create a GR immediately, rather than going through the best practice phase.
- David to make request in April 14 meeting
- Plan is to create a REQ, then create child issues for each project that needs to remove a dependency
- Start with AAF? Portal?
- Portal for Kohn
- Start socializing AAF for removal in London release
- Process for identifying and documenting dependencies
- Arch review?
- Discuss / socialize in PTL meeting
- Mailling list query
- Thomas Kulik send email to LFIT to begin the discussion about using repos.yaml to automate processes for repositories. Follow up discussion in this meeting, or the PTL meeting (standing LFIT agenda item).
Apr 4, 2022
Attendees: David McBride , Thomas Kulik , Amy Zwarico , Muddasar Ahmed , Fiachra Corcoran, Tony Hansen , Paweł Pawlak, Kenny Paul , Maggie C, Timo Perala
- Follow up on Kenny's action item from Mar 7: checklist for steps to follow for project transitioning to unmaintained
- Kenny Paul to check with Edge and other projects: how do other major projects handle critical communication to end users
- repo.yaml and schema
- No progress with schema
- Should we move forward with repo.yaml file without a schema
Mar 28, 2022
Attendees: David McBride , Thomas Kulik , Amy Zwarico , Muddasar Ahmed , Cedric Ollivier, Fiachra Corcoran, Tony Hansen , Paweł Pawlak
- Gerrit: https://gerrit.onap.org/r/c/relman/+/127959
- Is "unmaintained" a project level, or a repo level, attribute?
- Should we add another lifecycle state, "Closed"
- Active (i.e., incubation, mature, core): currently maintained and included in release
- Unmaintained: no longer active, but still part of a release.
- Not a persistent state.
- Should be moving toward Closed by removing dependencies.
- Closed: no longer part of a release
Mar 21, 2022
Attendees: David McBride , Thomas Kulik , Amy Zwarico , Muddasar Ahmed , Cedric Ollivier, Fiachra Corcoran, Tony Hansen
- New repo (relman) created.
- Next steps?
- Thomas is working on the repos.yaml file, as well as a schema for validation.
- What's the process when we need to branch an unmaintained project (i.e., in the case where there are dependencies on the unmaintained project)
- One option: create list of unmaintained projects that must be branched and submit as a ticket to IT
- Another option: relman committers have rights to branch unmaintained projects
- Cedric advises that Jenkins jobs should be updated and/or removed as projects are removed from the release. Removing them later can be difficult and tedious.
- Present slide deck to PTLs on Mar 28
- Fiachra Corcoran suggests AAF as a trial
- Tracking:
- Use Best Practice / Global Requirement process as a parent ticket with child tickets for reach project with a dependency
Mar 7, 2022
Attendees: David McBride , Thomas Kulik , Tony Hansen , Amy Zwarico , Muddasar Ahmed , Kenny Paul , Robert Heinemann , Cedric Ollivier
- 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.
- No meeting next week due to DTF Workshop event
- Adjust time to two hours earlier due to DST shift of PTL meeting. (i.e., 6 a.m. Pacific)
Feb 28, 2022
Attendees: David McBride , Thomas Kulik , Tony Hansen , Amy Zwarico
- TSC approved creation of a new repo without the need for a formal project
- Question: is yaml the best format, or should we use something else (json, xml)?
- consistent with other config files
Feb 14, 2022
Attendees: David McBride , Kenny Paul , Thomas Kulik , Tony Hansen , Amy Zwarico
- Plan for creating new repo to contain repo status file
- Request exception from TSC to create new repo without creating a new project
- Could be useful for other artifacts, such as release management Jira task generation
- Should we use GitLab?
- Repo name? How about "relman" or "rel-man"? Or "release-management" (like the already existing "ci-management" repo)?
- Thomas Kulik has proposal for file configuration (a very first draft: repos.yaml).
- Avoid repeating information found in the info.yaml file
- Should we capture project association? The project association for most repos can be identified by the path name. However, some (e.g., "oparent" belongs to INT) are not obvious.
Feb 7, 2022
Attendees: David McBride , Kenny Paul , Fiachra Corcoran , Thomas Kulik , Eric Debeau , Tony Hansen , Cedric Ollivier , Amy Zwarico
- 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
Jan 31, 2022
Attendees: David, Kenny, Fiachra, Amy, Thomas, Eric, Pawel, Timo, Tony
Re-cap from Dec 13 - discussion
- Eric reports that the REST call scanning tool may work well at the project level, but there is not enough information to identify dependencies to the repo level.
- Fiachra says that there are also some Kubernetes tools that might be useful (https://learnk8s.io/visualise-dependencies-kubernetes).
- Cedric Ollivier suggests maintaining a text file in git that documents the status of all repos used by the project
- This would be one file for all projects
- Use a structured markup. YAML?
- PTLs would update as a release management task. Probably at M1.
Jan 24, 2022
Attendees: David, Muddasar, Amy, Thomas, Tony, Kenny, Eric, Cedric
- Re-cap from Dec 13 - discussion
- Thomas says that we should start with dependencies at the project level, since we don't have an obvious way to get repo level dependencies
- Eric made an attempt to create a dependency graph.
- Very complex and time consuming manual operation! However, we believe that relationships are stable, so this may be worthwhile.
- Note that some dependencies are optional; however, the map does not currently differentiate between optional and required.
- Cedric suggests an alternative, automated way to identify dependencies: develop script to analyze code and detect REST calls
- Eric / Cedric to test with one or two components and report back to this meeting (next week?)
- What might process look like? (tentative)
- Release management task: PTLs review JSON file and make updates to dependencies
- This would be a pre-requisite to the architectural review between M1 and M2
- Run dependency tool to create map
- Review map against unmaintained projects list
- Who would do this?
- PTL / arch subcommittee
- Create Jira ticket to identify and track dependency?
- Start countdown clock for projects to remove dependency
- TSC must decide policy on how quickly dependencies must be resolved
- Strict: no release with dependencies
- Flexible: dependencies resolved over 2 or more releases
Dec 13, 2021
Attendees: David, Pawel, Tony, Chaker, Thomas, Kenny
- David McBride asks Chaker Al-Hakim to describe how the Arch Subcommittee works with project dependencies
- Chaker says that dependencies are tracked at the project level, not the repo level.
- Need to map dependencies to the repo level
- Example: DMAAP archived a repo, but the project is still active. What if active projects have a dependency on the repo that was archived?
- Chaker shares the review template with a new section that asks about dependencies.
- Thomas Kulik suggests that "critical dependencies" should be replaced by "dependencies".
- Chaker believes that mapping dependencies between projects at the repo level is outside of the scope of the architectural review.
- Need to understand both build dependencies and functional dependencies.
- Kenny: Force updates by removing unmaintained projects from OOM.
- Build failures and test failures will highlight dependencies.
Dec 6, 2021
Attendees: David, Kenny, Amy, Andreas, Muddasar, Pawel, Tony, Cedric
- Andreas: how are unmaintained projects represented in the arch diagram
- Chaker says that the diagram includes unmaintained projects for one release past when they were moved to unmaintained
- Unmaintained Project Dependencies.pdf
- Audit (propose to TSC on Thursday)
- Develop a map of dependencies between components
- David to present to the TSC
- Unmaintained => Archived should happen when there are no longer any dependencies on the unmaintained project
- Already documented? Kenny will check.
Actions:
- David McBride ask Chaker to attend next week's meeting to discuss arch subcommittee and unmaintained project dependencies
Nov 29, 2021
Attendees: David, Kenny, Amy, Cedric, Thomas
- Scope:
- Documentation
- Software dependencies (incl. uses cases)
- Understand what repos are actually part of a release - not just the projects in a release.
- Increased transparency on software modules included in an ONAP release
- Need an x-project dependency tree from the PTLs of all active projects
- repos with no dependencies should be locked
- repos with dependencies where unmaintained need to have the conversation
- end state needs to be an awareness of unmaintained dependencies.
- Release notes should document any use of or dependency on unmaintained projects/repos
- Amy: goal should be no dependency on unmaintained projects. However, we will still have exceptions
- Suggestion that we look at ESR/Logging and Portal as the litmus test for Jakarta
- Doc team will not include non-branched / unmaintained content going forward.
- Need an automated way for identifying the dependencies. SBOM?
- Should the arch subcommittee be tasked with determining whether a use case has a dependency on an unmaintained project?
- Example: Cannot pass arch review if there is a dependency on an unmaintained project without an exception from the TSC.