> On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Folks, > > After feedback from Chris and Mehdi, I have added one long text answer > to *each* critical questions (impact on productivity), so that people > can extend their reasoning. > > But I have not made them compulsory, so that people that don't know > much about or don't have any problem don't feel compelled to expand on > nothing. > > https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform > > The bottom line is, answers with more substance will be taken more > seriously than those without, but the numbers should also tell us > something. > > For example, if 9/10 of the answers are "we don't care", than the > other 1/10 will have less weight than if it was 1/2, but still > important to any decision. > > Can we go live with what we have now? > > Mehdi, how's the document? Can we get that online so I can change the > header of the survey?Hi Renato, Thanks very much for putting this together. I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on. The survey is a great start, but the final page isn't quite addressing the concerns in the final proposal. I'm not sure it asks the right questions to focus the conversation at the BoF. Firstly, I'm concerned that the questions focus on: - what's good for the individuals responding, instead of what they think is best for the LLVM project; and - how much pain the transition would cause, instead of what they think the right final state is. Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. I spent some time today thinking through what set of questions would get us the data we want. - I've focused on the main concerns about (and benefits of) the two variants. - I've referred to the multirepo and monorepo by name (consistently) in questions asking about them. This ensures that people know exactly what they're answering. - I've added specific questions about how people plan to use the multirepo and monorepo, so that we know which tooling is most important (and also to determine how worried we should be about some of the concerns). - I've moved the "vote"-like question to the end to force respondents to think through the issues first. I've also restricted "the vote" to "the ideal project setup", so we can clearly separate that from "transition pain". (I'm still not sure the vote will have much value, but it doesn't hurt.) Here are my suggested questions; feedback welcome: ---- 1. How do you use LLVM? // as is 2. Which projects do you contribute to / use? // as is 3. Use this field to expand on your usage, if necessary // as is 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? - Always. - Most of the time. - Sometimes. - Never. 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. 6. How important is cross-project blame, grep, etc.? - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. - Extremely. It should be easy enough that everyone does it by default. - Somewhat. I would use it if it were easy, but it's just nice to have. - Not at all. Anyone who cares can write their own tooling. 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. - Extremely. It should be easy enough that everyone does it by default. - Somewhat. I would use it if it were easy, but it's just nice to have. - Not at all. Anyone who cares can write their own tooling. 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? // checkboxes: + Actively contribute tooling improvements to improve it. + Integrate it into our downstream fork. + Use it for upstream contributions. + Use it as the primary interface development environment. + Use it for bisection. 9. If multirepo is adopted, how do you plan to contribute to upstream? - Using Git submodules. - Using the Git repos directly. - Using the SVN bridges. - n/a: I don't contribute. 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? - I'll use the monorepo as soon as it's possible, even before it's canonical. - I'll use the monorepo as soon as it's canonical. - I'll transition to monorepo eventually. - I'll use the SVN bridge on separated sub-projects forever. - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. - n/a: I don't contribute. 11. If monorepo is adopted, how do you plan to integrate it downstream? - We already use monorepo. - We'll switch to pulling from monorepo during the transition period. - We'll switch to pulling from monorepo eventually. - We'll integrate from the SVN bridge forever. - We'll integrate from the split sub-project Git mirror forever. - n/a: There is no downstream. 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? - This is great. Native cross-project refactoring, without penalizing runtime-only developers. - Whatever. I'll deal with it. - This is terrible. All the transition pain of monorepo, without the advantages. 13. If multirepo is adopted, how much pain will there be in your transition? - Nothing consequential. - A little; but it'll be fine. - A lot; but it'll get done somehow. - Too much; I/we may stop contributing to LLVM. 14. If monorepo is adopted, how much pain will there be in your transition? - Nothing consequential. - A little; but it'll be fine. - A lot; but it'll get done somehow. - Too much; I/we may stop contributing to LLVM. 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? - CVS. - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. - Subversion repository as a single project (trunk/<sub-project>), with git-svn. - Git: multirepo variant. - Git: monorepo variant. - Git: multi/mono hybrid variant. - Other. 16. Other comments. // Open text field. ---- Thanks again for your hard work on this! Duncan P.S. I think there's a bug on in the survey (or maybe my browser). I'm seeing some stray "If responding for a" text at the top. See the PDF I've attached here. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-10-12 at 16.16.05.png.pdf Type: application/pdf Size: 61771 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/56e72377/attachment-0001.pdf> -------------- next part --------------> > We only have a month and a bit now... > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
| 6. How important is cross-project blame, grep, etc.? I don't understand "cross-project blame" as it works on one file at a time? Also, is this question intended to cover bisection? Thanks, --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Duncan P. N. Exon Smith via llvm-dev Sent: Wednesday, October 12, 2016 7:07 PM To: Renato Golin Cc: LLVM Dev; Tanya Lattner Subject: Re: [llvm-dev] GitHub Survey?> On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > > Folks, > > After feedback from Chris and Mehdi, I have added one long text answer > to *each* critical questions (impact on productivity), so that people > can extend their reasoning. > > But I have not made them compulsory, so that people that don't know > much about or don't have any problem don't feel compelled to expand on > nothing. > > https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform > > The bottom line is, answers with more substance will be taken more > seriously than those without, but the numbers should also tell us > something. > > For example, if 9/10 of the answers are "we don't care", than the > other 1/10 will have less weight than if it was 1/2, but still > important to any decision. > > Can we go live with what we have now? > > Mehdi, how's the document? Can we get that online so I can change the > header of the survey?Hi Renato, Thanks very much for putting this together. I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on. The survey is a great start, but the final page isn't quite addressing the concerns in the final proposal. I'm not sure it asks the right questions to focus the conversation at the BoF. Firstly, I'm concerned that the questions focus on: - what's good for the individuals responding, instead of what they think is best for the LLVM project; and - how much pain the transition would cause, instead of what they think the right final state is. Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. I spent some time today thinking through what set of questions would get us the data we want. - I've focused on the main concerns about (and benefits of) the two variants. - I've referred to the multirepo and monorepo by name (consistently) in questions asking about them. This ensures that people know exactly what they're answering. - I've added specific questions about how people plan to use the multirepo and monorepo, so that we know which tooling is most important (and also to determine how worried we should be about some of the concerns). - I've moved the "vote"-like question to the end to force respondents to think through the issues first. I've also restricted "the vote" to "the ideal project setup", so we can clearly separate that from "transition pain". (I'm still not sure the vote will have much value, but it doesn't hurt.) Here are my suggested questions; feedback welcome: ---- 1. How do you use LLVM? // as is 2. Which projects do you contribute to / use? // as is 3. Use this field to expand on your usage, if necessary // as is 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? - Always. - Most of the time. - Sometimes. - Never. 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. 6. How important is cross-project blame, grep, etc.? - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. - Extremely. It should be easy enough that everyone does it by default. - Somewhat. I would use it if it were easy, but it's just nice to have. - Not at all. Anyone who cares can write their own tooling. 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. - Extremely. It should be easy enough that everyone does it by default. - Somewhat. I would use it if it were easy, but it's just nice to have. - Not at all. Anyone who cares can write their own tooling. 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? // checkboxes: + Actively contribute tooling improvements to improve it. + Integrate it into our downstream fork. + Use it for upstream contributions. + Use it as the primary interface development environment. + Use it for bisection. 9. If multirepo is adopted, how do you plan to contribute to upstream? - Using Git submodules. - Using the Git repos directly. - Using the SVN bridges. - n/a: I don't contribute. 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? - I'll use the monorepo as soon as it's possible, even before it's canonical. - I'll use the monorepo as soon as it's canonical. - I'll transition to monorepo eventually. - I'll use the SVN bridge on separated sub-projects forever. - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. - n/a: I don't contribute. 11. If monorepo is adopted, how do you plan to integrate it downstream? - We already use monorepo. - We'll switch to pulling from monorepo during the transition period. - We'll switch to pulling from monorepo eventually. - We'll integrate from the SVN bridge forever. - We'll integrate from the split sub-project Git mirror forever. - n/a: There is no downstream. 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? - This is great. Native cross-project refactoring, without penalizing runtime-only developers. - Whatever. I'll deal with it. - This is terrible. All the transition pain of monorepo, without the advantages. 13. If multirepo is adopted, how much pain will there be in your transition? - Nothing consequential. - A little; but it'll be fine. - A lot; but it'll get done somehow. - Too much; I/we may stop contributing to LLVM. 14. If monorepo is adopted, how much pain will there be in your transition? - Nothing consequential. - A little; but it'll be fine. - A lot; but it'll get done somehow. - Too much; I/we may stop contributing to LLVM. 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? - CVS. - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. - Subversion repository as a single project (trunk/<sub-project>), with git-svn. - Git: multirepo variant. - Git: monorepo variant. - Git: multi/mono hybrid variant. - Other. 16. Other comments. // Open text field. ---- Thanks again for your hard work on this! Duncan P.S. I think there's a bug on in the survey (or maybe my browser). I'm seeing some stray "If responding for a" text at the top. See the PDF I've attached here.> > We only have a month and a bit now... > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev_______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/fa382c48/attachment-0001.html>
> On Oct 13, 2016, at 11:03 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > | 6. How important is cross-project blame, grep, etc.? > <> > I don't understand "cross-project blame" as it works on one file at a time?True, not straightforward blame. My workflow when trying to track the history of some code involves frequently blaming recursively. When I reach a commit that moved the function, I switch file, but continue *from the same commit*. This is only possible in the same repository. Another thing I use daily is finding “when was this added”, using git “pickaxe” (git log S ….). Which again works only inside a repository.> Also, is this question intended to cover bisection? > Thanks, > --paulr > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Duncan P. N. Exon Smith via llvm-dev > Sent: Wednesday, October 12, 2016 7:07 PM > To: Renato Golin > Cc: LLVM Dev; Tanya Lattner > Subject: Re: [llvm-dev] GitHub Survey? > > > > On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > Folks, > > > > After feedback from Chris and Mehdi, I have added one long text answer > > to *each* critical questions (impact on productivity), so that people > > can extend their reasoning. > > > > But I have not made them compulsory, so that people that don't know > > much about or don't have any problem don't feel compelled to expand on > > nothing. > > > > https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform <https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform> > > > > The bottom line is, answers with more substance will be taken more > > seriously than those without, but the numbers should also tell us > > something. > > > > For example, if 9/10 of the answers are "we don't care", than the > > other 1/10 will have less weight than if it was 1/2, but still > > important to any decision. > > > > Can we go live with what we have now? > > > > Mehdi, how's the document? Can we get that online so I can change the > > header of the survey? > > Hi Renato, > > Thanks very much for putting this together. > > I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on. > > The survey is a great start, but the final page isn't quite addressing the concerns in the final proposal. I'm not sure it asks the right questions to focus the conversation at the BoF. > > Firstly, I'm concerned that the questions focus on: > - what's good for the individuals responding, instead of what they think is best for the LLVM project; and > - how much pain the transition would cause, instead of what they think the right final state is. > > Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. > > Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. > > I spent some time today thinking through what set of questions would get us the data we want. > - I've focused on the main concerns about (and benefits of) the two variants. > - I've referred to the multirepo and monorepo by name (consistently) in questions asking about them. This ensures that people know exactly what they're answering. > - I've added specific questions about how people plan to use the multirepo and monorepo, so that we know which tooling is most important (and also to determine how worried we should be about some of the concerns). > - I've moved the "vote"-like question to the end to force respondents to think through the issues first. I've also restricted "the vote" to "the ideal project setup", so we can clearly separate that from "transition pain". (I'm still not sure the vote will have much value, but it doesn't hurt.) > > Here are my suggested questions; feedback welcome: > > ---- > > 1. How do you use LLVM? > // as is > > 2. Which projects do you contribute to / use? > // as is > > 3. Use this field to expand on your usage, if necessary > // as is > > 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? > - Always. > - Most of the time. > - Sometimes. > - Never. > > 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. > > 6. How important is cross-project blame, grep, etc.? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling. > > 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling. > > 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? > // checkboxes: > + Actively contribute tooling improvements to improve it. > + Integrate it into our downstream fork. > + Use it for upstream contributions. > + Use it as the primary interface development environment. > + Use it for bisection. > > 9. If multirepo is adopted, how do you plan to contribute to upstream? > - Using Git submodules. > - Using the Git repos directly. > - Using the SVN bridges. > - n/a: I don't contribute. > > 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? > - I'll use the monorepo as soon as it's possible, even before it's canonical. > - I'll use the monorepo as soon as it's canonical. > - I'll transition to monorepo eventually. > - I'll use the SVN bridge on separated sub-projects forever. > - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. > - n/a: I don't contribute. > > 11. If monorepo is adopted, how do you plan to integrate it downstream? > - We already use monorepo. > - We'll switch to pulling from monorepo during the transition period. > - We'll switch to pulling from monorepo eventually. > - We'll integrate from the SVN bridge forever. > - We'll integrate from the split sub-project Git mirror forever. > - n/a: There is no downstream. > > 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? > - This is great. Native cross-project refactoring, without penalizing runtime-only developers. > - Whatever. I'll deal with it. > - This is terrible. All the transition pain of monorepo, without the advantages. > > 13. If multirepo is adopted, how much pain will there be in your transition? > - Nothing consequential. > - A little; but it'll be fine. > - A lot; but it'll get done somehow. > - Too much; I/we may stop contributing to LLVM. > > 14. If monorepo is adopted, how much pain will there be in your transition? > - Nothing consequential. > - A little; but it'll be fine. > - A lot; but it'll get done somehow. > - Too much; I/we may stop contributing to LLVM. > > 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? > - CVS. > - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. > - Subversion repository as a single project (trunk/<sub-project>), with git-svn. > - Git: multirepo variant. > - Git: monorepo variant. > - Git: multi/mono hybrid variant. > - Other. > > 16. Other comments. > // Open text field. > > ---- > > Thanks again for your hard work on this! > > Duncan > > P.S. I think there's a bug on in the survey (or maybe my browser). I'm seeing some stray "If responding for a" text at the top. See the PDF I've attached here. > > > > > We only have a month and a bit now... > > > > cheers, > > --renato > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>_______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/1218ebb0/attachment.html>
Hi, Thanks a lot Duncan, I really like this! I totally support adopting this scheme now. See inline a few quite minor comments. Renato: are you still interested and available now to set-up the survey? We should close on this *this week*.> On Oct 12, 2016, at 7:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Folks, >> >> After feedback from Chris and Mehdi, I have added one long text answer >> to *each* critical questions (impact on productivity), so that people >> can extend their reasoning. >> >> But I have not made them compulsory, so that people that don't know >> much about or don't have any problem don't feel compelled to expand on >> nothing. >> >> https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform >> >> The bottom line is, answers with more substance will be taken more >> seriously than those without, but the numbers should also tell us >> something. >> >> For example, if 9/10 of the answers are "we don't care", than the >> other 1/10 will have less weight than if it was 1/2, but still >> important to any decision. >> >> Can we go live with what we have now? >> >> Mehdi, how's the document? Can we get that online so I can change the >> header of the survey? > > Hi Renato, > > Thanks very much for putting this together. > > I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on. > > The survey is a great start, but the final page isn't quite addressing the concerns in the final proposal. I'm not sure it asks the right questions to focus the conversation at the BoF. > > Firstly, I'm concerned that the questions focus on: > - what's good for the individuals responding, instead of what they think is best for the LLVM project; and > - how much pain the transition would cause, instead of what they think the right final state is. > > Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. > > Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. > > I spent some time today thinking through what set of questions would get us the data we want. > - I've focused on the main concerns about (and benefits of) the two variants. > - I've referred to the multirepo and monorepo by name (consistently) in questions asking about them. This ensures that people know exactly what they're answering. > - I've added specific questions about how people plan to use the multirepo and monorepo, so that we know which tooling is most important (and also to determine how worried we should be about some of the concerns). > - I've moved the "vote"-like question to the end to force respondents to think through the issues first. I've also restricted "the vote" to "the ideal project setup", so we can clearly separate that from "transition pain". (I'm still not sure the vote will have much value, but it doesn't hurt.) > > Here are my suggested questions; feedback welcome: > > ---- > > 1. How do you use LLVM? > // as is > > 2. Which projects do you contribute to / use? > // as isFor this last question, I’d keep a check-boxes list with an optional blank field. It seems that the list of projects being limited, checking boxes is both easier for the people answering and for us doing the data-mining. (What Renato has set-up looks good to me here)> > 3. Use this field to expand on your usage, if necessary > // as is > > 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? > - Always. > - Most of the time. > - Sometimes. > - Never. > > 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. > > 6. How important is cross-project blame, grep, etc.? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling. > > 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling. > > 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? > // checkboxes: > + Actively contribute tooling improvements to improve it. > + Integrate it into our downstream fork. > + Use it for upstream contributions. > + Use it as the primary interface development environment. > + Use it for bisection. > > 9. If multirepo is adopted, how do you plan to contribute to upstream? > - Using Git submodules. > - Using the Git repos directly. > - Using the SVN bridges. > - n/a: I don't contribute.Can you clarify what “Using Git submodules” mean? Since the umbrella is read-only, it is not clear to me. Removing this first answer and keeping the others makes sense to me on the other hand.> > 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? > - I'll use the monorepo as soon as it's possible, even before it's canonical. > - I'll use the monorepo as soon as it's canonical. > - I'll transition to monorepo eventually. > - I'll use the SVN bridge on separated sub-projects forever. > - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. > - n/a: I don't contribute. > > 11. If monorepo is adopted, how do you plan to integrate it downstream? > - We already use monorepo. > - We'll switch to pulling from monorepo during the transition period. > - We'll switch to pulling from monorepo eventually. > - We'll integrate from the SVN bridge forever. > - We'll integrate from the split sub-project Git mirror forever. > - n/a: There is no downstream. > > 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? > - This is great. Native cross-project refactoring, without penalizing runtime-only developers. > - Whatever. I'll deal with it. > - This is terrible. All the transition pain of monorepo, without the advantages. > > 13. If multirepo is adopted, how much pain will there be in your transition? > - Nothing consequential. > - A little; but it'll be fine. > - A lot; but it'll get done somehow. > - Too much; I/we may stop contributing to LLVM. > > 14. If monorepo is adopted, how much pain will there be in your transition? > - Nothing consequential. > - A little; but it'll be fine. > - A lot; but it'll get done somehow. > - Too much; I/we may stop contributing to LLVM.For the two previous question, I’d add an answer “n/a: I don’t contribute”. (We keep readonly views in both cases, not clear to me how it affects non-contributors). — Mehdi> > 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? > - CVS. > - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. > - Subversion repository as a single project (trunk/<sub-project>), with git-svn. > - Git: multirepo variant. > - Git: monorepo variant. > - Git: multi/mono hybrid variant. > - Other. > > 16. Other comments. > // Open text field. > > ---- > > Thanks again for your hard work on this! > > Duncan > > P.S. I think there's a bug on in the survey (or maybe my browser). I'm seeing some stray "If responding for a" text at the top. See the PDF I've attached here. > > <Screen Shot 2016-10-12 at 16.16.05.png.pdf> >> >> >> We only have a month and a bit now... >> >> cheers, >> --renato >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/1aab216a/attachment-0001.html>
Hi Duncan, I don't understand your concerns. First, the choice between sub-modules and mono-repo has been put forward as the only two choices because people felt that, if we let it open, we'd have too many different implementation details and we'd never get anywhere. So...> - how much pain the transition would cause, instead of what they think the right final state is.The final state is defined by submod vs. monorepo, and that's represented in a different question. Those questions are addressing the additional work done to get there, as many have said would be the crucial decision point. It also outlines the cost over their preferred vs non-preferred solutions, which leads to the aggregated cost over the whole project for each decision.> - what's good for the individuals responding, instead of what they think is best for the LLVM project; andThat's implied. I think it is clear enough, but we can always change the wording if others feel confused.> Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document.It is a vote. The "thinking" is on the extended answer that follows. Answers with good extended reasoning will have a greater weight than those without. If you're worried about data mining, than leaving those questions to full text answers will require someone to read it all, interpret, and put their bias on top. Given the nature of this problem, we should avoid bias whenever possible, especially when interpreting the answers.> Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion.I see your point. We can re-word to make that more clear.> 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? > - Always. > - Most of the time. > - Sometimes. > - Never.Interesting, it covers the main problem with both proposals.> 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.I'm not sure that's critical. My current source repo has 35GB with just a few worktrees. Also, both solutions have low-disk-usage modes, and this would make no difference on how we proceed.> 6. How important is cross-project blame, grep, etc.? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling.Based on other comments in the thread, we should leave this one out.> 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling.I don't like to assert my opinion and then ask how much people agree. I prefer to ask the question directly, like: How often do you need to commit across repositories (ex. llvm+clang) and how often are your builds broken because they're in separate repositories? Also, I think your scale of important is somewhat skewed up. Vital and Extremely are at the top, somewhat is right bang in the middle and not at all is the very bottom. You either have two positive and two negative (very, somewhat, not much, not at all) or you add a fifth in the middle. I prefer 4 because that makes people think harder.> 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? > // checkboxes: > + Actively contribute tooling improvements to improve it. > + Integrate it into our downstream fork. > + Use it for upstream contributions. > + Use it as the primary interface development environment. > + Use it for bisection.Good. (+ N/A, too)> 9. If multirepo is adopted, how do you plan to contribute to upstream? > - Using Git submodules. > - Using the Git repos directly. > - Using the SVN bridges. > - n/a: I don't contribute. > > 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? > - I'll use the monorepo as soon as it's possible, even before it's canonical. > - I'll use the monorepo as soon as it's canonical. > - I'll transition to monorepo eventually. > - I'll use the SVN bridge on separated sub-projects forever. > - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. > - n/a: I don't contribute. > > 11. If monorepo is adopted, how do you plan to integrate it downstream? > - We already use monorepo. > - We'll switch to pulling from monorepo during the transition period. > - We'll switch to pulling from monorepo eventually. > - We'll integrate from the SVN bridge forever. > - We'll integrate from the split sub-project Git mirror forever. > - n/a: There is no downstream.Good.> 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? > - This is great. Native cross-project refactoring, without penalizing runtime-only developers. > - Whatever. I'll deal with it. > - This is terrible. All the transition pain of monorepo, without the advantages.I didn't know we were proposing yet another variant. This seems like a last minute rushed in proposal and I don't want to endorse it in the survey. We can discuss them in the BoF, though.> 13. If multirepo is adopted, how much pain will there be in your transition? > - Nothing consequential. > - A little; but it'll be fine. > - A lot; but it'll get done somehow. > - Too much; I/we may stop contributing to LLVM. > > 14. If monorepo is adopted, how much pain will there be in your transition? > - Nothing consequential. > - A little; but it'll be fine. > - A lot; but it'll get done somehow. > - Too much; I/we may stop contributing to LLVM.Those are already covered by the current bad/good, but I'll change the wording to be like this one.> 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? > - CVS. > - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. > - Subversion repository as a single project (trunk/<sub-project>), with git-svn. > - Git: multirepo variant. > - Git: monorepo variant. > - Git: multi/mono hybrid variant. > - Other.Let's not put CVS in there, please. :) So, what's the purpose of this question? I mean, we are "starting fresh" in a way, and the responses of the rest of the survey would make this question irrelevant, no? I'll be changing the wording on the ones we all agree on and leave the ones with questions until they're all solved. cheers, --renato
> On Oct 13, 2016, at 11:56 AM, Renato Golin <renato.golin at linaro.org> wrote: > > Hi Duncan, > > I don't understand your concerns. > > First, the choice between sub-modules and mono-repo has been put > forward as the only two choices because people felt that, if we let it > open, we'd have too many different implementation details and we'd > never get anywhere. > > So... > >> - how much pain the transition would cause, instead of what they think the right final state is. > > The final state is defined by submod vs. monorepo, and that's > represented in a different question. Those questions are addressing > the additional work done to get there, as many have said would be the > crucial decision point. > > It also outlines the cost over their preferred vs non-preferred > solutions, which leads to the aggregated cost over the whole project > for each decision. > > >> - what's good for the individuals responding, instead of what they think is best for the LLVM project; and > > That's implied. I think it is clear enough, but we can always change > the wording if others feel confused. > > >> Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. > > It is a vote. The "thinking" is on the extended answer that follows. > Answers with good extended reasoning will have a greater weight than > those without. > > If you're worried about data mining, than leaving those questions to > full text answers will require someone to read it all, interpret, and > put their bias on top. Given the nature of this problem, we should > avoid bias whenever possible, especially when interpreting the > answers. > > >> Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. > > I see your point. We can re-word to make that more clear. > >> 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? >> - Always. >> - Most of the time. >> - Sometimes. >> - Never. > > Interesting, it covers the main problem with both proposals. > > >> 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. > > I'm not sure that's critical. My current source repo has 35GB with > just a few worktrees. > > Also, both solutions have low-disk-usage modes, and this would make no > difference on how we proceed.This is a point of contention and a concern that Chris voiced about the monorepo. It should be in the survey.> > > >> 6. How important is cross-project blame, grep, etc.? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. > > Based on other comments in the thread, we should leave this one out.The point of the survey is to gather data. The fact that not much people are doing it, does not mean that after reading the proposal document they wouldn’t answer " It should be easy enough that everyone does it by default.”.> > >> 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. > > I don't like to assert my opinion and then ask how much people agree.I don’t see an “opinion” in the question.> I prefer to ask the question directly, like: > > How often do you need to commit across repositories (ex. llvm+clang) > and how often are your builds broken because they're in separate > repositories?Asking it this way does not allows someone to answer " It should be easy enough that everyone does it by default.”. I prefer Duncan’s wording.> > Also, I think your scale of important is somewhat skewed up. Vital and > Extremely are at the top, somewhat is right bang in the middle and not > at all is the very bottom. > > You either have two positive and two negative (very, somewhat, not > much, not at all) or you add a fifth in the middle. I prefer 4 because > that makes people think harder. > > >> 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? >> // checkboxes: >> + Actively contribute tooling improvements to improve it. >> + Integrate it into our downstream fork. >> + Use it for upstream contributions. >> + Use it as the primary interface development environment. >> + Use it for bisection. > > Good. (+ N/A, too) > > >> 9. If multirepo is adopted, how do you plan to contribute to upstream? >> - Using Git submodules. >> - Using the Git repos directly. >> - Using the SVN bridges. >> - n/a: I don't contribute. >> >> 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? >> - I'll use the monorepo as soon as it's possible, even before it's canonical. >> - I'll use the monorepo as soon as it's canonical. >> - I'll transition to monorepo eventually. >> - I'll use the SVN bridge on separated sub-projects forever. >> - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. >> - n/a: I don't contribute. >> >> 11. If monorepo is adopted, how do you plan to integrate it downstream? >> - We already use monorepo. >> - We'll switch to pulling from monorepo during the transition period. >> - We'll switch to pulling from monorepo eventually. >> - We'll integrate from the SVN bridge forever. >> - We'll integrate from the split sub-project Git mirror forever. >> - n/a: There is no downstream. > > Good. > > >> 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? >> - This is great. Native cross-project refactoring, without penalizing runtime-only developers. >> - Whatever. I'll deal with it. >> - This is terrible. All the transition pain of monorepo, without the advantages. > > I didn't know we were proposing yet another variant. This seems like a > last minute rushed in proposal and I don't want to endorse it in the > survey. We can discuss them in the BoF, though.We're not “endorsing” anything in the survey. We’re collecting data to help driving the BoF discussing the proposal document. Before starting the survey design I stated that we should first have the proposal document ready, and the survey should ask the relevant question with respect to the proposal. Also, this “variant” was discussed very early when the monorepo proposal came out.> > >> 13. If multirepo is adopted, how much pain will there be in your transition? >> - Nothing consequential. >> - A little; but it'll be fine. >> - A lot; but it'll get done somehow. >> - Too much; I/we may stop contributing to LLVM. >> >> 14. If monorepo is adopted, how much pain will there be in your transition? >> - Nothing consequential. >> - A little; but it'll be fine. >> - A lot; but it'll get done somehow. >> - Too much; I/we may stop contributing to LLVM. > > Those are already covered by the current bad/good, but I'll change the > wording to be like this one. > > >> 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? >> - CVS. >> - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. >> - Subversion repository as a single project (trunk/<sub-project>), with git-svn. >> - Git: multirepo variant. >> - Git: monorepo variant. >> - Git: multi/mono hybrid variant. >> - Other. > > Let's not put CVS in there, please. :) > > So, what's the purpose of this question? I mean, we are "starting > fresh" in a way, and the responses of the rest of the survey would > make this question irrelevant, no?We’re not “starting fresh”: we have downstream user integrating the repos, we have bug tracker referencing revisions, we have tooling (LNT, llvm-bisect …). The sense of the question is “making abstraction of the pain of the transition” what is the “ideal” environment for developing LLVM. — Mehdi> > I'll be changing the wording on the ones we all agree on and leave the > ones with questions until they're all solved. > > cheers, > --renato
> On 2016-Oct-13, at 11:23, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi, > > Thanks a lot Duncan, I really like this! I totally support adopting this scheme now. See inline a few quite minor comments. > > Renato: are you still interested and available now to set-up the survey? We should close on this *this week*. > > >> On Oct 12, 2016, at 7:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >>> >>> On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Folks, >>> >>> After feedback from Chris and Mehdi, I have added one long text answer >>> to *each* critical questions (impact on productivity), so that people >>> can extend their reasoning. >>> >>> But I have not made them compulsory, so that people that don't know >>> much about or don't have any problem don't feel compelled to expand on >>> nothing. >>> >>> https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform >>> >>> The bottom line is, answers with more substance will be taken more >>> seriously than those without, but the numbers should also tell us >>> something. >>> >>> For example, if 9/10 of the answers are "we don't care", than the >>> other 1/10 will have less weight than if it was 1/2, but still >>> important to any decision. >>> >>> Can we go live with what we have now? >>> >>> Mehdi, how's the document? Can we get that online so I can change the >>> header of the survey? >> >> Hi Renato, >> >> Thanks very much for putting this together. >> >> I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on. >> >> The survey is a great start, but the final page isn't quite addressing the concerns in the final proposal. I'm not sure it asks the right questions to focus the conversation at the BoF. >> >> Firstly, I'm concerned that the questions focus on: >> - what's good for the individuals responding, instead of what they think is best for the LLVM project; and >> - how much pain the transition would cause, instead of what they think the right final state is. >> >> Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. >> >> Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. >> >> I spent some time today thinking through what set of questions would get us the data we want. >> - I've focused on the main concerns about (and benefits of) the two variants. >> - I've referred to the multirepo and monorepo by name (consistently) in questions asking about them. This ensures that people know exactly what they're answering. >> - I've added specific questions about how people plan to use the multirepo and monorepo, so that we know which tooling is most important (and also to determine how worried we should be about some of the concerns). >> - I've moved the "vote"-like question to the end to force respondents to think through the issues first. I've also restricted "the vote" to "the ideal project setup", so we can clearly separate that from "transition pain". (I'm still not sure the vote will have much value, but it doesn't hurt.) >> >> Here are my suggested questions; feedback welcome: >> >> ---- >> >> 1. How do you use LLVM? >> // as is >> >> 2. Which projects do you contribute to / use? >> // as is > > For this last question, I’d keep a check-boxes list with an optional blank field. It seems that the list of projects being limited, checking boxes is both easier for the people answering and for us doing the data-mining. > (What Renato has set-up looks good to me here)I agree that what Renato has set up looks good. That's what I meant from "as is", but I wasn't clear.> > >> >> 3. Use this field to expand on your usage, if necessary >> // as is >> >> 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? >> - Always. >> - Most of the time. >> - Sometimes. >> - Never. >> >> 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. >> >> 6. How important is cross-project blame, grep, etc.? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. >> >> 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. >> >> 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? >> // checkboxes: >> + Actively contribute tooling improvements to improve it. >> + Integrate it into our downstream fork. >> + Use it for upstream contributions. >> + Use it as the primary interface development environment. >> + Use it for bisection. >> >> 9. If multirepo is adopted, how do you plan to contribute to upstream? >> - Using Git submodules. >> - Using the Git repos directly. >> - Using the SVN bridges. >> - n/a: I don't contribute. > > Can you clarify what “Using Git submodules” mean? > Since the umbrella is read-only, it is not clear to me. > Removing this first answer and keeping the others makes sense to me on the other hand.Day-to-day work: - Are you checking out the Git umbrella, using git-submodules, and hacking on the submodules within it? - Are you checking out the split repos directly? - Are you checking out the SVN bridges directly? - n/a Does that help to clarify? How can we adjust the wording to make it clear?> > >> >> 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? >> - I'll use the monorepo as soon as it's possible, even before it's canonical. >> - I'll use the monorepo as soon as it's canonical. >> - I'll transition to monorepo eventually. >> - I'll use the SVN bridge on separated sub-projects forever. >> - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. >> - n/a: I don't contribute. >> >> 11. If monorepo is adopted, how do you plan to integrate it downstream? >> - We already use monorepo. >> - We'll switch to pulling from monorepo during the transition period. >> - We'll switch to pulling from monorepo eventually. >> - We'll integrate from the SVN bridge forever. >> - We'll integrate from the split sub-project Git mirror forever. >> - n/a: There is no downstream. >> >> 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? >> - This is great. Native cross-project refactoring, without penalizing runtime-only developers. >> - Whatever. I'll deal with it. >> - This is terrible. All the transition pain of monorepo, without the advantages. >> >> 13. If multirepo is adopted, how much pain will there be in your transition? >> - Nothing consequential. >> - A little; but it'll be fine. >> - A lot; but it'll get done somehow. >> - Too much; I/we may stop contributing to LLVM. >> >> 14. If monorepo is adopted, how much pain will there be in your transition? >> - Nothing consequential. >> - A little; but it'll be fine. >> - A lot; but it'll get done somehow. >> - Too much; I/we may stop contributing to LLVM. > > For the two previous question, I’d add an answer “n/a: I don’t contribute”. > (We keep readonly views in both cases, not clear to me how it affects non-contributors).SGTM.> > — > Mehdi > > >> >> 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? >> - CVS. >> - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. >> - Subversion repository as a single project (trunk/<sub-project>), with git-svn. >> - Git: multirepo variant. >> - Git: monorepo variant. >> - Git: multi/mono hybrid variant. >> - Other. >> >> 16. Other comments. >> // Open text field. >> >> ---- >> >> Thanks again for your hard work on this! >> >> Duncan >> >> P.S. I think there's a bug on in the survey (or maybe my browser). I'm seeing some stray "If responding for a" text at the top. See the PDF I've attached here. >> >> <Screen Shot 2016-10-12 at 16.16.05.png.pdf> >>> >>> We only have a month and a bit now... >>> >>> cheers, >>> --renato >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On 13 October 2016 at 03:07, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:> 6. How important is cross-project blame, grep, etc.? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling.Btw, I now split into multiple pages, to make it less daunting, so I've added this question at the "usage questions" page, but phrased in a more generic way as "cross-repo usage" (example, bisect, blame, etc). cheers, --renato
> On 2016-Oct-13, at 11:56, Renato Golin <renato.golin at linaro.org> wrote: > > Hi Duncan, > > I don't understand your concerns. > > First, the choice between sub-modules and mono-repo has been put > forward as the only two choices because people felt that, if we let it > open, we'd have too many different implementation details and we'd > never get anywhere.Yup, that makes sense. I'm partly just trying to fill in the survey now that we've been informed by the proposal process (impossible to predict ahead of time). BTW, this has now been committed, so you can read it here: http://llvm.org/docs/Proposals/GitHubMove.html> So... > >> - how much pain the transition would cause, instead of what they think the right final state is. > > The final state is defined by submod vs. monorepo, and that's > represented in a different question. Those questions are addressing > the additional work done to get there, as many have said would be the > crucial decision point. > > It also outlines the cost over their preferred vs non-preferred > solutions, which leads to the aggregated cost over the whole project > for each decision.I guess my problem is that it's really hard for people to judge this, so I'm breaking it down to specific questions that are easy to judge. I think if we can trust that people answered accurately, the date will be more useful for the BoF discussion.> >> - what's good for the individuals responding, instead of what they think is best for the LLVM project; and > > That's implied. I think it is clear enough, but we can always change > the wording if others feel confused. > > >> Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. > > It is a vote. The "thinking" is on the extended answer that follows. > Answers with good extended reasoning will have a greater weight than > those without.I'd like to move it later. Asking for a vote first will affect how respondents answer the rest of the questions; humans have a tendency to post-rationalize their decisions. Asking for the vote at the end forces them to think through the issues first, informing their eventual decision/vote.> > If you're worried about data mining, than leaving those questions to > full text answers will require someone to read it all, interpret, and > put their bias on top. Given the nature of this problem, we should > avoid bias whenever possible, especially when interpreting the > answers.I agree that full text answers aren't good for data mining, and lead to bias. That's why I argue for spelling out the known concerns with specific radio and/or checkbox questions.> > >> Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. > > I see your point. We can re-word to make that more clear. > >> 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? >> - Always. >> - Most of the time. >> - Sometimes. >> - Never. > > Interesting, it covers the main problem with both proposals. > > >> 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. > > I'm not sure that's critical. My current source repo has 35GB with > just a few worktrees. > > Also, both solutions have low-disk-usage modes, and this would make no > difference on how we proceed.This is targeting the number one contentious issue about monorepo. You can see more in the proposal: http://llvm.org/docs/Proposals/GitHubMove.html#id12 Affected users that need read-write access can use the SVN bridge (or the git-svn layer on top of it). There's another concern that the SVN bridge might somehow go away, killing the split sub-project option for write access. However, we'll *always* be able to maintain a split sub-project Git mirror. This question groups everyone into three categories: - People that are worried about disk space and need read/write access. They'll be relying somehow on the SVN bridge. - People that are not worried about disk space. Whether they decide to use monorepo or the SVN bridge, their disk space is not preventing them from using monorepo. (It sounds like this is your category.) - People that don't need write access, so split Git mirrors would be sufficient (they don't rely on the SVN bridge).> > > >> 6. How important is cross-project blame, grep, etc.? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. > > Based on other comments in the thread, we should leave this one out.I don't understand your reasoning. Why? This is targeting one of the benefits of monorepo. I think it's important to know if anyone cares.> >> 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. > > I don't like to assert my opinion and then ask how much people agree.This doesn't strike me as opinion. It does design away a class of build failures (whether it's an important class is opinion), and it does simplify making API changes (whether it matters is opinion).> I prefer to ask the question directly, like: > > How often do you need to commit across repositories (ex. llvm+clang) > and how often are your builds broken because they're in separate > repositories?This affects more than just the people *making* the changes, so I'm not a big fan of your wording. I also don't think the frequency of the problems necessarily reflects developers' opinions about how important they are. - Some people may find that it happens "all the time", but think that it's not important. - Others may find that it happens rarely, but think that it's devastating.> Also, I think your scale of important is somewhat skewed up. Vital and > Extremely are at the top, somewhat is right bang in the middle and not > at all is the very bottom.How about "Quite" instead of "Extremely"?> > You either have two positive and two negative (very, somewhat, not > much, not at all) or you add a fifth in the middle. I prefer 4 because > that makes people think harder.I think they're all positive except "not at all" (which is 0). Since "vital" is an absolute adjective, it clearly sets an upper limit. But I'm happy to shift somewhat/extremely if you can think of better things in the middle.> > >> 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? >> // checkboxes: >> + Actively contribute tooling improvements to improve it. >> + Integrate it into our downstream fork. >> + Use it for upstream contributions. >> + Use it as the primary interface development environment. >> + Use it for bisection. > > Good. (+ N/A, too) >Sure, that works. Although "leaving all boxes blank" means the same thing I think.> > >> 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? >> - This is great. Native cross-project refactoring, without penalizing runtime-only developers. >> - Whatever. I'll deal with it. >> - This is terrible. All the transition pain of monorepo, without the advantages. > > I didn't know we were proposing yet another variant. This seems like a > last minute rushed in proposal and I don't want to endorse it in the > survey. We can discuss them in the BoF, though.It was raised around a month ago in the proposal thread as a compromise solution. Here's the description. http://llvm.org/docs/Proposals/GitHubMove.html#multi-mono-hybrid-variant Since this hasn't been carefully thought through, it risks wasting a *lot* of time at the BoF. I'd like to raise it here so that we know if it's worth talking about there. If this gets a lot of support, then we should talk about it at the BoF. But if most people think it's the end of the world then we can skip the conversation.> >> 13. If multirepo is adopted, how much pain will there be in your transition? >> - Nothing consequential. >> - A little; but it'll be fine. >> - A lot; but it'll get done somehow. >> - Too much; I/we may stop contributing to LLVM. >> >> 14. If monorepo is adopted, how much pain will there be in your transition? >> - Nothing consequential. >> - A little; but it'll be fine. >> - A lot; but it'll get done somehow. >> - Too much; I/we may stop contributing to LLVM. > > Those are already covered by the current bad/good, but I'll change the > wording to be like this one.Yes, these were basically rewording of those questions :).> > >> 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? >> - CVS. >> - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. >> - Subversion repository as a single project (trunk/<sub-project>), with git-svn. >> - Git: multirepo variant. >> - Git: monorepo variant. >> - Git: multi/mono hybrid variant. >> - Other. > > Let's not put CVS in there, please. :)I believe it was the choice Chris made, so it seemed worth mentioning ;). If you really don't want it there, I'm fine with you taking it out.> > So, what's the purpose of this question?This is my wording for "the vote".> I mean, we are "starting > fresh" in a way, and the responses of the rest of the survey would > make this question irrelevant, no?This is wording to tease out: "If there were no transition pain, what do you think the best solution would be?" I worded differently so that I wasn't making people think about the pain while they thought about their answer. (Might be good to have a text box for "other" in case the entire community wants Mercurial or something; up to you.)> I'll be changing the wording on the ones we all agree on and leave the > ones with questions until they're all solved.Makes sense!> > cheers, > --renato
> On 2016-Oct-13, at 13:51, Renato Golin <renato.golin at linaro.org> wrote: > > On 13 October 2016 at 03:07, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> 6. How important is cross-project blame, grep, etc.? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. > > Btw, I now split into multiple pages, to make it less daunting, so > I've added this question at the "usage questions" page, but phrased in > a more generic way as "cross-repo usage" (example, bisect, blame, > etc).To pick the nit, "cross-repo" is not correct for monorepo. It's only cross-project.> cheers, > --renato
On 13 October 2016 at 03:07, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:> Hi Renato, > > Thanks very much for putting this together. > > I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on.Hi Duncan, I think I have addressed all your points. The survey is now much more complex, but I think more in line with the document and with more practical answers (thanks for that). Can you please confirm that the result looks good on your end? https://goo.gl/forms/HBlyyDuEsH2tQ5Xi2 cheers, --renato
> On 2016-Oct-13, at 15:28, Renato Golin <renato.golin at linaro.org> wrote: > > On 13 October 2016 at 03:07, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> Hi Renato, >> >> Thanks very much for putting this together. >> >> I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on. > > Hi Duncan, > > I think I have addressed all your points. The survey is now much more > complex, but I think more in line with the document and with more > practical answers (thanks for that). > > Can you please confirm that the result looks good on your end? > > https://goo.gl/forms/HBlyyDuEsH2tQ5Xi2(I've caught up now.) This looks great, thanks so much for filling it in. Remaining concerns: 1. The minor comments I had in my response ~20 minutes ago. 2. The "disk space and read-only/read-write" question (#5) directly gathers data on the main concern with monorepo, and it's still missing. => If we don't collect data on this, we'll have no idea whether anyone cares about the concern. => Sparse checkouts, which you mentioned, do not have consensus as addressing this. => The Git-svn mirrors on the SVN bridge would address it, but there's a concern they could disappear somehow someday. => But all of this is only worth hashing out if there are real users that will be affected. => And assuming it is worth hashing out, the kind of solution we come up with in the BoF might depend on the *number* of real, affected users. 3. The multi/mono hybrid question (#12) directly gathers data on the compromise proposal, and it's still missing. => If we can show with the survey that no one wants this, we'll save a lot of time at the BoF by knowing that ahead of time. => On the other hand, if many people want it, someone should think through it deeply and be prepared to answer questions about it at the BoF. I've actually got new wording for this one that I think is better (and I hope will demonstrate better why it's important):> 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? > - This is great. Native cross-project refactoring, without penalizing runtime-only developers. > - This is a compromise, but if I can't have multirepo, I want this. > - This is a compromise, but if I can't have monorepo, I want this. > - Whatever. I'll deal with it. > - This is terrible. All the transition pain of monorepo, without the advantages.^ The difference is the new "compromise" options. - Realistically, I don't think this is anyone's first choice, but we should have a "great" answer just in case someone surprises us. - If there are a lot of "we are fine with the compromise" votes, that's useful to know, and might make this worth talking about. - If there are a lot of "this is terrible" votes, that's useful to know as well.