[PATCH] D24167: Moving to GitHub - Unified Proposal

Renato Golin via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 2 15:51:39 PDT 2016


rengolin added a comment.

Hi folks,

Deviating a bit from the conflict, I'd like to show how all of us agree on the same things basically...

In https://reviews.llvm.org/D24167#533142, @beanz wrote:

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


I agree with you, and I think that's what Justin was going for. I also see Mehdi's text as an attempt to do that, but it's hard to do it (I certainly can't) while we have an opinion (and we all have some).

So, the way I see it, we're arguing over specifics. There's no need.

I can see two ways this will go down without exploding again:

1. We "sanitise" the text from our biases the best we can and expect people to understand it. I'm not saying the intention was to be biased, just that humans bias. By having more points of view (this review is a good start), we "clean it up" a bit. Ie. we just continue doing this review as is, until everyone is happy "enough". (the quotes are important, as those words can have multiple meanings, and I mean the best of them). This will have the cost of re-reviewing what was agreed before (the sub-mod proposal), but we can make it simpler by having a clear table to workflow (as I proposed earlier) and a very short list of pros and cons (as was proposed on the list).

2. We do the original plan, to have two completely separate sections (on the same document). The sub-mod section copied (+ some workflow) from the other text, the mono-repo as a filter from this text. It'd still be good to have a table at the end, though. The additional cost is re-do a lot of what Mehdi has done, but the benefit is that people that spent time discussing the other proposal won't have to do the whole thing again here.

I don't mind either way, but would be good to pick one and stick with it.

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


I agree this has to be avoided, no matter how we organise the document. Justin's point that "this is a comparison" is very fair, but IIGIR, Chris' point was surrounding "bias comparison" (ex. "A is more complicated than B").

Workflows are all different, and people find different things complicated. Let's just lay out the independent facts about each one, even if the text becomes a bit brittle, and let people do their own comparisons.

> I don't believe advocacy documents of this nature have any place on llvm.org.


So, removing all feelings around the phrase and the moment, I think there's a lot of meaning in this statement.

The OSS LLVM community has prided in not pushing an agenda towards anyone. The individual contributions (company or personal) do have agendas, and they're synced upstream, and the discussions are massively technical in nature. There is obviously a power play, as in any other community (OSS or not), but here, we have always valued technical arguments over everything else.

The GitHub problem is a technical one, but also a personal one. Technical problems, with technical solutions, but very rooted on how companies and individuals develop, validate and deliver their products. It's very easy to let our biases of "this is much easier than that" unintentionally blind us, and we have to be careful.

The first rule of thumb is to not assume, for any reason, that we're experts. Most people in our community could have been doing the job of investigating this issue, but they're not. That's not to say that whatever opinion *we* reach will be the best, just that whatever we present has to be clear, concise and technically accurate, so *they* can take their own decisions.

We're not here to decide what's best, but to digest and present the information in the simplest form possible, so everyone can decide what's best for themselves.

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


This is a very good example why we can't use biased comparison like "A would be more disruptive than B". This is a personal opinion, not an invariant fact to all members of our community. We should not have any of that on this document, or people will not take it seriously and we won't have the effect we want.

I'm not pointing fingers or trying to start a fight, I'm just making clear that this discussion cannot happen in the text.

We need simplicity and clarity. Despite our best efforts, this text is not there yet, and it's no one's fault. I think Mehdi, Justin and Chris have done a remarkable job at collating and discussing all the facts, and I think a lot of people in the community *really* appreciate it. I certainly do.

But now it's time to stop discussing how the *best* workflow looks like, and start clearing up the proposal.

In my personal view, Mehdi's description and workflow examples are great. We just need to validate the sub-module part with the previous proposal, and work on the formatting.

cheers,
-renato


================
Comment at: docs/Proposals/GitHubMove.rst:617
@@ +616,3 @@
+the pieces needed for a full toolchain present in one repository. And for
+newcomers, getting and building a toolchain is easier.
+
----------------
mehdi_amini wrote:
> rengolin wrote:
> > That work flow example shows a changed flow for commits, so the statement that "their workflow is unchanged" is not accurate. 
> > 
> > The parentheses comment helps, but doesn't address the issue completely. A better way would be "the workflow is as described in [link] pointing above. 
> I'm sorry I don't follow. You mention a changed in the flow for commit. Here is what's mentioned in the section I referred to, can you clarify where is the inaccuracy?
> 
> Workflow today:
> 
> ```
>   # direct SVN checkout
>   svn co https://user@llvm.org/svn/llvm-project/llvm/trunk llvm
>   # or using the read-only Git view, with git-svn
>   git clone http://llvm.org/git/llvm.git
>   cd llvm
>   git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=<username>
>   git config svn-remote.svn.fetch :refs/remotes/origin/master
>   git svn rebase -l  # -l avoids fetching ahead of the git mirror.
> ```
> 
> Workflow after (copy/paste):
> 
> ```
> A second option is to use svn via the GitHub svn native bridge::
> 
>   svn co https://github.com/llvm/llvm-projects/trunk/compiler-rt compiler-rt  —username=...
> 
> This checks out only compiler-rt and provides commit access using "svn commit",
> in the same way as it would do today.
> 
> Finally, you could use *git-svn* and one of the sub-project mirrors::
> 
>   # Clone from the single read-only Git repo
>   git clone http://llvm.org/git/llvm.git
>   cd llvm
>   # Configure the SVN remote and initialize the svn metadata
>   git svn init https://github.com/joker-eph/llvm-project/trunk/llvm —username=...
>   git config svn-remote.svn.fetch :refs/remotes/origin/master
>   git svn rebase -l
> 
> 
> In this case the repository contains only a single sub-project, and commits can
> be made using `git svn dcommit`, again **exactly as we do today**.
> ```
> 
This is how it would work on a multi-repo, but this section is talking about the mono-repo.

IIGIR, on a mono-repo, developers of a single component will have to commit back on the mono-repo, which will then be propagated to the individual (read-only) repos, no?


https://reviews.llvm.org/D24167





More information about the llvm-commits mailing list