<div dir="ltr"><div><span style="font-size:12.8000001907349px">David, </span></div><div><br></div><div><br></div><div><blockquote 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" class="gmail_quote">1. It will either lead to people doing things to game the system or overuse of the #<span style="font-size:12.8000001907349px">no-</span><span style="font-size:12.8000001907349px">coverage</span><span style="font-size:12.8000001907349px">-check  tag you mentioned.</span></blockquote></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Job doesn't force people to increase coverage, it just checks that it was not decreased. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Btw according to the latest refactoring, we are using absolute values missing lines, so now we don't need #no-coverage-check at all. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><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"><span style="font-size:12.8000001907349px">2. It really doesn't tell you too much. A core developer should really be looking at the tested use cases to see if they are all there. Line coverage and even branch coverage won't tell you that. </span></blockquote><div><br></div><div>It saves a lot of time.</div><div><br></div><div>1) I don't want to review patches that are not fully covered by tests (they just won't be merged in any case). </div><div>    Checking by eyes takes in average 2 minutes. I am doing 750 reviews / release.</div><div>    This automation saves about ~25 hours / release, that can be spend on analyze and reviewing of unit tests code quality. </div><div>    If we assume that in </div><div><br></div><div>2) It simplify dev process:</div><div><br></div><div>    I write my code. Before publishing I just run "tox -ecover" that shows not fully covered files in my change. </div><div><br></div><div>3) It reduce usage of CI hardware and reduce amount of patch sets </div><div><br></div><div>    If "tox" runs cover job by default, most developers will make it pass before sending patch on review. </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 22, 2015 at 5:00 PM, David Stanek <span dir="ltr"><<a href="mailto:dstanek@dstanek.com" target="_blank">dstanek@dstanek.com</a>></span> wrote:<br><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"><span class=""><br><div class="gmail_quote">On Sat, Apr 18, 2015 at 9:30 PM, Boris Pavlovic <span dir="ltr"><<a href="mailto:boris@pavlovic.me" target="_blank">boris@pavlovic.me</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>Code <span>coverage</span> is one of the very important metric of overall code quality especially in case of Python. It's quite important to ensure that code is <span>covered</span> fully with well written unit tests. </div><div><br></div><div>One of the nice thing is <span>coverage</span> job. </div></blockquote></div><br></span>I really like the idea of adding the coverage job everywhere so that developers can view the results be using a link in Gerrit. I think this would make it easier for many.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't like the idea of checking that coverage is increased. There are many issues with that. The two biggest one for me are:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1. It will either lead to people doing things to game the system or overuse of the #<span style="font-size:12.8000001907349px">no-</span><span style="font-size:12.8000001907349px">coverage</span><span style="font-size:12.8000001907349px">-check  tag you mentioned.</span><br></div><div class="gmail_extra"><span style="font-size:12.8000001907349px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8000001907349px">2. It really doesn't tell you too much. A core developer should really be looking at the tested use cases to see if they are all there. Line coverage and even branch coverage won't tell you that. <span class="HOEnZb"><font color="#888888"><br></font></span></span><span class="HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div>David<br>blog: <a href="http://www.traceback.org" target="_blank">http://www.traceback.org</a><br>twitter: <a href="http://twitter.com/dstanek" target="_blank">http://twitter.com/dstanek</a><div>www: <a href="http://dstanek.com" target="_blank">http://dstanek.com</a></div></div>
</font></span></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>