<div dir="ltr">On Sun, Feb 3, 2013 at 12:24 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>Its more work for me. Clearly you are asking me to do something I do not currently do. A loss.</div>

</div></blockquote><div><br></div></div><div>How is _not typing 'hg merge' or 'hg pull'_ harder than typing it? Do your work in a bookmark and merge it when it's ready for review. It's not a hard concept.</div>
</div></div></div></blockquote><div><br></div><div style>It is clearly more work.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra">There are no "gains" from a baseline. This is</div><div class="gmail_extra">a point I have made multiple times. Changes must be justified.</div>
<div class="gmail_extra"></div></blockquote></div></div><br>I provided a long list of justifications that you have not responded to. There is a great deal of empirical evidence to back my claims.</div></div>
</blockquote></div></div><br>I have responded to each and every point carefully. You need to listen.</blockquote></div></div><br>You have not said anything about reviewability, actual bug rates, extensibility, ability to recognize distinct features in the history, or realized and perceived stability and lack of spurious warnings when users pull petsc-dev.</div>

</div>
</blockquote></div><br>Reviewability: I have responded that a) you are reviewing at the wrong time, and b) your second example was a perfectly reviewable checkin which resulted in an easy fix.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Actual bug rates:  you have not offered any evidence here, so my assertion is that they do not decrease</div><div class="gmail_extra"><br></div><div class="gmail_extra">Extensibility: Your assertion is that extensibility benefits from code review. I agree. You are reviewing at the wrong time. Code reviews</div>
<div class="gmail_extra">should be organized, not carried out after every checkin.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ability to recognize distinct features in history: I do not think this is worth preserving at the cost of a lot more process. This is the linux model where everything is smoothed out into a series of clean patches. We have explicitly chosen not to do this. It obscures the actual development process and I am not convinced it is as useful here as they claim in the kernel.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Warnings: I did respond to that, so its not worth repeating here.</div><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<br clear="all"><div><br>
</div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener
</div></div>