<div dir="ltr">There are already a lot of responses and I haven't read them all.<div><br></div><div>I just wanted to say that, if there is consensus among the clangd developers that this is what they want to do, they should feel empowered to do it. You are the ones best positioned to make the right decision for your project.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 20, 2018 at 10:39 AM Sam McCall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>I work on clangd, the language server/IDE backend in clang/tools/extra.<br></div><div>Clangd is at a stage where the core functionality is stable and useful enough that we want to put it front of more users. I've been spending time recently thinking about user-facing things: packaging, mailing lists, docs, bugtracking.</div><div><br></div><div>And I think we should do much of this on GitHub, rather than *.<a href="http://llvm.org" target="_blank">llvm.org</a>. And not in the upcoming monorepo, but in a separate repository. (e.g. <a href="http://github.com/llvm/clang" target="_blank">github.com/llvm/clang</a>)</div><div><br></div><div>I expect this to be controversial. It's definitely community fragmentation. I think the reasons to do it for clangd are strong, but they won't apply equally to all projects. And I'd like to know what people think. So here's my reasoning.</div><div><br></div><div><b>Point 1: It's what people expect.</b></div><div>Everyone knows how to use the Github bug tracker, and has a Github account.</div><div>Everyone knows markdown, how to edit-and-preview, and how to send a doc pull request.</div><div>Everyone has these workflows in their muscle memory when a github project is the top websearch result.</div><div>(Current LLVM developers *also* know the LLVM equivalents, but that's a small group).</div><div>This is largely why we're moving the code to Github, too.</div><div><br></div><div><b>Point 2: exposing the LLVM monolith is bad for users.</b></div><div>Clangd's customers don't care about the structure of the LLVM umbrella project, or even that it exists.</div><div>If they search for clangd on the web, they want to find a tree that looks like this:</div><div>clangd</div><div>- features</div><div>- installation</div><div>- bugs</div><div>- code</div><div>Not like this:</div><div><a href="http://llvm.org" target="_blank">llvm.org</a></div><div>- docs</div><div>-- lldb, etc</div><div>-- clang</div><div>--- features, etc</div><div>--- tools</div><div>---- clang-tidy, etc</div><div>---- clangd</div><div>----- features</div><div>----- installation</div><div>- bugs</div><div>-- lldb, etc</div><div>-- clang</div><div>--- tools</div><div>---- clang-tidy, etc</div><div>---- clangd</div><div>- code</div><div>-- lldb, etc</div><div>...</div><div>LLVM's source repository is monolithic for technical reasons (versioning), but we that's not a strong reason that the bug trackers, documentation etc should be monolithic. Spraying hyperlinks around won't fix the fact that the website is the wrong shape.</div><div><br></div><div><b>Point 3: the tools are just better.</b></div><div>I have nothing but respect and gratitude for the people that admin bugzilla, wrangle CMake and sphinx to generate docs, and keep mailman running. But unsurprisingly the state of the art has moved on, and the equivalents are in my experience easier to use, faster, and more reliable.</div><div>Symptoms of this are people routing around the tools: LLDB doesn't use sphinx for docs, sanitizers don't use bugzilla.</div><div>I'm sure there's going to be some agreement and disagreement on this point :-)</div><div><br></div><div><b>Point 4: but the tools are designed for smaller, focused repositories</b></div><div>The "github-native" community is mostly using fairly narrowly scoped repositories, and the tools work better this way. For example, labels are enough to organize issues in a project the size of clangd, but too lightweight if the scope is LLVM and all subprojects.</div><div><br></div><div><b>What does the logical conclusion of this look like?</b></div><div>I don't know. I suspect other subprojects in a similar boat may independently come to the same conclusion. Projects that have e.g. lots of bug history will need a migration story.</div><div>None of this mitigates the need for a source monorepo, so we'd be stuck with all the code in llvm/llvm and just issues/docs in llvm/clangd. Not ideal, but manageable.</div><div>Clangd is a pretty easy case, so I don't know if this makes it a good trial or a bad one.</div><div><br></div><div><*dons flame-retardant suit*></div><div>What do you all think?</div><div><br></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>