<div dir="ltr"><div dir="ltr"><div dir="ltr"> <br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 20, 2018 at 12:39 PM 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div></blockquote><div><br></div><div>Can't we / shouldn't we create decomposed repos by partitioning commits made to the monorepo into corresponding ones made to per-project repo "mirrors"?  Certainly if we can, we should.  Seems to me that even monorepo commits spanning projects could be broken down and applied to independent repos.  Perhaps it's slightly more interesting when top-level content starts to be more common, but an "llvm-top" or "llvm-general" individual repo seems feasible.  Even if they're not the canonical repos for submitting changes, it's still a valuable idea.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div></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></div></div></div></blockquote><div><br></div><div>Not sure which "users" we're referring to but if we're talking about ones who use only binaries provided by llvm project, they wouldn't necessarily have to know or care anything about git, svn, github, development trees, or anything else.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>...</div></div></div></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><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.<br></div><div><br></div></div></div></blockquote><div><br></div><div>The monorepo is flat, yes?  Is this satisfactory, or did I misunderstand your point?  Is this about the tree or the organization of the website (or development process)?  The website design could be very much orthogonal from the source control hierarchy.  <a href="http://clang.llvm.org/">http://clang.llvm.org/</a> shows a page describing the compiler.  Should <a href="http://clangd.llvm.org/">http://clangd.llvm.org/</a> be created to describe clangd?  Would that suffice?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div></div><div><b>...</b></div></div></div></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><b>What does the logical conclusion of this look like?</b><br></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></div></div></div></blockquote><div><br></div><div>I think it would've been nice if instead we could have gone with llvm-repo-composed-of-submodules, but it was proposed, discussed and several good reasons were given for why it wasn't preferred.  *shrug* better a consensus on the git monorepo than years more of svn IMO.</div></div></div></div></div>