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

[Renato Golin via llvm-dev]

Kristof, Chandler,

I think most of the responses seem favourable of the move, the
concerns being which Git repo we'll use (GitHub, GitLab, BitBucket),
but they're essentially identical on the git side.

Infrastructure decisions will need to be taken into account, but that
doesn't interfere with the "how we commit" discussion in any way.


On 25 February 2016 at 08:55, Kristof Beyls via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I'm afraid I've never committed to any github project before, so I am a bit
> confused on how committing would work in practice.

GitHub (and others) work by fork&pull-request. Simply put, you fork
the original repo, do your changes, push to your repo and make a
"pull-request" to the original repo. The added work is that one of the
original repo owners will have to "accept" your pull-request, and
GitHub then merges your changes.

One of the design decisions of working this way is to have less
committers on the main repo, and everyone else works on their own.
This is great for collaborative development, but not very similar of
the way we work.

I believe all those services use something similar to git-new-workdir,
so even if we have 100 forks of the test-suite, we won't have 100 x
1GB of used space. But if we move into a "less owners" scenario, we
will penalise them with pull-requests all the time. Having said that,
if we have enough, and if they, too, follow the fork & pull-request
model, I think it could work.


> Obviously, I hope for the mechanism to commit to be simple - e.g. just do a
> git push from the command line.

This is a little more complex. SVN is very conservative on history,
and that saves us from destroying the origin. Git, on the other hand,
allows anyone with write access to completely wipe out the repo. I
don't think anyone would want to, but accidents do happen in git.

As was said earlier, "git doesn't destroy data" in the sense that
anyone with a good tree can re-make the origin, or even for a limited
time (while commits are still in cache), you can cherry-pick them back
and remake the tree. But buildbots will NOT be happy with broken
trees. With new committers coming all the time, it's hard to control
how much people know about git and GitHub (et al), so accidents are
bound to happen more often than they should.

The other problem is about release validation. We'll need to do
separate "releases" of the test-suite for each LLVM release, since we
can't run old tests with new releases and vice versa.

Another way to work with git is like the Linux kernel, where different
maintainers have different trees and they all merge from each other. I
personally think that would be a nightmare for us.

If anyone with more git experience than me can come up with a safe way
to have 100s of committers pushing to master, I'd be happy to know.

cheers,
--renato