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.

Proposed Unmaintained Project/Artifact Identification & Deprecation Process

Presented to PTLs March 13, 2023; Architecture subcommitte March 14, 2023

Amy Zwarico: Proposed process for removing unmaintained artifacts from ONAP
- Definition: artifact is unmaintained if has had no new build in over 12 months or it has no PTL
- Case 1: Artifact is part of a project without a PTL
  - Step 1: TSC engage Architecture subcommittee to determine other project dependencies on project
    - Case 1: No dependencies on project without PTL
      - TSC request LFIT to remove all project tasks from Jenkins and set repo(s) to read only
      - TSC creates DOCS Jira to add deprecation/removal of project from the ONAP release
    - Case 2: Other projects have dependencies on project
      - TSC initiate effort to find replacement for unsupported functionality
- Case 2: Artifact unmaintained and is part of a project with a PTL
  - Step 1: Each PTL notified via Jira of their unmaintained artifacts & Architecture subcommittee notified via ARCH Jira of all unmaintained artifacts in active projects
  - Step 2: PTL documents intra-project dependencies on artifact in the project Jira
  - Step 3: Architecture subcommittee determines inter-project dependencies via the architecture reviews and documents results in ARCH Jira
  - Step 4: PTL Removes unmaintained projects with no dependencies from the release
    - PTL creates a gerrit request in the CI management repo to remove the Jenkins jobs associated with the unneeded repos and set repos to read only
      - Jira should remain open until gerrit request is merged by LFIT (does this remove jobs from OOM?)
    - PTL adds removal of the artifact/repo to their release documentation and removes all other documentation about the artifact/repo from their documentation
  - Step 5: Architecture/Docs informs TSC of removal of artifacts/repos

Meeting Minutes

March 6, 2023

Attendees: David McBride , Amy Zwarico , Jessica Gonzalez , Thomas Kulik , Fiachra Corcoran , Thomas Kulik

Amy: we've discussed (see Feb 27 notes) the process when a project has a PTL, but what about the case where a project has no PTL?
In the case of no PTL, we need to use the project archiving process, vs the repo archiving process.
The ultimate goal is to avoid shipping unmaintained code
Update the arch review process to review any unmaintained Jiras assigned to the project
- Complete unmaintained Jiras by M1
- Arch review includes review of unmaintained Jiras and is completed by M2
  - Attach unmaintained Jira as linked issue to "request arch review" task at M1
- May not need to include arch task in unmaintained Jira
The team agrees that this should be the last meeting

David McBride send mail to Chaker and Byung explaining updated arch review process which includes a review of unmaintained Jiras

February 27, 2023

Attendees: David McBride , Amy Zwarico , Jessica Gonzalez , Muddasar Ahmed

The team concurs that we are ready to wrap up this task force.
We will use our remaining time to consolidate and summarize what we learned:
Part 1 - How do we identify candidate repositories for
- Script examines Jenkins release tab. Examines the last time that a particular artifact (repo) was published.
  - Amy, Bert, and Jess will coordinate to submit script into CI Management repo
- Script generates a list of artifacts that were not published in the last 12 months.
- This is the list of candidates for investigation for archiving
Part II - Investigate list of artifacts
- Generate Jira issue for each project. Note that a Jira issue could have more than one artifact.
  - Example: VFC-1983 - Getting issue details... STATUS
  - Note that these tickets use the "unmaintained" label
  - Jira issue should contain the following questions/directions
    - Is the image used by the project (already doing this)?
    - Is the image used by any other project (already doing this)?
    - What is the repo associated with the image or component?
    - Does the repo contain anything else that is still in use within the project, or anywhere in ONAP?
    - IF the PTL determines that the repo can be archived, then the PTL creates a gerrit request in the CI management repo to remove the Jenkins jobs associated with the unneeded repos
      - Jira should remain open until gerrit request is merged
    - TASKS
      - PTL - generate gerrit to remove jenkins jobs (submit LFIT if PTL not available)
      - Arch - review to identify dependencies and related issues
      - DOCS - exclude from documentation anything associated with the repository being archived
      - OOM - remove artifact from deployment
- PTLs provide feedback through the Jira issue as to whether the identified artifacts should be removed from Jenkins jobs and archived
Part III (See Oct 17 notes)
- PTL - Deprecate the Jenkins jobs that generate the image (see Jira directions above)
- Submit ticket to IT to deprecate the repo (archive)
  - Indicate in the ticket whether NexusIQ and Sonar reports should be retained
