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

Eric Christopher via llvm-dev
Wed, 19 Feb 2020 02:30:43 -0000

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>