<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 6:21 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.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 dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 4:39 PM Eric Christopher 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 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></blockquote><div><br>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.<br><br>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.<br><br></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>- Dave<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 dir="ltr"><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>
_______________________________________________<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></div>
</blockquote></div></div>