Other questions/issues
- Do we need to update Muddasar Ahmed RACI (last reviewed last October)
- Plan to share conclusions with the TSC
The team concurs that we need to meet at least one more time before closing the task force.

Feb 7 - 20

Canceled until Amy's Jira issues come due (Feb 22).

January 30, 2023

Attendees: David McBride , Amy Zwarico , Jessica Gonzalez , Muddasar Ahmed

January 23, 2023

Canceled by consensus

January 16, 2023

Canceled due to holiday

January 09, 2023

Attendees: David McBride , Amy Zwarico , Thomas Kulik

New tab that Jessica added: https://jenkins.onap.org/view/Release-Jobs/
- Note that the spreadsheet that Bert generated is a filter of this page.
Next actions:
- Amy to review Bert's list of repos (see spreadsheet linked to Jan 5 minutes) with PTLs on Jan 23
- Invite Jessica to Jan 23 meeting to reconcile Insights page vs Jenkins tab. How are these related?
- Thomas to investigate adding the last user associated with last repo activity to the "Release Jobs" Jenkins page
  - Amy will talk with Bert about doing the same, only using the API, instead, to extract the user name
Next meeting - Jan 23 (Note: Jan 16 canceled due to MLK holiday)

December 19, 2022 - January 2, 2023

Canceled due to winter holidays.

December 12, 2022

Attendees: David McBride , Amy Zwarico , Jessica Gonzalez

Jessica Gonzalez shares Insights: https://insights-v2.lfx.linuxfoundation.org/onap/code-base/repositories-that-need-attention
- May be useful in analyzing which repositories we should focus on archiving
Next meeting is Jan 9.

December 5, 2022

Attendees: David McBride , Amy Zwarico , Fiachra Corcoran , Jessica Gonzalez

Process (supplements use of Version Evolution Tool):
- from the release merge jobs within Jenkins
- generate a list of runs of release jobs across all ONAP (artifacts + images)
- use the last successful run date to determine how recently the item was touched
- Use this list to communicate with PTLs
Jessica to join the meeting again next week (Dec 12).
Note that Dec 12 will be our last meeting of the calendar year. We will resume on Jan 9.

Jessica Gonzalez investigate API to automate generation of candidate list from Jenkins release merge jobs
Jessica Gonzalez make Jenkins release merge a permanent tab
Fiachra Corcoran generate a list of projects that still have helm charts in OOM that haven't participated in an ONAP release recently to review for removal from OOM
Bert Sloan (AT&T resource) use Jenkins API to pull all repos from Jenkins release-jobs list
- 34 repos have not had a merge in >12 mos
- release_jobs_12_5.xlsx

November 28, 2022

Attendees: David McBride , Amy Zwarico , Fiachra Corcoran

Amy asks, what do we want to accomplish for the London release?
Reviewed five closed unmaintained repo tasks assigned to Kohn.
Note: version evolution tool needs to be updated to include the Kohn branch
- Fiachra will coordinate with Michal to update the script.
Amy and Fiachra noted that we would still like to talk with Jessica.
- David to invite Jess to the Dec 5 meeting.
Next meeting is Dec 5.
Meeting is canceled Dec 19, Dec 26, Jan 2.

Fiachra Corcoran update version evolution tool to include Kohn branch

November 21, 2022

Attendees: David McBride

Meeting canceled due to low participation.
Next meeting is Nov 28.

November 14, 2022

Canceled due to ONE Summit

November 7, 2022

Attendees: David McBride , Thomas Kulik , Fiachra Corcoran

Meeting canceled due to low participation.
Next week (Nov 14) is canceled due to ONE Summit.

October 31, 2022

Meeting canceled.

October 24, 2022

Attendees: David McBride , Muddasar Ahmed , Tony Hansen , Byung-Woo Jun , Amy Zwarico

David to invite Jessica to the Oct 31 meeting.

October 17, 2022

Attendees: David McBride , Muddasar Ahmed , Tony Hansen , Thomas Kulik, Fiachra Corcoran , Thomas Kulik

