Re: Proposal to change GH org permission structure for committers

Gabriel Rosenhouse <grosenhouse@...>

Hi Chip,

Thanks for taking the time to describe this proposal to the community. 

I want to make sure I'm understanding correctly.  Unfortunately "team" and "project" mean very different things for Cloud Foundry than for GitHub.  If I'm understanding, you're proposing two very impactful changes:

a) every committer to any Runtime PMC project (e.g. everyone on the CF Routing team) has push access to any/all repos owned by all other Runtime PMC project teams (e.g. Release Integration)

b) project teams are no longer allowed to have their own GitHub orgs (e.g.

I have a couple concerns with this approach:

1. I don't trust myself with push rights to other teams's repositories

Our team (Routing) frequently PRs changes to code that is maintained by other CF teams.  Today, this workflow is involves forking their repo into our team org, making changes on a branch there, and then opening a PR.  It is pretty easy during this process to accidentally push the wrong commits to the wrong branch.  I'd be worried that if we were not doing the fork+PR model and instead I had push access to the "upstream" repo directly, then I'd accidentally push a merge commit with a lot of junk to their master or develop branch.  This would be painful for them to clean up, and painful for other teams to deal with in the meantime.

Team code ownership (as opposed to individual) is a powerful model.  But I'm worried that it doesn't scale much beyond our existing 2-pizza teams.

2. Forking 3rd-party repos becomes more painful

Our team occasionally PRs changes to outside code, maintained by other individuals and organizations.  We have to fork the repo in that case.  If we didn't have a team org, we'd need to fork into the cloudfoundry org.  Today, I don't have permission to fork into the cloudfoundry org (I don't see anything in your email about changing that).   So I'd have to put in a ticket and wait for an Admin to do that for me.  The Admins are usually crazy fast at this stuff, but the long-tail can stretch into hours and that really impacts our development efforts.

I wonder if we can find other solutions to your listed problems, maybe with more sophisticated CLA bot setup and more narrowly drawn policies around what kinds of code goes in what orgs.


On Wed, Dec 6, 2017 at 4:50 PM, Chip Childers <cchilders@...> wrote:
All (especially committers and project leads),

Some of the CFF project teams have been working in team specific GH orgs as a way to fork other project team repos that aren't core to their own efforts. Others have been using the cloudfoundry-incubator org for this same purpose. Largely, this seems to be happening inside of the Runtime PMC projects, but may be happening in other projects. Neither is optimal, for several reasons:

1) People that aren't on the project teams have a hard time finding where work of that project team is actually happening.
2) The team specific orgs are not typically setup to ensure CLA's for any inbound pull requests.
3) Use of the cloudfoundry-incubator for these forks is confusing to observers, and completely different from what the incubator is supposed to be.

Today, permissions are established for specific teams to access specific repos. In most cases they are limited to the repos owned by their project. In some cases, teams are already sharing commit rights to repos from other projects. The theory of locked down permissions is tied to the assumption of code ownership by one specific team.

I propose we change both the technical aspects of how permissions are handled, and the social / community aspect of how committers work with other project teams.

Specifically, I propose that we change our permission model to a much simpler one:

1) A single team for all committers in each PMC. That team would be given write permission across all repos that are part of projects in that PMC in both the cloudfoundry-incubator and cloudfoundry GH organizations.
2) All repos would also have a default branch selected and set as "protected" (disabling deletion and things like forced push).

This would both simplify some of the administrative work (much of which is handled by the awesome admin team at Pivotal today), and allow us to change our community's approach to cross project collaboration. Specifically, teams that want to make changes to another project's repo would create a branch in that repo to do their work in (and from which to do a PR). Project teams would still "own" their repos (and default branches), but this would be convention not enforced via permissions.

I welcome your thoughts and feedback on the proposal!

Chip Childers
CTO, Cloud Foundry Foundation

Join to automatically receive all group messages.