[PATCH] D24167: Moving to GitHub - Unified Proposal

[Chris Bieneman via llvm-commits]

beanz added a comment.

In https://reviews.llvm.org/D24167#532327, @jlebar wrote:

> Wait a second.  We're choosing between two proposals.  The three of us here are among the experts.


Assuming that we're somehow experts on workflows above other contributors seems a bit presumptuous to me. Keep in mind the difference in the proposals isn't Git, so being a Git expert (which I'm certainly not) isn't really relevant. I'm not an expert on other people's workflows, so I would prefer if we approach this from a perspective of providing information and allowing people to form their own opinions.

> 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!


Really? No offense, but this comes off as incredibly condescending. You're asserting that you know better than everyone else. I'm not saying we shouldn't help people compare the proposals. I'm saying we shouldn't draw conclusions for them. Our community is filled with a lot of really smart people and I strongly believe they are capable of forming their own informed decisions.

> 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.


Debate is great. The LLVM.org documentation on the proposal isn't the place for it. Debate it at the social, debate it in your office, debate it on the lists and on IRC, debate it on your livejournal (I think that's still a thing right?). I believe the proposals should be neutral. I believe the documentation on LLVM.org should be position agnostic geared toward informing people without trying to directly influence them.

> 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 disagree. There are a number of advantages to multiple focused documents, and one of them is that they will be smaller and easier to review. Also shorter documents are generally easier to digest because you can pick one up and read it in a few minutes, and they provide break points.

> 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 would have no objection to this assuming that the two "why" sections and workflow comparisons are also neutrally written and avoid direct references to the other proposals.

In https://reviews.llvm.org/D24167#532395, @jlebar wrote:

> Could we just add a similar section advocating for the multirepo and be done here, move on with our lives?


No. I don't believe advocacy documents of this nature have any place on llvm.org. I know it isn't your intention, but your document as written is little better than propaganda. It is filled with half-truths, assertions that aren't backed by fact, and slanted language designed to influence the reader to your opinion. To provide some examples:

> SVN users would be more disrupted in the multirepo approach.


I disagree. I think that the mono-repo is more disruptive. But, that is my opinion, not backed by fact. You present this as a fact, and it is clearly a subjective opinion.

> Because all of our subprojects would live in a single repository, we could move code between them easily and without losing history.


This can actually be done with a multi-repo approach too using sub-tree merging. While it may not be as easy, it doesn't lose history.

> With the multirepo, moving clang-tools-extra into clang would be much more complicated, and might end up loosing history.


Same as above. You don't need to lose history to do this. Yes, it is more complicated, but it is a one-time cost.

Look, at the end of the day I care *way* more about how our community arrives at a decision rather than the specifics of the decision. I believe that are community is filled with intelligent people that are capable of drawing their own opinions, and that those opinions are equally or more valuable than my own. As a result I believe that the information we should be providing to the community for consideration of these proposals should be the best possible effort at being non-biased and impartial.

You may disagree with some or all of that, which is certainly your prerogative. What I'm trying to push for here is a framework for how to construct documents for these proposals that strive to be non-biased. Is it possible to write non-biased documents that refer to each other? Sure. Is it possible to write biased documents that *don't* directly refer to each other? Sure. My point is that it is *easier* to write non-biased documents if they don't directly relate themselves against their opposition.

-Chris


https://reviews.llvm.org/D24167