[llvm-dev] [RFC] One or many git repositories?

[Renato Golin via llvm-dev]

On 25 July 2016 at 14:29, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> These are both good questions for someone more familiar with the Buildbot infrastructure than me.

Don't look at me! :)


> Not hard - there are two queues (stuff that’s ready to merge, stuff awaiting review) and you only start on the second queue when the first one is empty.

Indeed, why I mention priority queues. Should be trivial to implement,
but less so to maintain and to make it work everywhere. Development is
easy, software engineering is hard.


> These are the advantages.  The disadvantages are:
>
> - Someone needs to write the Buildbot integration code

Yup.

> - Committers need to adopt a slightly more complex workflow (though not more complex than going via phabricator)

Not entirely true. Pre-review committers can "just commit". I'm not a
big fan of that practice myself, I think it promotes "quick broken
changes that get quickly fixed later", but it is a big difference.


>> 4. Everyone else: just pull request access, need to wait for someone
>> in (2) to approve
>
> There’s not really a difference between 3 and 4 in this model.

That's my point.


> I have no idea about group 1.  This set roughly corresponds today to the set of people who are Chris, and should probably be half a dozen people for a bit more redundancy (admins are also the people who can add people to the GitHub group, create new repos, and so on).  It might be something overseen by the foundation.

Right, probably the people that have access to the servers today. Not
code owners, high committers. For *admin* purpose *only*.


> Give people membership in the group and let them know what the community expects them to have reviewed pre-commit.  If they start committing things that should have been reviewed without proper review and they don’t change their behaviour, then move them back into group 4.

Right, so *all* committers. This solves the "3/4 separation problem",
and it puts the conundrum to rest.

Today we *trust* all committers to do that, anyway, so there's no
reason to *not* do that in the future. Makes sense to me.


> I don’t see a need for a mechanical separation between groups 2 and 3.  In FreeBSD we have a concept of mentorship, where new committers must have ‘Approved by: {name} (mentor)’ in all of their commits and their mentor is responsible for ensuring that they are following the expectations of the community.  This is similarly not enforced by the revision control system (though, again, people who don’t do it may find that they can no longer commit).

The same is true here, but without the additional flag.


> It’s also worth pointing out that this is in no way required to happen at the same time as the GitHub migration (or at all), so should not delay that.  Just something for people to think about...

Got it.

Thanks!
--renato