Update request to PTL (conversation with Jessica):
- Is the image used by the project (already doing this)?
- Is the image used by any other project (already doing this)?
- What is the repo associated with the image or component?
- Does the repo contain anything else that is still in use within the project, or anywhere in ONAP?
Process for archiving a repository (conversation with Jessica)
- PTL - Deprecate the Jenkins jobs that generate the image
- Submit ticket to IT to deprecate the repo (archive)
  - Indicate in the ticket whether NexusIQ and Sonar reports should be retained
Muddasar Ahmed points out that step 5 in the RACI belongs with step 1
- Muddasar to combine step 5 into step 1, then delete step 5

October 10, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed , Tony Hansen , Byung-Woo Jun , Kenny Paul

VFC-1978 was updated with a comment that shows the repo associated with the image vfc-huawei-vnfm-driver
IT ticket updated to request that repo be archived
We also need to confirm that there is nothing else in the repo that is still in use
How do we determine the repo from the image that is displayed by the version evolution tool?
Do we need to follow two steps: 1) stop image generation; 2) archive repo
David to discuss docker generation with RELENG. How do we stop it?
David to submit request to IT to remove all instances of the image policy-mariadb (POLICY-4308)
Muddasar Ahmed points out that we should finish polishing the unmaintained repo process, then present it to the PTLs.
- Tentatively plan on Oct 24 or Oct 31

October 3, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed , Tony Hansen

Discussed issue of authority for archiving repositories, since this came up at the TSC meeting last week. We agreed on the following.
- PTL may authorize archiving. No TSC approval needed.
- If PTL is unavailable, then the TSC must authorize archiving.
- Archiving a single repo or subset of repos is different that archiving a project, or otherwise changing the project lifecycle state. That requires TSC approval.
IT reports that they are unable to find vfc-huawei-vnfm-driver (VFC-1978). Left note in Jira asking PTL to show us the location.

September 26, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed , Fiachra Corcoran

Some records reported by the version evolution tool are docker images, rather than repos (e.g., POLICY-4308)
- New link for tool (DT): https://logs.onap.org/onap-integration/daily/onap-daily-dt-oom-master/2022-09/24_05-31/index-versions.html (date specific)
- It appears that code repos can be distinguished by "nexus3" in the URL in the image column
Fiachra Corcoran suggests an improvement to the tool to differentiate between "infra" and source code repos
Agreement that we should focus on code repos from Nexus3. We will reconsider docker images later.
Reviewed unmaintained Jira tickets
- DCAEGEN2-3233 - deferred to London release
- VFC-1978 - will propose archiving vfc-huawei-vnfm-driver to the TSC
- POLICY-4308 - This refers to a docker image. The team decided that we will focus on code repos for now. However, we may look at this again in the future.
- MSB-701 -Docker image - see notes above
- AAI-3514 - AAI PTL reports that repos are still in use. Lack of updates appears to be due to the lack of new development, but also due to a lack of updating vulnerable packages. Left comment to PTL to that effect.

September 19, 2022

Attendees: David McBride , Thomas Kulik , Amy Zwarico , Muddasar Ahmed

Reviewed Jira issues assigned by Amy to projects with candidates for unmaintained repo processing.
Created Jira epics
David to propose to the TSC archiving vfc-huawei-vnfm-driver (VFC-1978).

August 29, 2022

Attendees: David McBride , Thomas Kulik , Amy Zwarico , Tony Hansen

Meeting canceled next week (Sept 5) due to the Labor Day holiday. Next meeting, Sept 12.

August 22, 2022

Attendees: David McBride , Thomas Kulik , Amy Zwarico , Tony Hansen

Review RACI (see link below)

August 15, 2022

Attendees: David McBride , Thomas Kulik , Amy Zwarico , Byung-Woo Jun , Tony Hansen , Kenny Paul

If a project is not participating in a release, can they CLOSE - won't do, or defer to the next release?
- Team feels that projects should continue to support unmaintained repo activities / information gathering, even if they are not participating in the release
- Need an escalation process
- Kenny Paul suggests that RM should escalate
RACI: Project State: Unmaintained
- Review next week

August 8, 2022

Attendees: David McBride , Andreas Geißler , Thomas Kulik , Amy Zwarico , Byung-Woo Jun , Tony Hansen , Kenny Paul

Feedback

July 25, 2022

Attendees: David McBride , Andreas Geißler , Thomas Kulik , Amy Zwarico , Byung-Woo Jun , Muddasar Ahmed , Paweł Pawlak , Tony Hansen

