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

Tue Feb 18 16:05:31 PST 2020

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 <mailto: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
>     <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/ffa156ea/attachment.html>