[llvm-dev] Formalize "revert for more design review" policy.

[Philip Reames via llvm-dev]

On 03/08/2016 09:30 PM, Xinliang David Li via llvm-dev wrote:
>
>
> On Tue, Mar 8, 2016 at 9:00 PM, Sean Silva <chisophugis at gmail.com 
> <mailto:chisophugis at gmail.com>> wrote:
>
>     Recently there's been some friction over reversions (I can
>     remember two cases in recent memory). In both issues the general
>     feel I got is that as a community we should honor "revert for more
>     design review" requests unconditionally.
>
>     What do you guys think of adding something like this to
>     DeveloperPolicy.rst as an item at the end of the numbered list in
>     http://llvm.org/docs/DeveloperPolicy.html#code-reviews ?
>
>     #. Sometimes patches get committed that need more discussion.
>        If a developer thinks that a patch would benefit from some more
>     review
>        and promptly communicates this, the patch should be reverted
>     (preferably
>        by the original author, unless they are unresponsive).
>        Developers often disagree, and erring on the side of the developer
>        asking for more review prevents any lingering disagreement over
>     code in
>        the tree.
>
>
> This is an interesting proposal. In practice, what I have seen is that 
> developers usually send out RFC (design of some kinds) to llvm-dev 
> long before the actual implementation, and the patch is submitted 
> after RFC did not get any objections.
Slightly OT, but I wanted to raise a related point for clarity. I've 
noticed a general trend to interpret RFCs without response as approval 
to move forward.  This is not what it means; more often its that either 
a) the RFC is so off base no one has the time to explain why or b) no 
one is interested enough in the feature to respond. It's the 
responsibility of the RFC author to get explicit agreement.  This can be 
annoying and frustrating, but it is necessary.  Most of the late design 
blockages I've seen over the last couple of months fall into this category.

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160309/5fe443ec/attachment-0001.html>