llvm dev - Feb 2020 - amount of camelCase refactoring causing some downstream overhead

During that variable renaming debate, there was a discussion about discussion
about doing things all at once, piecemeal or not at all. An issue that
wasn't really resolved I think. I had the impression that the efforts
fizzled out a bit, and I thought this renaming was maybe related to that, but
I'm neutral on if we should do variable renaming.

All I'm asking as a kindness if we could be kind on poor downstream
maintainers not on the issue of variable renaming at large, but on the micro
level of not pushing 5/6 patches of this kind covering closely related
functionality in two days but collating them in 1. I don't think that would
slow down development, and I wanted to highlight the issue, as people might not
be aware that they could save some pain in a simple way. Especially if indeed
there is going to be a big renaming push and this would be a continuous thing.

Cheers,
/Ties

________________________________________
From: Michael Kruse <llvmdev at meinersbur.de>
Sent: 17 February 2020 21:16
To: Ties Stuij
Cc: llvm-dev
Subject: Re: [llvm-dev] amount of camelCase refactoring causing some downstream
overhead

My understanding is that LLVM's general policy is to not let
downstream slow down upstream development. The C++ API explicitly
unstable.

Note that we are even considering renaming variables globally:
https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html

Michael

Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev
<llvm-dev at lists.llvm.org>:
>
> Hi there,
>
> At the end of last week we saw a number of commits go in that were
camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions.
>
> For example:
> - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691
> - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b
> - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956
>
> Unfortunately all these individual commits trigger the same merge conflicts
over and over again with our downstream repo, which takes us some manual
intervention every time.
>
> I understand uniformity is a nice to have, but:
> 1 - is it worth it to do this work right now? I can remember the casing
debate a few months back, which seems unrelated to this work which seems manual,
but I'm unsure of the outcome.
> 2 - If this work should be done, it would be nice if all of the work is
done in one batch, to save us some of the downstream overhead.
>
> Thanks
> /Ties
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

As others have said, our long standing policy has been that downstream 
projects must fend for themselves.  We're certainly not going to reverse 
that policy without careful discussion of the tradeoffs.

I'm personally of the opinion that there could be a middle ground which 
allows upstream to move quickly while reducing headache for downstream 
projects.  Given I wear both hats, I know I'd certainly appreciate such 
a state.  However, it's important to state that such decisions would 
need to be carefully considered and would require some very careful 
drafting of proposal to balance the competing interests at hand.

If anyone is curious, I'm happy to share some ideas offline on what 
starting points might be, but I have neither the time nor the interest 
to drive such a conversion on list.

Philip

On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote:
> During that variable renaming debate, there was a discussion about
discussion about doing things all at once, piecemeal or not at all. An issue
that wasn't really resolved I think. I had the impression that the efforts
fizzled out a bit, and I thought this renaming was maybe related to that, but
I'm neutral on if we should do variable renaming.
>
> All I'm asking as a kindness if we could be kind on poor downstream
maintainers not on the issue of variable renaming at large, but on the micro
level of not pushing 5/6 patches of this kind covering closely related
functionality in two days but collating them in 1. I don't think that would
slow down development, and I wanted to highlight the issue, as people might not
be aware that they could save some pain in a simple way. Especially if indeed
there is going to be a big renaming push and this would be a continuous thing.
>
> Cheers,
> /Ties
>
> ________________________________________
> From: Michael Kruse <llvmdev at meinersbur.de>
> Sent: 17 February 2020 21:16
> To: Ties Stuij
> Cc: llvm-dev
> Subject: Re: [llvm-dev] amount of camelCase refactoring causing some
downstream overhead
>
> My understanding is that LLVM's general policy is to not let
> downstream slow down upstream development. The C++ API explicitly
> unstable.
>
> Note that we are even considering renaming variables globally:
> https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html
>
> Michael
>
> Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev
> <llvm-dev at lists.llvm.org>:
>> Hi there,
>>
>> At the end of last week we saw a number of commits go in that were
camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions.
>>
>> For example:
>> - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691
>> - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b
>> - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956
>>
>> Unfortunately all these individual commits trigger the same merge
conflicts over and over again with our downstream repo, which takes us some
manual intervention every time.
>>
>> I understand uniformity is a nice to have, but:
>> 1 - is it worth it to do this work right now? I can remember the casing
debate a few months back, which seems unrelated to this work which seems manual,
but I'm unsure of the outcome.
>> 2 - If this work should be done, it would be nice if all of the work is
done in one batch, to save us some of the downstream overhead.
>>
>> Thanks
>> /Ties
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

