[llvm-dev] GitHub anyone?

[Mehdi Amini via llvm-dev]

> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> There has been some discussion on IRC about SVN hosting and the perils
>> of doing it ourselves. The consensus on the current discussion was
>> that moving to a Git-only solution would have some disvantages, but
>> many advantages. Furthermore, not hosting our own repos would save us
>> a lot of headaches, admin costs and timed out connections.
> 
> Personally, I’m hugely in favor of moving llvm’s source hosting to github at some point, despite the fact that I continue to dislike git as a tool and consider monotonicly increasing version numbers to be hugely beneficial.

Getting a monotonically increasing revision number seems doable in git with some server-side scripting using git notes or named tags (yet to be seen is how to achieve it *reliably* with github hosting).
However the challenge is more about sharing this number across repositories (i.e. having clang and llvm in sync). I can imagine some tooling for that, but with a github hosting it may still be fragile.

Ideally, I'd prefer the cross-repository to be handled with an extra layer, in a way similar as described in: https://gerrit-review.googlesource.com/Documentation/user-submodules.htm (somehow conceptually similar to Android manifests XML files). 
It would be easy to have tooling/scripts for llvm that would easily say "checkout llvm+clang+compiler-rt+libcxx+clang-extra here", or "update all llvm subproject under this root", or "checkout this specific revision for all these" (with a monotonic number for the revision).

(+1 to all the rest of what you wrote)

-- 
Mehdi


> The killer feature to me is the community aspects of github, allowing people to get involved in the project more easily and make “drive by” contributions through the pull request model.  Github also has a very scriptable interface, allowing integration of external bug trackers etc into the workflow (which is good, because its bugtracker is anemic).
> 
>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>> etc. Not only this incurs in additional admin cost, but it also gets
>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>> gives all that for us for free.
> 
> Yes, it would be great to get out of this business.
> 
>> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
>> we can also use GitHub's system to manage releases (it's actually
>> quite good for that).
> 
> If we made this change, I think we should only change one thing at a time: change source hosting, but not phabricator or the bug tracker.  We could then discuss moving off phabricator to the github PR model, etc.
> 
>> 6. GitHub has automated testing of merge requests, meaning we can have
>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>> own validation hooks.
> 
> This works pretty well.  The major problem is with tests that are flakey.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev