search for: k8stone

One more thing I want to note on this thread. For anyone looking at the patches. I’ve intentionally tried to make them minimal. After the patches have landed and stayed on trunk without issue for a while I’ll start doing cleanup around all the CMake version checks. I’d like to not open the flood gates on those kinds of cascading changes in case these patches need to be reverted for some reason.

Thanks, Chandler, for all your work on this. I’m glad to see this moving forward. -Jim > On Jun 30, 2016, at 11:55 AM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello folks, > > As mentioned some time ago[1], we’ve had a long (looooooong) series of discussions about establishing a code-of-conduct for the LLVM project as a whole over on the

> 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

Hello folks, As mentioned some time ago[1], we’ve had a long (looooooong) series of discussions about establishing a code-of-conduct for the LLVM project as a whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741 code review. The discussion has largely died down for some time, and towards the end there has been pretty wide support for the draft wording we have now. It isn’t

Folks, 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. TL;DR: GitHub + git submodules [1] could replace all the