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

Tue Feb 18 18:21:41 PST 2020

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>