<div dir="ltr">Hi Philip,<div><br></div><div>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.</div><div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 11:07 AM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Eric,</p>
<p>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.</p>
<p>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. <br>
</p>
<p>Philip</p>
<div>On 2/18/20 4:39 PM, Eric Christopher
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Philip,
<div><br>
</div>
<div>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".</div>
<div><br>
</div>
<div>-eric</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 4:05
PM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Valentin,</p>
<p>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. <br>
</p>
<p>Philip<br>
</p>
<div>On 2/18/20 3:03 PM, Valentin Churavy wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">I don't think anyone is arguing to change
longstanding policy. From a downstream perspective many
small renaming changes do increase overhead for us.
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">-V</div>
<div dir="auto"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020,
17:00 Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As others have
said, our long standing policy has been that
downstream <br>
projects must fend for themselves. We're certainly
not going to reverse <br>
that policy without careful discussion of the
tradeoffs.<br>
<br>
I'm personally of the opinion that there could be a
middle ground which <br>
allows upstream to move quickly while reducing
headache for downstream <br>
projects. Given I wear both hats, I know I'd
certainly appreciate such <br>
a state. However, it's important to state that such
decisions would <br>
need to be carefully considered and would require some
very careful <br>
drafting of proposal to balance the competing
interests at hand.<br>
<br>
If anyone is curious, I'm happy to share some ideas
offline on what <br>
starting points might be, but I have neither the time
nor the interest <br>
to drive such a conversion on list.<br>
<br>
Philip<br>
<br>
On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote:<br>
> 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.<br>
><br>
> 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.<br>
><br>
> Cheers,<br>
> /Ties<br>
><br>
> ________________________________________<br>
> From: Michael Kruse <<a href="mailto:llvmdev@meinersbur.de" rel="noreferrer" target="_blank">llvmdev@meinersbur.de</a>><br>
> Sent: 17 February 2020 21:16<br>
> To: Ties Stuij<br>
> Cc: llvm-dev<br>
> Subject: Re: [llvm-dev] amount of camelCase
refactoring causing some downstream overhead<br>
><br>
> My understanding is that LLVM's general policy is
to not let<br>
> downstream slow down upstream development. The
C++ API explicitly<br>
> unstable.<br>
><br>
> Note that we are even considering renaming
variables globally:<br>
> <a href="https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html</a><br>
><br>
> Michael<br>
><br>
> Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties
Stuij via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>>:<br>
>> Hi there,<br>
>><br>
>> 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.<br>
>><br>
>> For example:<br>
>> - <a href="https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691</a><br>
>> - <a href="https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b</a><br>
>> - <a href="https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956</a><br>
>><br>
>> 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.<br>
>><br>
>> I understand uniformity is a nice to have,
but:<br>
>> 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.<br>
>> 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.<br>
>><br>
>> Thanks<br>
>> /Ties<br>
>>
_______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>