<div dir="auto"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié., 24 de mar. de 2021 4:53 PM, Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div>
    <p>I've <a href="https://reviews.llvm.org/D99305" target="_blank" rel="noreferrer">posted a patch</a> to
      document our norms around reverts.  I was recently surprised to
      not find anything in this spirit.  A lot of newcomers find our
      norms a bit odd, so having this explicitly spelled out seems very
      worthwhile.</p>
    <p>I tried to stick to stuff that is uncontroversial in the
      community. If you see something here that less than 90+% of the
      community would agree with, please point it out. I'll remove it
      for now, and possibly return to individual points if warranted in
      future reviews.</p>
    <p>Philip</p>
    <p>p.s. Draft text follows, but please make detailed wording
      suggestions on the review.</p>
    <p>Reverts<br>
      -------<br>
      <br>
      As a community, we strongly value having the tip of tree in a good
      state.  As<br>
      such, we tend to make much heaver use of reverts than some other
      open source<br>
      projects, and our norms are a bit different.<br>
      <br>
      When should you revert your own change?<br>
      <br>
      * Any time you learn of a serious problem with a change, you
      should revert it.<br>
        We strongly encourage "revert to green" as opposed to "fixing
      forward".  We<br>
        encourage reverting first, investigating offline, and then
      reapplying the<br>
        fixed patch - possibly after another round of review if
      warranted.<br>
      * If you break a buildbot in a way which can't be quickly fixed,
      please revert.<br>
      * If a test case is reported in the commit thread which
      demonstrates a problem<br>
        please revert, and investigate offline.<br>
      * If you are asked to revert by another contributor, please revert
      and discuss<br>
        the merits of the request offline (unless doing so would further
      destabilize<br>
        trip of tree).<br>
      <br>
      When should you revert someone else's change?<br>
      <br>
      * In general, if the author themselves would revert the change per
      these<br>
        guidelines, we encourage other contributors to do so as a favor
      to the<br>
        author.  This is one of the major cases where our norms differ
      from others;<br>
        we generally consider reverting someones change to be a favor to
      them.  We<br>
        don't expect contributors to be always available, and the
      assurance that a<br>
        problematic patch will be reverted and we can return to it at
      our next<br>
        opportunity enables this.<br>
      * The other case for a third-party revert is for serious norm
      violations.  As a<br>
        general rule, you should never be reverting a patch for this
      unless you've<br>
        already started a discussion highlight the problem on the
      original commit<br>
        thread.  There are exceptions where a rapid revert for a norm
      violation may<br>
        be called for, but if those are relevant for you, you already
      know.<br>
      <br>
      What are the expectations around a revert?<br>
      <br>
      * You should be sure that reverting the change improves the
      stability of tip<br>
        of tree.  Sometimes reverting one change in a series can worsen
      things<br>
        instead of improving them.  We expect reasonable judgment to
      ensure that<br>
        the proper patch or set of patches is being reverted.<br>
      * You should have a publicly reproducible test case ready to
      share.  It is<br>
        not considered reasonable to revert without at least the promise
      to produce<br>
        a public test case in the near term.  We encourage sharing of
      test cases in<br>
        commit threads, or in PRs.  We encourage the reverter to
      minimize the test<br>
        case and to prune dependencies where practical.<br>
      * Reverts should be reasonably timely.  A change submitted two
      hours ago<br>
        can be reverted by a third-party without prior discussion.  A
      change<br>
        submitted two years ago probably shouldn't be.  Where exactly
      the transition<br>
        point is is hard to say, but it's probably in the handful of
      days in tree<br>
        territory.    If you are unsure, we encourage you to reply to
      the commit<br>
        thread, give the author a bit to respond, and then proceed with
      the revert<br>
        if the author doesn't seem to be actively responding.<br>
      <br>
      How should you respond if someone reverted your change?<br>
      <br>
      * In general, the appropriate response is to start by thanking
      them.  If you<br>
        need more information to address the problem, please follow up
      in the<br>
        original commit thread with the reverting patch author.<br>
      * It is normal and healthy to have patches reverted.  Having a
      patch reverted<br>
        does not neccessarily mean you did anything wrong.<br>
      <br>
    </p>
  </div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">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>