Re: Proposal to change GH org permission structure for committers


Jesse T. Alford
 

Yes, you're understanding me right, David.

RelInt's automation around this focused on branch freshness. If a branch wasn't updated in a couple of weeks (or a month, I think), a CI job would start failing. If it was an outstanding PR we hadn't gotten to, merging develop to the PR would fix the problem. Our PM would followup with people who had commits on the branch if we couldn't tell why it was still around.

I believe the Diego team currently maintains a cf-deployment branch. It doesn't fail the freshness test, because they keep it fresh.

To Chip's point, my experience definitely bears out that social functions are sufficient to manage these sorts of situations. Teams with push access to the repo _and_ an agreement with RelInt that they can push directly to develop still sometimes make PRs because they'd like a review of their style or approach.

I really wish Github offered a way to limit push access to release/master branches, partly because this increases safety when collaborating across teams and their associated conventions, but basically because I only want a robot to push to release branches much of the time, and I want those commits to be fast-forward-only-merges from develop post-CI. The existing force-push/deletion protection isn't as robust as I'd prefer.

On Thu, Dec 7, 2017 at 2:47 PM David McClure <dmcclure@...> wrote:
I think I'm in favor of this idea overall as well.

Jesse, if I understand correctly, you're advocating "don't fork, just use branches".  Is that right?

What about the case where team A needs to use a fork/branch in team B's repo for an extended period of time?  What mechanisms might we use to help people know *not* to delete that branch?

I guess this is just a specific case of how branch cleanup may be complicated (how do we know no one is using this anymore? can we delete it?)  I guess you can look at the recent commits and reach out to those committers...



On Thu, Dec 7, 2017 at 1:26 PM, Jesse T. Alford <jalford@...> wrote:
I support this idea.

The CF Release Integration team encourages other teams to use branches on their repos when PRs are appropriate, and in cases of closer collaborative relationships, commit directly to develop when that is appropriate. A small amount of additional automation and administrative overhead around branch cleanup was necessary, but we found it a very workable approach to have other teams using branches in our repos as suited them.

- Jesse Alford,
recent anchor of Release Integration

On Thu, Dec 7, 2017 at 12:41 PM Chip Childers <cchilders@...> wrote:
Thanks Adam,

I've been involved in some other very large OSS communities, and frankly this has not been a problem in any of them. Occasionally someone makes a mistake, but then things get fixed. Coding is a social activity, and, instead of using rules and permissions, why not have trust in your fellow contributors to do the right thing?

OTOH, if a PR is just sitting there and not being reviewed, causing whomever (other project team or outside contributor) to want to just commit the change, then that project team is doing something wrong that's perhaps even more concerning.


On Thu, Dec 7, 2017 at 11:08 AM Adam Hevenor <ahevenor@...> wrote:
On the Loggregator team we are currently supporting a large number of repos that sprawled across both /cloudfoundry and /cloudfoundry-incubator and I certainly think we are reaching the limits of our current approach to administration. Like Gabe though I am mostly against the idea that runtime teams could commit directly to repos outside of their core responsibility. I can think of a very recent circumstance where I am sure our collective patience for a PR would have elapsed and we would have just pushed a change through. This would have disrupted workflow of feature not yet fully delivered and I know I would find it difficult to manage acceptance and packaging of releases if this was occurring regularly in our repos. 

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.