[llvm-dev] Subprojects, GitHub, and the Monorepo

[Brian Cain via llvm-dev]

On Sat, Oct 20, 2018 at 12:39 PM Sam McCall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I work on clangd, the language server/IDE backend in clang/tools/extra.
> 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.
>
> And I think we should do much of this on GitHub, rather than *.llvm.org.
> And not in the upcoming monorepo, but in a separate repository. (e.g.
> github.com/llvm/clang)
>
>
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.



> 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.
>
> *Point 1: It's what people expect.*
> Everyone knows how to use the Github bug tracker, and has a Github account.
> Everyone knows markdown, how to edit-and-preview, and how to send a doc
> pull request.
> Everyone has these workflows in their muscle memory when a github project
> is the top websearch result.
> (Current LLVM developers *also* know the LLVM equivalents, but that's a
> small group).
> This is largely why we're moving the code to Github, too.
>
> *Point 2: exposing the LLVM monolith is bad for users.*
> Clangd's customers don't care about the structure of the LLVM umbrella
> project, or even that it exists.
> If they search for clangd on the web, they want to find a tree that looks
> like this:
>

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.


> ...
>



> 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.
>
>
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.  http://clang.llvm.org/ shows a page
describing the compiler.  Should http://clangd.llvm.org/ be created to
describe clangd?  Would that suffice?


> *...*
>



> *What does the logical conclusion of this look like?*
> 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.
> 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.
> Clangd is a pretty easy case, so I don't know if this makes it a good
> trial or a bad one.
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181020/86ad2bb2/attachment.html>