I don't think anyone is arguing to change longstanding policy. From a
downstream perspective many small renaming changes do increase overhead for
us.

One thing that happens to downstream projects is that they support more
than one LLVM version, we (JuliaLang) currently try to support latest
stable + master.

So for me the question is more, are renaming changes worth downstream
projects not being able to test and provide feedback to upstream?  One way
of mitigating that is to consciously schedule them just before a release
and do them all in short succession.

-V


On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> As others have said, our long standing policy has been that downstream
> projects must fend for themselves.  We're certainly not going to
reverse
> that policy without careful discussion of the tradeoffs.
>
> I'm personally of the opinion that there could be a middle ground which
> allows upstream to move quickly while reducing headache for downstream
> projects.  Given I wear both hats, I know I'd certainly appreciate such
> a state.  However, it's important to state that such decisions would
> need to be carefully considered and would require some very careful
> drafting of proposal to balance the competing interests at hand.
>
> If anyone is curious, I'm happy to share some ideas offline on what
> starting points might be, but I have neither the time nor the interest
> to drive such a conversion on list.
>
> Philip
>
> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote:
> > During that variable renaming debate, there was a discussion about
> discussion about doing things all at once, piecemeal or not at all. An
> issue that wasn't really resolved I think. I had the impression that
the
> efforts fizzled out a bit, and I thought this renaming was maybe related to
> that, but I'm neutral on if we should do variable renaming.
> >
> > All I'm asking as a kindness if we could be kind on poor
downstream
> maintainers not on the issue of variable renaming at large, but on the
> micro level of not pushing 5/6 patches of this kind covering closely
> related functionality in two days but collating them in 1. I don't
think
> that would slow down development, and I wanted to highlight the issue, as
> people might not be aware that they could save some pain in a simple way.
> Especially if indeed there is going to be a big renaming push and this
> would be a continuous thing.
> >
> > Cheers,
> > /Ties
> >
> > ________________________________________
> > From: Michael Kruse <llvmdev at meinersbur.de>
> > Sent: 17 February 2020 21:16
> > To: Ties Stuij
> > Cc: llvm-dev
> > Subject: Re: [llvm-dev] amount of camelCase refactoring causing some
> downstream overhead
> >
> > My understanding is that LLVM's general policy is to not let
> > downstream slow down upstream development. The C++ API explicitly
> > unstable.
> >
> > Note that we are even considering renaming variables globally:
> > https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html
> >
> > Michael
> >
> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev
> > <llvm-dev at lists.llvm.org>:
> >> Hi there,
> >>
> >> At the end of last week we saw a number of commits go in that were
> camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions.
> >>
> >> For example:
> >> -
https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691
> >> -
https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b
> >> -
https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956
> >>
> >> Unfortunately all these individual commits trigger the same merge
> conflicts over and over again with our downstream repo, which takes us some
> manual intervention every time.
> >>
> >> I understand uniformity is a nice to have, but:
> >> 1 - is it worth it to do this work right now? I can remember the
casing
> debate a few months back, which seems unrelated to this work which seems
> manual, but I'm unsure of the outcome.
> >> 2 - If this work should be done, it would be nice if all of the
work is
> done in one batch, to save us some of the downstream overhead.
> >>
> >> Thanks
> >> /Ties
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200218/a0c13cc0/attachment.html>