You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

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

Mar 7, 2022

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

  • Need list of new committers for repo
  • No meeting next week due to DTF Workshop event

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)
    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.
  • No labels