consolidate user/group setup for mlkem implementation repositories
Closed this issue · 1 comments
During the hackathon the intent was to create the following repositories and groups for implementations, with an additional high level group. I wanted to record the approach taken (intended!), raise it for discussion, and reference ongoing work to improve
repo | contributors (read) | maintainers (maintain) | admin (admin |
---|---|---|---|
mlkem-c-generic | pqcp-generic | pqcp-generic-maintainers | pqcp-generic-admin |
mlkem-c-embedded | pqcp-embedded | pqcp-embedded-maintainers | pqcp-embedded-admin |
mlkem-libjade | pqcp-libjade | pqcp-libjade-maintainers | pqcp-libjade-admin |
mlkem-rust-libcrux | pqcp-libcrux | pqcp-libcrux-maintainers | pqcp-libcrux-admin |
These are defined as a hierarchy in github, where each group selects a subset from it's parent ie
- pqcp-contributors
- -> pqcp-c-embedded
- -> -> pqcp-c-embedded-maintainers
- -> -> -> pqcp-c-embedded-admin
and so on.
The members of each group are as per
(I"ll update with literal names if I get a chance later)
In principle each group should have at least one maintainer (the creator also is setup by default).
This setup is tedious, and during the event we made mistakes, so what has been created may not exactly follow this.
I wanted to share the intent since we have some followup actions
- Develop an automated git-integrated approach based on editing a centralized file to create these groups consistently. @ajbozarth has taken on this
- Ensure all members listed in the repo request issues are within the org, and the correct groups (if the above is likely soon, we should get the pipeline working and then update the definition
- Ensure all repos have the correct groups assigned (as above)
- Agree at the TSC (here? meeting?) that the naming convention / approach is ok. for example should we have used the actual repo name rather than a short-form ?
- Agree if 'read' is appropriate for contributors. It allows issue assignment, but some prefer triage or write