[llvm-dev] amount of camelCase refactoring causing some downstream overhead

David Blaikie via llvm-dev
Wed, 19 Feb 2020 02:21:41 -0000

On Tue, Feb 18, 2020 at 4:39 PM Eric Christopher via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Philip,
>
> While it's true we don't I think Valentin is reasonable in saying
"hey,
> when people do this let's try to combine them if it makes sense".
It's just
> being polite to everyone, especially if it doesn't risk the patches or
> upstream stability. I don't think there's a policy change being
proposed,
> just a "hey, let's see what we can do in the future".
>

I think the somewhat unspoken change in LLVM social conventions (& somewhat
policy, I think it's written down in some places) is the "keep patches
as
small as practically possible" - grouping unrelated renamings would be
something I'd usually (without concern for downstream consumers) push back
against for all the usual reasons: easier to review, easier to revert
strategically if something goes wrong, etc.

What I'm not clear on is why one big rename patch is easier for a
downstream consumer than two smaller renames - I haven't fully understood
the nature of this particular downstream consumer's approach makes this
interesting.

- Dave


>
> -eric
>
> On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Valentin,
>>
>> You are proposing to change existing policy.  Current policy is that we
>> don't consider downstream *at all*.  Your proposal may seem
reasonable - it
>> may even *be* reasonable - but it is definitely a change from
historical
>> practice and must be considered as such.
>>
>> Philip
>> On 2/18/20 3:03 PM, Valentin Churavy wrote:
>>
>> 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
>>>
>> _______________________________________________
>> 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/cc7e1144/attachment.html>