Versions Compared

Old Version 13

changes.mady.by.user Kenny Paul

Saved on

compared with

New Version 14

changes.mady.by.user David McBride

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

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"?
  • Thomas Kulik has proposal for file configuration.
    • 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

...