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

Neil Nelson via llvm-dev
Wed, 19 Feb 2020 20:24:08 -0000

Philip,

This statement "The current policy is "downstream is on their
own"."
appears to have gotten out of hand.

LLVM for this thread is a production line, a pipeline, a team operation.
Of course each person in the team has their own responsibility but there
is never a team member who is on their own. There is never a position on
the production line that does not depend on all the other positions in
order to keep the production line running. At some point all the members
depend on and are responsible for all the other members and for the
success of the team.

This is not policy. It is merely a fact of life for this kind of
organization.

Neil Nelson

On 2/19/20 12:07 PM, Philip Reames via llvm-dev 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 <mailto: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 <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
>>>
>>     _______________________________________________
>>     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
> 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/6e051d5f/attachment.html>