[llvm-dev] GitHub Survey?

[Duncan P. N. Exon Smith via llvm-dev]

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