Skip to content

Generate Project MetaData files #15

@RobertKielty

Description

@RobertKielty

The CNCF would like to improve the process whereby projects document their maintainer team to the CNCF.

@jeefy and @mrbobbytables have written up a design describing the format of the a project.yaml which will contain project meta-data focused on, but not limited to, maintainer line-up.

The maintainer-d database has all of the requisite data to generate these files on a per-project basis.

Tasks

  • Write code to generate project meta data files - perhaps including it in the bootstrap process 1
  • Write code to process updates to the files and have changes reflected in maintainer-d 2
  • PR the generated project files so that project maintainers can access their files.
  • Contact project maintainers on maintainer-circle/mailing lists, announce and describe the initiaive to start using project meta data files.

Footnotes

  1. The bootstrap process ingests data from an internal Google worksheet that has project and maintainer data, this data seeds the maintainer-d database and runs in an initContainer each time maintainer-d is deployed.
    As maintainer-d development matures we would like to retrieve maintainer and project data from a combination of LFX's http://openprofile.dev/ and https://lfx.linuxfoundation.org/tools/pcc/
    The bootstrap process has been implemented as a separate component from the maintainer-d server process so that in the future re-writing boostrap to ingest data from the LFX platform will be a relatively easy task once LFX tools provide us with a per-project maintainer line-up and can associate multiple email addresses with a single maintainer on a per-service basis, where a service is a 3rd-party service such as, FOSSA, Snyk, etc.

  2. The maintainer-d server listens for events on github-events.cncf.io and is currently processing events on cncf/sandbox for on-boarding. One of the design considerations here will be ease of configuratoin wrt to where the project meta data files are located. Centralizing file locations on a single CNCF repo will make it easier to deploy but this will mean that we have to tell projects, go to this CNCF repo to update your maintainer line-up, distributing the meta data files out in the project orgs will mean that we have to ask projects to configure the maintainer-d webhook end-point on the GitHub settings on those repos. It will alss place a location tracking burden on maintainer-d. A decision for CNCF Project Teams leadership in consultation with the wider community needed here?

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions