Re: [project-leads] Proposal to change GH org permission structure for committers
Amit Kumar Gupta
. . .
Do you have any data on how significant a problem this is? I assume 99% of a team's work happens in cf or cf-inc orgs, and forks are temporary in service of PR'ing to a repo in cf or cf-inc. For teams I've worked on in the past, someone has forked into their personal account and given the rest of the team members collab access to that repo, then tore it down after the PR is merged. Forking into a team account e.g. cf-routing also seems like it makes sense to solve this problem. But the main point IMO is that almost all the team's work happens in a discoverable place (cf or cf-inc), and the work that happens on these forks is ephemeral and not meant to receive further upstream PRs, they exist to PR into something else downstream.
See prev comment about how these team-specific orgs are generally not used for long-lived work that should be receiving PRs.
3) Use of the cloudfoundry-incubator for these forks is confusing to observers, and completely different from what the incubator is supposed to be.
Agree that cf-inc shouldn't be used to house forks. It's confusing, not the point of cf-inc, and doesn't scale (what happens when two teams want to fork nats into cf-inc?).
If there were a simple working agreement to do core work in cf or cf-inc, and use personal/team accounts/orgs for temporary forks for the purpose of PRs, would this solve the problems?
I would definitely be hesitant about wide-open push access across teams, I'd recommend allowing teams and people to organically choose the best cross-team collaboration workflow (cross-team pairing, PRs, direct commit) on a case-by-case basis.
On Wed, Dec 6, 2017 at 4:50 PM, Chip Childers <cchilders@...> wrote: