[PATCH] D24167: Moving to GitHub - Unified Proposal

[Justin Lebar via llvm-commits]

jlebar added a subscriber: jlebar.
jlebar added a comment.

> The idea being that it is *way* easier to write neutral documents that will allow people to form their own opinions if the documents don't refer to each other.


Wait a second.  We're choosing between two proposals.  The three of us here are among the experts.  We absolutely should be comparing the two proposals explicitly, to draw users' attentions to the differences that we think are important.  Because we actually know something that others don't!

I don't want a one-sided fight, where only the monorepo or multirepo cadre gets to have its say.  But if you believe that debate leads to better outcomes, then absolutely we should compare and advocate, which is just another way of explaining why, in our view, one proposal is better than the other.

>   I see us having four distinctly different documents.

> 

> (1) Git/GitHub proposal

>  (2) Mono-repo proposal

>  (3) Multi-repo proposal

>  (4) Proposal comparison


Can we just have these as separate sections in one document?  That's almost what we have here.

Four documents is a lot to ask people to read and understand.  At least with one, they can skip around, etc...  And it will also be easier to review and edit.

I think we could agree on a section that lays out the monorepo and multirepo proposals in a dry way, explaining what each looks like.  Then we could have the "why monorepo" and "why multirepo" sections.  Finally we could have the workflow comparison.

I also don't like the half-advocacy position taken in parts of this document, particularly "one or many repositories?"  When I revised Mehdi's proposal, I structured it more like you suggested, being explicit when we're advocating for one side or the other.


================
Comment at: docs/Proposals/GitHubMove.rst:148
@@ +147,3 @@
+..
+  TODO: Is this going to work when people push via the SVN bridge?
+
----------------
What's the resolution here?

================
Comment at: docs/Proposals/GitHubMove.rst:181
@@ +180,3 @@
+
+With the Monorepo, the existing read-only repositories (i.e. for example
+http://llvm.org/git/compiler-rt.git) with git-svn read-write access would be
----------------
Maybe we should call them "single-subproject mirrors" instead of "read-only repositories".

================
Comment at: docs/Proposals/GitHubMove.rst:182
@@ +181,3 @@
+With the Monorepo, the existing read-only repositories (i.e. for example
+http://llvm.org/git/compiler-rt.git) with git-svn read-write access would be
+maintained
----------------
would continue to be maintained

================
Comment at: docs/Proposals/GitHubMove.rst:183
@@ +182,3 @@
+http://llvm.org/git/compiler-rt.git) with git-svn read-write access would be
+maintained
+
----------------
I think we need to explain what this means, because this is critical for understanding the monorepo.

> Developers will continue to be able to use the existing single-subproject git repositories as they do today, with *no changes to workflow* beyond a one-time git-svn config change.  Everything (git fetch, git svn dcommit, etc.) would continue to work identically to how it works today.

================
Comment at: docs/Proposals/GitHubMove.rst:183
@@ +182,3 @@
+http://llvm.org/git/compiler-rt.git) with git-svn read-write access would be
+maintained
+
----------------
jlebar wrote:
> I think we need to explain what this means, because this is critical for understanding the monorepo.
> 
> > Developers will continue to be able to use the existing single-subproject git repositories as they do today, with *no changes to workflow* beyond a one-time git-svn config change.  Everything (git fetch, git svn dcommit, etc.) would continue to work identically to how it works today.
Missing period at end of sentence.

================
Comment at: docs/Proposals/GitHubMove.rst:185
@@ +184,3 @@
+
+There are other impacts that are less immediates and less technicals: the first
+proposal of keeping the repository separate implies that the sub-projects are
----------------
This segue does not make sense in context.

================
Comment at: docs/Proposals/GitHubMove.rst:199
@@ +198,3 @@
+as we wish. With the multirepo, moving clang-tools-extra into clang would be
+much more complicated, and might end up loosing history.
+
----------------
losing


https://reviews.llvm.org/D24167