llvm dev - Aug 2016 - [RFC] GitHub Survey - Please review

On 19 August 2016 at 19:35, Justin Bogner <mail at justinbogner.com>
wrote:
> I think you misunderstood what I meant here. Whether "moving to
git"
> will affect my workflow depends very much on "how we're moving to
> git".
That's exactly what I understood. :)

> For example, if we do a monorepo, I may now need to lay code out
> differently on my filesystem (since I currently check out multiple repos
> rooted at llvm), or if we do a multirepo I probably need to learn some
> new commands to associate llvm and clang repos (rather than using git
> svn find-rev). If we do something where there's a monorepo of some of
> the stuff but not all, I probably have to adapt to things from each.
My point is: either way, you'll have to "change your workflow".
For
some people workflow A will be "less change", for others, it will be
workflow B. For some others still, neither A nor B will be easier than
Git-SVN, or just SVN.

My other point was: *a lot* of people already "adapt" their workflow,
so capturing how much each option will make to each person is less
important than catching how much *any* change will mean to *most*
people.

To capture and weigh each edge of a graph with hundreds of nodes will
need a very smart AI. But I can do it reasonably well with a dozen or
so on my own. I don't have the time nor the expertise to build such an
AI, and it would ultimately have uncertainties, which could very well
amount to the same ones we get with less, imprecise questions.

This whole exercise has already deviated the focus and work of *A LOT*
of people in the community. I'm trying to make it less painful.

So, I think it's perfectly acceptable to lose some of the semantics on
the questions if we get the gist of what the community wants.

makes sense?

--renato

Renato Golin <renato.golin at linaro.org> writes:
> On 19 August 2016 at 19:35, Justin Bogner <mail at justinbogner.com>
wrote:
>> I think you misunderstood what I meant here. Whether "moving to
git"
>> will affect my workflow depends very much on "how we're moving
to
>> git".
>
> That's exactly what I understood. :)
>
>> For example, if we do a monorepo, I may now need to lay code out
>> differently on my filesystem (since I currently check out multiple
repos
>> rooted at llvm), or if we do a multirepo I probably need to learn some
>> new commands to associate llvm and clang repos (rather than using git
>> svn find-rev). If we do something where there's a monorepo of some
of
>> the stuff but not all, I probably have to adapt to things from each.
>
> My point is: either way, you'll have to "change your
workflow". For
> some people workflow A will be "less change", for others, it will
be
> workflow B. For some others still, neither A nor B will be easier than
> Git-SVN, or just SVN.
>
> My other point was: *a lot* of people already "adapt" their
workflow,
> so capturing how much each option will make to each person is less
> important than catching how much *any* change will mean to *most*
> people.
>
> To capture and weigh each edge of a graph with hundreds of nodes will
> need a very smart AI. But I can do it reasonably well with a dozen or
> so on my own. I don't have the time nor the expertise to build such an
> AI, and it would ultimately have uncertainties, which could very well
> amount to the same ones we get with less, imprecise questions.
>
> This whole exercise has already deviated the focus and work of *A LOT*
> of people in the community. I'm trying to make it less painful.
>
> So, I think it's perfectly acceptable to lose some of the semantics on
> the questions if we get the gist of what the community wants.
>
> makes sense?
My point is still unaddressed - I wouldn't be able to answer this
question as phrased. If we go with the multi-repo (as currently
proposed) my answer is "very little change to workflow". If we go with
most of the mono-repo proposals so far, my answer is "major change to
workflow". If the survey is just "what does switching to git do to
your
workflow?", I simply can't answer at all.

