> On Oct 13, 2016, at 2:15 PM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
>>
>> On Oct 13, 2016, at 1:40 PM, Duncan P. N. Exon Smith <dexonsmith at
apple.com <mailto:dexonsmith at apple.com>> wrote:
>>
>>>
>>> On 2016-Oct-13, at 11:23, Mehdi Amini <mehdi.amini at apple.com
<mailto: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 <mailto:dexonsmith at apple.com>> wrote:
>>>>
>>>>>
>>>>> 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
>>>
>>> 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?
>
> Oh I see. You’re reword may be enough.
> I think what confused me was the “contribute to upstream” part of the
question. If you have an idea to rephrase the question maybe?
This question is the last one that does not seem great to me. Right now it
reads:
If multi-repo is adopted, how do you plan to contribute to upstream? *
- Using Git submodules for everything (checkout, commit, push)
- Using the Git repos directly, submodules only for bisecting, etc.
- Using the SVN bridges.
- I don't contribute.
The first answer mention “commit” and “push”, using submodules, which isn’t
clear to me what it means in practice since the submodules are supposed to be
read-only (no-one should be able to push to the umbrella).
Can you clarify or reword?
—
Mehdi
>
>
>
>>
>>
>>>
>>>
>>>>
>>>> 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 <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
<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/20161014/a323c58b/attachment.html>