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

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 19 August 2016 at 23:57, Jonathan Roelofs <jonathan at
codesourcery.com> wrote:
> 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.
This has been addressed early on by splitting short-term from long-term.

So, if you require a lot of changes, but overall this will be better
for you, the answer is "major impact short-term", "no impact
long-term".

You can interpret "no impact long term" as "it's would be a
good
move", as the long term "git-svn" already has a costly long term
impact.

So, It seems that the common misunderstanding here is that "the
current cost is zero", but that's far from the truth, and it's the
major reason why we're trying to change.

I can add an extra answer to the long term like "it'll be better".

does that help?

--renato

On 8/19/16 5:32 PM, Renato Golin wrote:
> On 19 August 2016 at 23:57, Jonathan Roelofs <jonathan at
codesourcery.com> wrote:
>> 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.
>
> This has been addressed early on by splitting short-term from long-term.
>
> So, if you require a lot of changes, but overall this will be better
> for you, the answer is "major impact short-term", "no impact
> long-term".
I don't think that actually susses out the difference I'm trying to draw
(unless I'm misunderstanding how you're using "impact" here).
For
example, switching to git can have a large impact on one's workflow in 
the long term, but that large long term impact might be a good thing.... 
so maybe the right wording here is "negative impact"?
>
> You can interpret "no impact long term" as "it's would
be a good
> move", as the long term "git-svn" already has a costly long
term
> impact.
>
> So, It seems that the common misunderstanding here is that "the
> current cost is zero", but that's far from the truth, and it's
the
> major reason why we're trying to change.
>
> I can add an extra answer to the long term like "it'll be
better".
>
> does that help?
Yeah, I think that's better (pun intended).

The important thing here, I think, is to get data on whether people 
think the change is a good thing, rather than to get data on whether 
people think the change is "big". Maybe it's worthwhile to get
data on
all of: { big, small } x { good, bad } x { long term, short term } ?


Jon
>
> --renato
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded