<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Philip,</p>
    <p>This statement "The current policy is "downstream is on their
      own"." appears to have gotten out of hand.</p>
    <p>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.</p>
    <p>This is not policy. It is merely a fact of life for this kind of
      organization.<br>
    </p>
    <p>Neil Nelson<br>
    </p>
    <div class="moz-cite-prefix">On 2/19/20 12:07 PM, Philip Reames via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:71afee99-d94b-5366-b126-66857d5dcc88@philipreames.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <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 class="moz-cite-prefix">On 2/18/20 4:39 PM, Eric Christopher
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CALehDX5CFkFORr5HMS43LZ0wQ+SiqgoQSJ=OhZ6OfOu7CbaOTw@mail.gmail.com">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <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"
              moz-do-not-send="true">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" moz-do-not-send="true">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"
                      moz-do-not-send="true">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"
                      moz-do-not-send="true">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"
                      moz-do-not-send="true">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"
                      moz-do-not-send="true">https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691</a><br>
                    >> - <a
href="https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b"
                      rel="noreferrer noreferrer" target="_blank"
                      moz-do-not-send="true">https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b</a><br>
                    >> - <a
href="https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956"
                      rel="noreferrer noreferrer" target="_blank"
                      moz-do-not-send="true">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"
                      moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
                    >> <a
                      href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
                      rel="noreferrer noreferrer" target="_blank"
                      moz-do-not-send="true">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"
                      moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
                    > <a
                      href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
                      rel="noreferrer noreferrer" target="_blank"
                      moz-do-not-send="true">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"
                      moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
                    <a
                      href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
                      rel="noreferrer noreferrer" target="_blank"
                      moz-do-not-send="true">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"
              moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
            <a
              href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
          </blockquote>
        </div>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </body>
</html>