Versions Compared

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

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 

...

  • 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

...