<div dir="ltr">On Sun, Feb 3, 2013 at 12:49 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:31 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<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><div>It is clearly more work.</div></div></div></blockquote><div><br></div></div><div>How so? Every (non-science) open source project I've worked with expects this sort of workflow.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">

<div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">


<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></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></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<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></blockquote><div><br></div></div><div>[citation needed]</div><div><br></div>

<div><a href="http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/" target="_blank">http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/</a></div></div></div></div></blockquote><div><br>
</div><div style>Notice here that "Informal code review" is the second worst form of checking by percentage of bugs</div><div style>found, and thus would appear to be an inefficient way to go about things. Formal code review does not</div>
<div style>happen every checkin, but only after a significant amount of work goes into the project. He makes a</div><div style>big deal about catching bugs early, which is a good point, but not the point here.</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><br></div><div><a href="http://en.wikipedia.org/wiki/Code_review" target="_blank">http://en.wikipedia.org/wiki/Code_review</a><br>

</div><div><a href="http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html" target="_blank">http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html</a></div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<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></blockquote><div><br></div></div><div>My view is that the history should _be the organization_. If you want to organize it differently, please suggest an alternative system.</div>
</div></div></div></blockquote><div><br></div><div style>Formal code review, which we had to do at Akamai, were organized meetings with all the developers, where</div><div style>we got a schedule of code to review, for what functionality, and with what aim in mind.</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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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>

</blockquote><div><br></div></div><div>The amount of process is proportional to the required stability and number of developers and users. A bug in kernel 'master' is an extremely bad thing. Even when fixed the same day, it can cost many thousands of dollars (it interrupts development for many developers and tends to discourage early adopters). PETSc is not such critical infrastructure, but I think it would be good to offer a more reliable low-latency way to interact with applications, which in turn requires more stability. Also, bugs that make it into a release are much more expensive than bugs fixed early, even without counting the indirect effect of discouraging users.</div>

<div><br></div><div>I'm not proposing the full kernel workflow, but having slightly better feature provenance and encouraging up-front review would be good.</div></div></div></div></blockquote><div><br></div><div style>
I am not proposing anarchy. I think everyone should push code with no warnings. We see from the nightly</div><div style>tests that it does not happen, but I am sure a timeline will reveal it is much better today. I agree that people</div>
<div style>should try to keep features together in coherent checkins. I label all my checkins at the top with the components</div><div style>that they impact. However, imposing an iron rule seems unwarranted, and I think its clear that hard rules and</div>
<div style>lots of process can have bad side effects (witness the reasonable sounding rule to MS that all checkins must</div><div style>pass the test suite, which resulted in horrible hacking to accomplish that).</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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_extra"><br></div><div class="gmail_extra">Warnings: I did respond to that, so its not worth repeating here.</div></blockquote></div></div><br>Only that you "try not to".</div></div>
</blockquote></div><br>What else could I possibly promise? Promising infallibility shows a lack of understanding of the problem.</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>