<div dir="ltr"><div class="gmail_extra">Welcome back! ;]</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 10:13 AM, Reid Spencer <span dir="ltr"><<a href="mailto:reid@reactific.com" target="_blank">reid@reactific.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hello LLVMers,<div><br></div><div>It has been a while (8 years?) since I’ve been involved with LLVM but I’m considering picking it up again. My recent review of the code base has led me to wonder if it isn’t time to update the code base, specifically:</div><div><ul><li>Convert to GIT</li></ul></div></div></blockquote><div>I looked at this, and my conclusion was that it would provide essentially no benefit over svn + git mirrors + git-svn, while requiring *substantial* work to ensure we end up with a clean, linear master history. Within the community there has been long standing strong desire to continue to have linear master history. Things like push and merge make the incremental development and post-commit review process substantially harder.</div><div><br></div><div>In essence, git isn't a good fit for our desired master behavior, svn is, and it is sufficiently easy to *use* git while having an svn master.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><ul><li>Refactor into smaller, separate, reusable libraries</li></ul></div></div></blockquote><div>I think the libraries are already mostly reusable. Where they aren't, that should be fixed, but I think it is fine to fix these things somewhat lazily -- IE, when we have a re-use case in mind.</div><div><br></div><div>I think the "smaller" is mostly a function of re-use. There is a fairly natural factoring that results from this, and it doesn't make a lot of sense to me to split further.</div><div><br></div><div>I think making them *separate* is actually a mistake. I think it would add substantial complexity to the development process and slow the entire project down. While there are advantages to this, they don't really seem large enough to make it worth the cost.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><ul><li>Host the master repository at GitHub (amongst other places)</li></ul></div></div></blockquote><div>I'm not really opposed to this in any way other than the fact that git seems like a bad fit for the master.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div></div><div>My reasons for doing this don’t have to do with the code repository choice, but rather encouraging innovation. LLVM’s private and centralized repository is now hurting the project, I believe.</div></div></blockquote><div><br></div><div>What evidence do you see of this? Over the past 7 years, I have seen the community and project growing by pretty significant degrees. I don't think this kind of low-level structure is really a significant factor to limiting the project in any way.</div><div><br></div><div>My two cents are essentially: the VCS is not going to significantly impact the likelihood or effectiveness of people contributing. If they want to contribute, especially significantly over a long period of time, then they will steam roll right past this, much like they will other annoyances: build systems, compiling prerequisites, etc.</div><div><br></div><div>The point at which we should change is when we have a reasonable number of contributors all clamoring for a change with specific reasons why that change will help them be more productive / effective / etc. This is how we picked up CMake and now Ninja support for example.</div><div><br></div><div>-Chandler</div></div></div></div>