[llvm-dev] GitHub Survey?

[Renato Golin via llvm-dev]

On 13 October 2016 at 20:45, Mehdi Amini <mehdi.amini at apple.com> wrote:
> This is a point of contention and a concern that Chris voiced about the monorepo. It should be in the survey.

A lot of concerns were voiced on the discussion, not all of them here.

Hasn't this particular point been solved by shallow checkouts?

Chris, are you still worried about disk size on a mono-repo vs. sub-modules?


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

We can go on and on about many topics, but the more we put in, the
harder it will be to make sense of things. Unless the question is
critical to the problem at hand, which I don't believe it is, we
should avoid bloating the survey.

As I said to Chris L. before, we can have a complete survey that will
take a lot of time to answer and will give us wonderful data over the
corse of months, and we can have a quick survey to feed the BoF
discussion, but we can't have both.


>>> 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes.  How important is it?
>
> I don’t see an “opinion” in the question.

Perhaps I should have said "a point of view".


> Asking it this way does not allows someone to answer "It should be easy enough that everyone does it by default.”.

I made a scale: must fix / could fix / doesn't matter.


> We're not “endorsing” anything in the survey. We’re collecting data to help driving the BoF discussing the proposal document.

The deal was to collect what's proposed only, and we're not (or should
not be) proposing a third alternative which won't have time to be
discussed.


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

We had the first proposal agreed and documented one month before the
survey first appeared. The second proposal is still not ready and we
won't have time to do a third.


> Also, this “variant” was discussed very early when the monorepo proposal came out.

Many variants were proposed for the sub-modules, too and only one
survived. Again, that was the "deal" we all reached in the review to
make the proposal and the survey more manageable.


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

I see your point. I'll add this question.

cheers,
--renato