[llvm-dev] Documenting community norms around reverts

Felix venancio Aguilar lopez via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 24 16:14:38 PDT 2021


El mié., 24 de mar. de 2021 4:53 PM, Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> escribió:

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


More information about the llvm-dev mailing list