<div dir="auto"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié., 24 de mar. de 2021 5:14 PM, Felix venancio Aguilar lopez <<a href="mailto:felixvenanancio676@gmail.com">felixvenanancio676@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank" rel="noreferrer">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" rel="noreferrer noreferrer" target="_blank">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" rel="noreferrer 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 noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>