GitHub repository maintainers

17 views
Skip to first unread message

Brandon Mitchell

unread,
Oct 3, 2024, 4:05:09 PM10/3/24
to tob
Looking over the repositories under the OCI organization, I'm seeing some inconsistencies with who has access.

- We have multiple teams defined, but some may be out of sync with the current maintainers of each project: https://github.com/orgs/opencontainers/teams
- Branch control for the 2 person review is not enabled on all repositories.
- Whether the 2 person PR review may be bypassed by maintainers is not consistent.
- Common repositories, like those for the website, have a mixture of individuals and maintainer teams, and access for those teams is not consistent (full admin vs repository write access).
- Archived projects still have access to common repositories.
- The TOB has been added to some repositories with limited access.
- Many of the working groups are setup with a list of individuals rather than a team.

I'd like to propose a general cleanup of the various teams, removing folks that are no longer active with the project, and aligning the team list with the current maintainer list. But before going through that, I think it would make sense to define who should have what level of access to the various repositories (both the specs, code, and shared repositories), including if/when people are given direct access to repositories, and whether the TOB should have any direct access. And we should specify a common branch protection policy to be used on every repository.

Would this be appropriate for the TOB to define, possibly as a technical document in the TOB or .github repository? And if so, do folks have preferences for how the inconsistencies are resolved?

Thanks,
Brandon

Samuel Karp

unread,
Oct 3, 2024, 4:26:16 PM10/3/24
to Brandon Mitchell, tob
Seems appropriate to me for the TOB to define team access to repositories.  Regarding branch control and 2-person review, we haven't mandated that in the past; I'd want to make sure the project maintainers are on board if we make any changes there.

To unsubscribe from this group and stop receiving emails from it, send an email to tob+uns...@opencontainers.org.


--
Samuel Karp

Tianon Gravi

unread,
Oct 3, 2024, 11:39:44 PM10/3/24
to Brandon Mitchell, tob

To unsubscribe from this group and stop receiving emails from it, send an email to tob+uns...@opencontainers.org.

Aleksa Sarai

unread,
Oct 6, 2024, 4:22:28 AM10/6/24
to Tianon Gravi, Brandon Mitchell, tob
On 2024-10-03, Tianon Gravi <admw...@gmail.com> wrote:
> See https://github.com/opencontainers/.github/pull/33,
> https://github.com/opencontainers/runtime-spec/pull/1124#issuecomment-942883377,
> and
> https://github.com/opencontainers/image-spec/pull/935#discussion_r942633195
> for prior discussion on some of these topics.

To reiterate the points I made in those threads (hopefully a little more
concisely):

As things stand at the moment, projects define their own governance
rules and the TOB is not involved in that process (other than approving
the initial set of rules when the project is accepted) because the
governance rules are per-project and are maintained by the project's
maintainers. Given that is how things are structured now, we should try
to avoid overstepping that boundary unless there is some dispute where
we have to step in.
Maybe in principle the TOB needs read access to private repos in case of
a dispute, but I don't think we need day-to-day access to repos (and
IMHO that is somewhat overstepping a boundary since the TOB are not
de-facto maintainers of OCI projects).

As for branch protection and rules for "core" OCI projects, I think at
best we could try to alert maintainers about projects that have "weird"
rules that don't match their own governance and figure out what access
makes sense for "non-core" OCI projects (like the website, templates,
etc etc). But I don't think it makes sense for the TOB to actively
police the rules, at least given how things are currently structured.

> > Would this be appropriate for the TOB to define, possibly as a technical
> > document in the TOB or .github repository? And if so, do folks have
> > preferences for how the inconsistencies are resolved?
> >
> > Thanks,
> > Brandon
> >
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to tob+uns...@opencontainers.org.
> >
>
> To unsubscribe from this group and stop receiving emails from it, send an email to tob+uns...@opencontainers.org.

--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc

Brandon Mitchell

unread,
Oct 7, 2024, 10:58:57 AM10/7/24
to Aleksa Sarai, Tianon Gravi, tob
On Sun, 2024-10-06 at 19:22 +1100, 'Aleksa Sarai' via OCI Technical Oversight Board wrote:
On 2024-10-03, Tianon Gravi <admw...@gmail.com> wrote:
and
for prior discussion on some of these topics.

To reiterate the points I made in those threads (hopefully a little more
concisely):

As things stand at the moment, projects define their own governance
rules and the TOB is not involved in that process (other than approving
the initial set of rules when the project is accepted) because the
governance rules are per-project and are maintained by the project's
maintainers. Given that is how things are structured now, we should try
to avoid overstepping that boundary unless there is some dispute where
we have to step in.

For public repositories, does explicit read access give any added access? I've seen read access given on those and it didn't make sense to me.

As for branch protection and rules for "core" OCI projects, I think at
best we could try to alert maintainers about projects that have "weird"
rules that don't match their own governance and figure out what access
makes sense for "non-core" OCI projects (like the website, templates,
etc etc). But I don't think it makes sense for the TOB to actively
police the rules, at least given how things are currently structured.

In chatting with Sam, having the TOB define a recommended policy for each repository, but allowing projects to deviate from that, seems like an area of agreement. The important part for me is to notify the individual repositories that they have differences from the recommendations and make sure they are intentional, because I suspect many are not. For some of the cross project repositories, like the website and .github, that don't have individual maintainers, may be easiest to just align them with the recommendation by default.

Samuel Karp

unread,
Oct 7, 2024, 12:07:24 PM10/7/24
to Brandon Mitchell, Aleksa Sarai, Tianon Gravi, tob
It sounds like Aleksa, Brandon, and I are in agreement that the TOB should not mandate settings for individual OCI Projects, given that each Project manages its own governance, however the TOB can create recommendations and notify the Projects of deviance.
--
Samuel Karp
Reply all
Reply to author
Forward
0 new messages