[llvm-dev] GitHub Survey?

Duncan P. N. Exon Smith via llvm-dev
Fri, 14 Oct 2016 00:16:52 -0000

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