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 4, 2022

Attendees: David McBride , Thomas Kulik   , Amy Zwarico , Muddasar Ahmed   , Fiachra Corcoran, Tony Hansen , Pawel 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://wiki.onap.org/x/RgR9B

•  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 , Amy Zwarico  Pawel 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

...

• 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.

...