Feedback from Fiachra on status of version evolution tool: The Linux Foundation Mail - status of version evolution tool?.pdf
Andreas reports that version evolution tool has been activated on DT. Example.
What does it mean when a project does not participate in a release?
- What if the project has required changes?
- If there is a change to the project, are they still subject to release management tasks?
- Can we define a minimal participation for a release (i.e., bug fixes only + support tasks)

July 18, 2022

Attendees: David McBride , Andreas Geißler , Thomas Kulik , Thomas Kulik , Amy Zwarico , Byung-Woo Jun , Muddasar Ahmed

Version evolution tool (Note: date specific) example: https://logs.onap.org/onap-integration/daily/onap_daily_pod4_master/2022-06/24_05-56/index-versions.html
Candidates for unmaintained project repo process (determined by selecting from list generated by using grey filter in version evolution tool):
- aai
- cli
- dcae
- dmaap
- policy
- multicloud
- so
- vfc
- vnfsdk
Use Jira label "unmaintained"
Jira summary should start with "Unmaintained"
Include a list of repos from the version evolution tool (grey filter) in the description for the Jira issue
Amy Zwarico will generate Jira issues for the projects above.
David McBride check with Fiachra about status of version evolution tool. Are there still bugs?
Latest unmaintained projects deck (v6): 22_04_18_ONAPUnmaintainedProjects_v6.pptx, 22_04_18_ONAPUnmaintainedProjects_v6.pdf

June 27, 2022

Attendees: David McBride , Tony Hansen , Thomas Kulik , Thomas Kulik , Muddasar Ahmed

Status of docker version evolution tool? Are there still issues?
Repo.yaml
- Use as a reference for status of every repo ("single source of truth")
  - For example, documenting the status of repos and projects in ONAP documentation
- Process?
  - Use a release management task at M1 or M2 for PTLs to review repos.yaml and update as needed
  - Need a process for projects that dissolve and where the PTL and committers are unavailable
- Format
  - still an open question
  - use yaml?
  - enumeration of states?
  - file validation?
- Need to align changes to repos.yaml file with process flow document

May 30, 2022

Canceled due to Memorial Day holiday

May 23, 2022

Attendees: David McBride , Tony Hansen , Timo Perala , Paweł Pawlak

Tony suggests that we re-visit the need and the purpose for the repos yaml file to determine how it fits into the archiving work flow that Amy has been presenting the past few weeks.
- Agenda item for June 6
Meeting ended early due to light attendance
Meeting canceled next week (May 30) due to the Memorial Day holiday

May 16, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed , Fiachra Corcoran , Maggie C, Andreas Geißler , 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.
- Fiachra Corcoran to check what contrib components can be disabled for daily/prod deployment
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)
Repos identified by grey filter should be discussed with projects during arch review
- If still required, why has no technical debt been retired?
- If not required, then retire the repo
- Invite Chakar next week to discuss

May 2, 2022

Meeting canceled.

Apr 25, 2022

Attendees: David McBride , Amy Zwarico , Muddasar Ahmed , Fiachra Corcoran , Paweł Pawlak, Maggie C, Thomas Kulik, Tony Hansen

Archive process flow will be presented in today's PTL meeting (Amy)
- See latest version attached to today's PTL meeting agenda
Unmaintained project dependency tracking using Global Requirements will be presented in today's PTL meeting (David)
Suggestion from Maggie to use color coding from slide in the documentation
Re-confirmed with team to pursue GRs for Portal and AAF with Portal being completed in the Kohn release, and AAF in the London release.
Meeting canceled next week

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://lf-onap.atlassian.net/wiki/x/mf76
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 Geißler

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
- https://lf-onap.atlassian.net/wiki/x/w1L6

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 , Cédric 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 , Cédric 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 , Cédric 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 , Cédric 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

Kenny Paul David McBride discuss a project proposal for stand alone repo creation.

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).
Cédric 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)
1. Release management task: PTLs review JSON file and make updates to dependencies
  1. This would be a pre-requisite to the architectural review between M1 and M2
2. Run dependency tool to create map
3. Review map against unmaintained projects list
  1. Who would do this?
    1. PTL / arch subcommittee
  2. Create Jira ticket to identify and track dependency?
4. Start countdown clock for projects to remove dependency
  1. TSC must decide policy on how quickly dependencies must be resolved
    1. Strict: no release with dependencies
    2. 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.

Browser not supported