> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev > <llvm-...@lists.llvm.org> wrote: > >> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev >> <llvm-...@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-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
