<div dir="ltr"><ul style="padding:0px;margin:0.3em 0px 0px 1.6em;color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px"><li><br></li></ul><div class="gmail_extra"><div class="gmail_quote">
On Thu, Aug 15, 2013 at 12:22 PM, Sam Harwell <span dir="ltr"><<a href="mailto:sam.harwell@rackspace.com" target="_blank">sam.harwell@rackspace.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 lang="EN-US" link="blue" vlink="purple">
<div>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I like to take a different approach. If my commit message is going to take more than a couple lines for people to understand the decisions I made, I go and
make an issue in the issue tracker before committing locally and then reference that issue in the commit message. This helps in a few ways:<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>1.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">If I find a technical or grammatical error in the commit message, it can be corrected.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>2.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Developers can provide feedback on the subject matter independently of the implementation, as well as feedback on the implementation itself.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>3.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I like the ability to include formatting and hyperlinks in my documentation of the commit.<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> </span></p></div></div></blockquote><div><br></div><div>This pattern has one slight issue, which is:</div><div> </div><div><ul style="padding:0px;margin:0.3em 0px 0px 1.6em;color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">
<li><b>Do not assume the reviewer has access to external web services/site.</b></li></ul><p style="margin:0px 0px 10px;color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">
In 6 months time when someone is on a train/plane/coach/beach/pub troubleshooting a problem & browsing GIT history, there is no guarantee they will have access to the online bug tracker, or online blueprint documents. The great step forward with distributed SCM is that you no longer need to be "online" to have access to all information about the code repository. The commit message should be totally self-contained, to maintain that benefit.</p>
<p style="margin:0px 0px 10px;color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px"><br></p><p style="margin:0px 0px 10px;color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">
<a href="https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages" target="_blank">https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages</a><br></p><div class="gmail_extra">
<br></div></div>
<div><br></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 lang="EN-US" link="blue" vlink="purple">
<div><p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Sam<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Christopher Yeoh [mailto:<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, August 15, 2013 7:12 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] Code review study<u></u><u></u></span></p><div><div>
<p><u></u> <u></u></p>
<div>
<div>
<p><u></u> <u></u></p>
<div>
<p>On Thu, Aug 15, 2013 at 11:42 AM, Robert Collins <<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p style="margin-bottom:12pt">This may interest data-driven types here.<br>
<br>
<a href="https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/" target="_blank">https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/</a><u></u><u></u></p>
</div>
<p style="margin-bottom:12pt">Note specifically the citation of 200-400 lines as the knee of the review effectiveness curve: that's lower than I thought - I thought 200 was clearly fine - but no.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>Very interesting article. One other point which I think is pretty relevant is point 4 about getting authors to annotate the code better (and for those who haven't read it, they don't mean comments in the code but separately) because it
results in the authors picking up more bugs before they even submit the code.<br>
<br>
So I wonder if its worth asking people to write more detailed commit logs which include some reasoning about why some of the more complex changes were done in a certain way and not just what is implemented or fixed. As it is many of the commit messages are
often very succinct so I think it would help on the review efficiency side too.<u></u><u></u></p>
</div>
<div>
<p> <u></u><u></u></p>
</div>
<div>
<p style="margin-bottom:12pt">Chris<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>