On 8/19/16 4:50 PM, Justin Bogner via llvm-dev wrote:
> Renato Golin <renato.golin at linaro.org> writes:
>> On 19 August 2016 at 19:35, Justin Bogner <mail at
justinbogner.com> wrote:
>>> I think you misunderstood what I meant here. Whether "moving
to git"
>>> will affect my workflow depends very much on "how we're
moving to
>>> git".
>>
>> That's exactly what I understood. :)
>>
>>> For example, if we do a monorepo, I may now need to lay code out
>>> differently on my filesystem (since I currently check out multiple
repos
>>> rooted at llvm), or if we do a multirepo I probably need to learn
some
>>> new commands to associate llvm and clang repos (rather than using
git
>>> svn find-rev). If we do something where there's a monorepo of
some of
>>> the stuff but not all, I probably have to adapt to things from
each.
>>
>> My point is: either way, you'll have to "change your
workflow". For
>> some people workflow A will be "less change", for others, it
will be
>> workflow B. For some others still, neither A nor B will be easier than
>> Git-SVN, or just SVN.
>>
>> My other point was: *a lot* of people already "adapt" their
workflow,
>> so capturing how much each option will make to each person is less
>> important than catching how much *any* change will mean to *most*
>> people.
>>
>> To capture and weigh each edge of a graph with hundreds of nodes will
>> need a very smart AI. But I can do it reasonably well with a dozen or
>> so on my own. I don't have the time nor the expertise to build such
an
>> AI, and it would ultimately have uncertainties, which could very well
>> amount to the same ones we get with less, imprecise questions.
>>
>> This whole exercise has already deviated the focus and work of *A LOT*
>> of people in the community. I'm trying to make it less painful.
>>
>> So, I think it's perfectly acceptable to lose some of the semantics
on
>> the questions if we get the gist of what the community wants.
>>
>> makes sense?
>
> My point is still unaddressed - I wouldn't be able to answer this
> question as phrased. If we go with the multi-repo (as currently
> proposed) my answer is "very little change to workflow". If we go
with
> most of the mono-repo proposals so far, my answer is "major change to
> workflow". If the survey is just "what does switching to git do
to your
> workflow?", I simply can't answer at all.
Not sure if this has already been mentioned elsewhere, but I think 
there's another important aspect to this: a big change in workflow can 
make things better/worse/same , but measuring the size of change doesn't 
tell you whether that change is good or not. Both the effort required to 
change, and the desirability of the end state are important here.


Jon
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

> On Aug 19, 2016, at 2:02 PM, Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 19 August 2016 at 19:35, Justin Bogner <mail at justinbogner.com>
wrote:
>> I think you misunderstood what I meant here. Whether "moving to
git"
>> will affect my workflow depends very much on "how we're moving
to
>> git".
> 
> That's exactly what I understood. :)
> 
> 
>> For example, if we do a monorepo, I may now need to lay code out
>> differently on my filesystem (since I currently check out multiple
repos
>> rooted at llvm), or if we do a multirepo I probably need to learn some
>> new commands to associate llvm and clang repos (rather than using git
>> svn find-rev). If we do something where there's a monorepo of some
of
>> the stuff but not all, I probably have to adapt to things from each.
> 
> My point is: either way, you'll have to "change your
workflow". For
> some people workflow A will be "less change", for others, it will
be
> workflow B. For some others still, neither A nor B will be easier than
> Git-SVN, or just SVN.
> 
> My other point was: *a lot* of people already "adapt" their
workflow,
> so capturing how much each option will make to each person is less
> important than catching how much *any* change will mean to *most*
> people.
> 
> To capture and weigh each edge of a graph with hundreds of nodes will
> need a very smart AI. But I can do it reasonably well with a dozen or
> so on my own. I don't have the time nor the expertise to build such an
> AI, and it would ultimately have uncertainties, which could very well
> amount to the same ones we get with less, imprecise questions.
> 
> This whole exercise has already deviated the focus and work of *A LOT*
> of people in the community. I'm trying to make it less painful.
> 
> So, I think it's perfectly acceptable to lose some of the semantics on
> the questions if we get the gist of what the community wants.
> 
> makes sense?
Not really no.
If the answer to the question can swing dramatically depending on the option
taken, the data you’re collecting becomes meaningless. I probably wouldn’t try
fixing the survey before getting the proposal document out.

— 
Mehdi

On 19 August 2016 at 23:50, Justin Bogner <mail at justinbogner.com>
wrote:
> My point is still unaddressed - I wouldn't be able to answer this
> question as phrased. If we go with the multi-repo (as currently
> proposed) my answer is "very little change to workflow". If we go
with
> most of the mono-repo proposals so far, my answer is "major change to
> workflow". If the survey is just "what does switching to git do
to your
> workflow?", I simply can't answer at all.
What if we inverted the questions?

Actually, this question is only meaningful for the people *not*
wanting to move or *not* wanting one of the two alternatives.

So, if we make this one conditional on the mono-repo vs. sub-mods,
your point would have been addressed.

So, change to:

* Which option? mono, mods, neither?

* How much the one you didn't pick would affect your workflow? A lot,
some, nothing?

* Expand on your answer?

This way we don't need the 4 answers to the mono vs mods, nor we need
two free-text for the same question-ish.

Does that work?

--renato

On 20 August 2016 at 00:18, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> If the answer to the question can swing dramatically depending on the
option taken, the data you’re collecting becomes meaningless. I probably
wouldn’t try fixing the survey before getting the proposal document out.
See if my answer to Justin helps...