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

[Mehdi Amini via llvm-dev]

> On Feb 25, 2016, at 3:33 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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.

GitHub offers  a simple *raw* git hosting. All the fork&pull-request is sugar in the web interface. You don't *have to* use it.


> 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.

We don't *have to* work this way on GitHub, you can allow "everyone" to commit (by asking to be added to the committer list just the same way we do it with the current svn servers).
I.e. it is possible to move to GitHub and *not* change our current workflow.

> 
> 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.

This is why git has "hooks": for example https://gist.github.com/stefansundin/d465f1e331fc5c632088

You can prevent from rewriting the history on the server side, which eliminate risk of "accidents". (You can have a whitelist of people allowed to rewrite the history...).


> 
> 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.

Not sure how this part relates to git/github/svn?

-- 
Mehdi


> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev