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

Tue Feb 18 18:30:43 PST 2020

On Tue, Feb 18, 2020 at 6:21 PM David Blaikie <dblaikie at gmail.com> wrote:

>
>
> 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.
>
>
Mostly the range of "broken" revisions as an example. That said, I also
very much want it to make sense rather than something else. :) I agree with
everything you've said anyhow.

-eric

> - 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/a3dd6d6e/attachment.html>