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
21
23
24
30
(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
[x] Develop an automated git-integrated approach based on editing a centralized file to create these groups consistently. @ajbozarth has taken on this
[x] 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
[x] 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
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
These are defined as a hierarchy in github, where each group selects a subset from it's parent ie
and so on.
The members of each group are as per
21
23
24
30
(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