[llvm-dev] GitHub Survey?

[Mehdi Amini via llvm-dev]

> On Oct 13, 2016, at 1:23 PM, Renato Golin <renato.golin at linaro.org> wrote:
> 
> 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.

We should ask the set of questions that are relevant to the proposal document, this is why Duncan’s feedback arrives right after the proposal is “finalized”. The set of questions he worded are right on point with respect to the document, neither too much or not enough.

If the survey does not help quantifying how much a concern raised in the proposal is important, it is an issue to me.

For this particular question, here are some relevant pieces of the proposal:

http://llvm.org/docs/Proposals/GitHubMove.html#concerns <http://llvm.org/docs/Proposals/GitHubMove.html#concerns> "Refactoring across projects is not friendly: taking some functions from clang to make it part of a utility in libSupport wouldn’t carry the history of the code in the llvm repo,  …. “
http://llvm.org/docs/Proposals/GitHubMove.html#monorepo-variant <http://llvm.org/docs/Proposals/GitHubMove.html#monorepo-variant> "Tooling based on git grep works natively across sub-projects, allowing to easier …”


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

Right, it seems we agree on the goal. All of my feedback is oriented toward it.

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


I’m not sure what you’re referring to here. In case I wasn’t clear before, I’m not interested in any way “to do a third” proposal.

My views is that there is a single document proposal for moving to GitHub, and it is mentioning multiple variants. 
It is published here: http://llvm.org/docs/Proposals/GitHubMove.html <http://llvm.org/docs/Proposals/GitHubMove.html> and it is also attached to the Dev Meeting Schedule: http://sched.co/8Yzj <http://sched.co/8Yzj>

We need now a survey that *matches* the proposal document, because that is what will be discussed at the meeting.

The document contains already this variant: http://llvm.org/docs/Proposals/GitHubMove.html#multi-mono-hybrid-variant <http://llvm.org/docs/Proposals/GitHubMove.html#multi-mono-hybrid-variant> ; so we need a question about it.

— 
Mehdi




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/9f1ece49/attachment.html>