[llvm-commits] [llvm] r134907 - /llvm/trunk/utils/TableGen/

Chris Lattner clattner at apple.com
Tue Jul 12 21:15:20 PDT 2011


On Jul 12, 2011, at 12:14 PM, David A. Greene wrote:

> greened at obbligato.org (David A. Greene) writes:
> 
>> I'm all for code review, especially on complex patches.  That's why I
>> sent this one for review ahead of time.  But the submitter needs to get
>> at least some indication someone is looking at it in a timely manner.
>> Otherwise the submitter is completely in the dark.
> 
> I think what might work is the following:
> 
> - Within 16 working hours after a review request is sent, the relevant
>  code owner either sends a review or sends an acknowledgement that the
>  request was received.  Either type of response should indicate that
>  the responder is the code owner (so the sumitter knows who has final
>  say).
...

> - Following the ping, the submitter should wait an additional eight
>  working hours.  If there is no response forthcoming, the submitter may
>  commit the patch which is then subject to post-commit review.
> 
> Does this sound reasonable?

No, this doesn't.  Not at all.  "If there is no response forthcoming, the submitter may commit the patch" is tantamount to ignoring process.

I understand where you're coming from and how frustrating it must be to have a bunch of changes that you want to push in that aren't getting reviewed.  As discussed elsewhere on the thread, there are *very* specific things that you can do to improve the chances of your patch being looked at promptly.  There are lots of patches that are going in right away and getting promptly reviewed, largely because there is an inverse correlation between the complexity of a patch and the likelihood that someone will want to look at it.

> This will at least give a predictable timeframe for the submitter.  As
> it is now, people who submit code are lost as to when things might move
> forward.  That makes scheduling and planning very difficult.

I understand, but the policy of the project is not based around the submitter's schedule.  While I imagine that it is *extra* frustrating to hear this, the policies of the project are aimed at making sure the *right code* goes in, not in *reducing barriers* to submission.  Having a high quality bar is a good thing.

That said, not getting prompt review is a bug, not a feature.  The reality is that we're all human, and all busy.  Part of working successfully with the project is finding ways that increase the odds that someone will say "go ahead and commit, it seems obvious".  Separating trivial and mechanical changes from the "interesting" ones is a great way to do that.  Making the "interesting" changes tiny is another great way.

-Chris 




More information about the llvm-commits mailing list