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