Renato, Let me be clear about my motivation on this particular question: I don’t like this variant, and I don’t want us to extra time discussing it at the BoF because we have enough things to go through. But that is only my personal opinion, and I avoid driving solely on my personal opinion, which is why this variant is present in the document. I believe data and facts are and the only way is to confirm whether or not it would actually be a waste of time to discuss it extensively at the BoF, so we *need* to ask about it. This is why, for the sake of “let’s optimize our limited time” at the BoF, I want to see this question in the survey. If the survey shows that a significant amount of people have interest in this variant, then we should allocate more time. For the exact same reason, this question is critical: 5. Please categorize how you interact with upstream. - I need read/write access, and I have limited disk space. - I need read/write access, but a 1GB clone doesn't scare me. - I only need read access. Yes, the survey is longer, folks will have a few more checkboxes to select, I’m perfectly fine with this if it may save 5-10 min of discussion at the BoF (Between 10% and 20% of our allocated time). — Mehdi PS: About your previous email, I think you are making a lot of claims that I believe are factually incorrect. But because you’re presenting this third variant as being proposed by a separate group, the so-called “monorepo group”, let me start by asking who answered "I personally feel two is minimum, three is good, four is too much.” when someone said "I want to put in my vote in favor of having a survey that takes into account multiple different approaches." (Answer: http://lists.llvm.org/pipermail/llvm-dev/2016-July/103059.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/103059.html> ) Then, we couldn’t converge on the monorepo, and this “third” proposal was a compromise to address the concerns of some folks. But guess who started the discussion about this variant? http://lists.llvm.org/pipermail/llvm-dev/2016-July/102667.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102667.html>> On Oct 13, 2016, at 3:16 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 13 October 2016 at 23:03, Mehdi Amini <mehdi.amini at apple.com> wrote: >> I don’t see how it is relevant, it is presented in the document, in its own section, just like the other variants. I don’t see any reason asking about it. > > The deal, from the beginning, was that we'd restrict ourselves to one > proposal, and make that count. It didn't work, so a second one was > created by a different group.“Different group” does not capture the overlap. You present it like two separate groups, which I believe is factually incorrect.> Both reviews happened in similar ways. Both sides started discussing, > then one side took over and the other gave up. Each part of the > document then became the point of view of a segregated group in our > community. > > The sub-modules group had initially many designs, but only one > survived.> It would be unfairI totally disagree with this statement.> if the mono-repo groupI don’t know who are you talking about, can you clarifying what is “the mono-repo group”? I believe this your own personal view, but .> had multiple > designs of their ownThis is another issue: this variant is *hybrid* and is not part of the monorepo. It is a separate proposal that is a compromise.> , because that dilutes the importance of the other > group's work.I don’t agree with this either. I don’t see the content of the document as here “to defend the work of any group”. This whole proposal, with the multiple variants, is a proposal for us as a community. So that we get the better. The monorepo proposal takes on many ideas developed by people who spent time brainstorming on the multi-repo, that does not make it the proposal of one group against the other.> > If you want to propose a third model, we'll have to do in the same > way: start over, with a new document, and discuss that.I’m not sure what’s missing in my previous emails: have you read the document?> > The discussion that happened in the second proposal doesn't count, > because the first group wasn't participating any more,This is again factually incorrect.> for the same > reasons that the second group didn't participate on the final steps of > the first proposal.This is also factually incorrect. — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/1576abee/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ToC.png Type: image/png Size: 124910 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/1576abee/attachment-0001.png>
Note: other than that the missing questions, I’m happy with the survey as is. When filling it, I hesitated if it would be better to split the question about multi/mono repo in different pages. But I don’t have any strong opinion about it. — Mehdi> On Oct 13, 2016, at 4:54 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Renato, > > Let me be clear about my motivation on this particular question: I don’t like this variant, and I don’t want us to extra time discussing it at the BoF because we have enough things to go through. > > But that is only my personal opinion, and I avoid driving solely on my personal opinion, which is why this variant is present in the document. > I believe data and facts are and the only way is to confirm whether or not it would actually be a waste of time to discuss it extensively at the BoF, so we *need* to ask about it. > > This is why, for the sake of “let’s optimize our limited time” at the BoF, I want to see this question in the survey. > If the survey shows that a significant amount of people have interest in this variant, then we should allocate more time. > > For the exact same reason, this question is critical: > > 5. Please categorize how you interact with upstream. > - I need read/write access, and I have limited disk space. > - I need read/write access, but a 1GB clone doesn't scare me. > - I only need read access. > > > Yes, the survey is longer, folks will have a few more checkboxes to select, I’m perfectly fine with this if it may save 5-10 min of discussion at the BoF (Between 10% and 20% of our allocated time). > > — > Mehdi > > > > PS: > > About your previous email, I think you are making a lot of claims that I believe are factually incorrect. > > But because you’re presenting this third variant as being proposed by a separate group, the so-called “monorepo group”, let me start by asking who answered "I personally feel two is minimum, three is good, four is too much.” when someone said "I want to put in my vote in favor of having a survey that takes into account multiple different approaches." > (Answer: http://lists.llvm.org/pipermail/llvm-dev/2016-July/103059.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/103059.html> ) > > Then, we couldn’t converge on the monorepo, and this “third” proposal was a compromise to address the concerns of some folks. > But guess who started the discussion about this variant? http://lists.llvm.org/pipermail/llvm-dev/2016-July/102667.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102667.html> > > >> On Oct 13, 2016, at 3:16 PM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: >> >> On 13 October 2016 at 23:03, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>> I don’t see how it is relevant, it is presented in the document, in its own section, just like the other variants. I don’t see any reason asking about it. >> >> The deal, from the beginning, was that we'd restrict ourselves to one >> proposal, and make that count. It didn't work, so a second one was >> created by a different group. > > “Different group” does not capture the overlap. You present it like two separate groups, which I believe is factually incorrect. > > >> Both reviews happened in similar ways. Both sides started discussing, >> then one side took over and the other gave up. Each part of the >> document then became the point of view of a segregated group in our >> community. >> >> The sub-modules group had initially many designs, but only one >> survived. > > >> It would be unfair > > I totally disagree with this statement. > > >> if the mono-repo group > > I don’t know who are you talking about, can you clarifying what is “the mono-repo group”? I believe this your own personal view, but . > > >> had multiple >> designs of their own > > This is another issue: this variant is *hybrid* and is not part of the monorepo. It is a separate proposal that is a compromise. > >> , because that dilutes the importance of the other >> group's work. > > I don’t agree with this either. > > I don’t see the content of the document as here “to defend the work of any group”. > This whole proposal, with the multiple variants, is a proposal for us as a community. So that we get the better. > > The monorepo proposal takes on many ideas developed by people who spent time brainstorming on the multi-repo, that does not make it the proposal of one group against the other. > > >> >> If you want to propose a third model, we'll have to do in the same >> way: start over, with a new document, and discuss that. > > I’m not sure what’s missing in my previous emails: have you read the document? > > <ToC.png> > > > >> >> The discussion that happened in the second proposal doesn't count, >> because the first group wasn't participating any more, > > This is again factually incorrect. > > >> for the same >> reasons that the second group didn't participate on the final steps of >> the first proposal. > > This is also factually incorrect. > > — > Mehdi >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/cbd8dc7b/attachment.html>
On 14 October 2016 at 00:56, Mehdi Amini <mehdi.amini at apple.com> wrote:> When filling it, I hesitated if it would be better to split the question > about multi/mono repo in different pages. But I don’t have any strong > opinion about it.I had the same hesitation, and I don't have a strong opinion either, but let together because they're largely similar and part of the same "group". Splitting also gets more confusing for people like me, that forgets what they're filling half-way through, and then answer the wrong question, because it's repetitive, and it's easier to spot. cheers, --renato