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

[Renato Golin via llvm-dev]

On 25 February 2016 at 12:46, Joachim Durchholz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I'm repeating myself but not they are not identical on the git side. Not for
> people without push access to the main repo anyway.

We're talking about the people with commit access to the main repo. No
commit access still needs someone with commit access to push/merge.


> Regular committers with write access to repositories have a different
> workflow than occasional contributors who send patches or pull requests.
> You need to consider all values of "we" that you are interested in getting
> work from.

Practically, if we don't want to change *anything*, non-committers can
have the same process they have today when submitting patches.

GitHub/Lab will just be yet another source repository.


> GitHub explicitly confirms that "forking" (remotely cloning) a repo does not
> copy the data.

Though so.


> What workflow are you comparing this to, if a pull request is a penalty?

Today, 100s of people commit directly. In a GitHub style, 100s of
people will have to wait for a merge from a few folks. 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.


> 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 haven't mastered git enough to know the pros and cons, but you seem
certain. Can you share your thoughts on the subject?


> You push to either a remote clone (GitHub) or a remote branch (GitLab), and
> the master's owner does the merge. These are essentially an alternative to
> sending patches by mail, with the added bonus that the Git* websites give
> you a forum website where you can open threads on individual lines of code,
> including an email gateway.

I think we all know the benefits of using GitHub/Lab, but we already
have Phabricator that does a similar way and kind of cope with it
being on a separate repository. Some people love Phab and Arc, I don't
particularly like it myself and do prefer the GitHub style, but I'm
just one guy.

The main reason to move to GitHub/Lab is one of cost: storage,
bandwidth and uptime, not one of tools. Even if we end up using the
GitHub interface in the future, I think we should consider a less
radical move first.

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.

cheers,
--renato