Re: Proposal to change GH org permission structure for committers
Jesse T. Alford
toggle quoted messageShow quoted text
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: