[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?

[Joachim Durchholz via llvm-dev]

Am 25.02.2016 um 14:41 schrieb Renato Golin:
> On 25 February 2016 at 12:46, Joachim Durchholz via llvm-dev
>> What workflow are you comparing this to, if a pull request is a penalty?
>
> Today, 100s of people commit directly.

Ah. I wasn't aware of that, I thought LLVM had a gatekeeper model.

 > In a GitHub style, 100s of
> people will have to wait for a merge from a few folks.

I guess in that case, you'd probably give these people write access to 
the GitHub repo.
It would probably be a good idea to prevent them from force-pushing and 
rebasing on the master branch so they cannot change recorded history. I 
am not sure whether GitHub allows that kind of restriction.

 > Those few folks
> will have the additional job of merging lots of patches. It's more
> like GCC, where maintainers are gate-keepers, and not one we have used
> so far. I'm ok with it, but other people might not.

It would be a considerable workload, but it would also be a considerable 
QA measure. From what I have seen, QA seems quite healthy on LLVM so I 
suppose the project will find that unattractive.

>> Nobody is allowing 100s of committers to push to master, that would be
>> silly.
>
> My personal preference is to not do that. I can't even cope with
> myself pushing to master from different repositories, let alone 100s
> of people. But I take it everyone else is indicating that would be the
> way forward.

I do not think this is on the table yet.

> I haven't mastered git enough to know the pros and cons, but you seem
> certain. Can you share your thoughts on the subject?

Well, PRs are a good way to discuss proposed patches, so you can take 
the discussion there. Particularly if the git hoster gives you all the 
web forum thingies you want, including the ability to be helpful with 
Markdown.
Also, a PR is easy to integrate once it's done.

So while the PR route is very, very unattractive if there's a readymade 
patch that you just need to integrate, it's a useful tool while the 
patch is being built, assuming the PR runs through a website that offers 
a discussion. It's just very slick if you don't have to quote some code 
just to say "I'd like to have xxx changed on line 512 of that patch", if 
you can simply point to the line of code and can say "I'd like to have 
xxx changed here". You can write annotations while you read - it does 
encourage write-before-you-think so it does have its downsides, but it 
is still a big timesaver because everybody is known to be in the same 
boat wrt. what line of code one is talking about.

Now that's the website side of things.
On the git side of things, you need to make sure that history isn't 
rewritten official branches such as master.
One way to achieve that is protecting those branches (that's the GitLab 
mechanism, GitHub implemented something similar last fall but I don't 
know if it's really the same); in that case people can still push to 
master without risking history.
The other would be setting up a clone and going through PRs even if you 
don't need a review. PRs do not really protect you against a history 
rewrite, they can still kill history - but you'll have to force-pull 
that so the people who do the pull will be alerted to potential damage.

On many projects, people still go through PRs even if they have direct 
write access. Simply to make sure that a second pair of eyes have looked 
at the code before it goes in.
It does require disciplined committers, so this does not work too well 
in practice. To make it fly, committers need to priorize reviewing over 
committing and keep that up; I do not know whether that's a viable 
policy for LLVM.
It does have its advantages if everybody knows his code will be 
eyeballed before it goes in though. But if it's a policy change for 
LLVM, this is something to consider for experimentation after the GH 
repo is set up, nothing that's up for decision right now.

> The main reason to move to GitHub/Lab is one of cost: storage,
> bandwidth and uptime, not one of tools.

For that, public git hosting services are a no-brainer.
You need to look at permissions because you can't simply set up 
gitolite, you have to live with whatever the service offers.

 > Even if we end up using the
> GitHub interface in the future, I think we should consider a less
> radical move first.

The opportunities will be there from day one.
Whether they are being used, or useful, is something to explore.

> Of course, if the problems of moving to git but still following our
> style becomes prohibitive, I think we should move to GitHub and use
> their style, as IMHO, the cost argument is stronger than the tooling.

The GitHub "flow" isn't the right one for every project, so the tooling 
does matter.