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

Eric Christopher via llvm-dev
Wed, 19 Feb 2020 19:25:36 -0000

Hi Philip,

You and I are going to disagree then. Strongly and strenuously every time.
As someone who has reiterated the same policy multiple times I don't see
anything around "try to make it easy on downstream if you can without
making it harder for upstream" that contradicts any policy or even tries to
set anything. There is no policy under discussion, just a "hey, see if you
can do this in a friendly way" next time is just fine. If you and I
can't
agree on that then I really see no point in discussing anything further
with you.

-eric

On Wed, Feb 19, 2020 at 11:07 AM Philip Reames <listmail at
philipreames.com>
wrote:

> Eric,
>
> I disagree.  Strongly.   I see the very fact we're engaging in the
> discussion of "just being polite" here as normalizing a proposed
change in
> policy which has potentially profound negative consequences for the project
> long term.  I do not want upstream developers "trying to be
polite" if that
> delays otherwise worthwhile work.  The current policy is "downstream
is on
> their own".  There was nothing even remotely unreasonable done in the
patch
> series which triggered this discussion and I don't want any upstream
> contributor coming to believe there was.
>
> Again, I'm open to carefully weighted proposals to change current
policy.
> I also have a downstream repo which is kept up to date and I understand the
> pain point being raised.  I just want to be very careful to distinguish
> between existing status, and any proposed changes.  I want the proposed
> changes to be carefully weighed before being put into effect.
>
> Philip
> On 2/18/20 4:39 PM, Eric Christopher 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".
>
> -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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200219/5f69b650/attachment.html>