
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 15, 2015, at 7:35 AM, Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com" class="">duncan.thomas@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 13 March 2015 at 17:36, Doug Hellmann <span dir="ltr" class=""><<a href="mailto:doug@doughellmann.com" target="_blank" class="">doug@doughellmann.com</a>></span> wrote:<br class=""><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wish we, as a community, were less obsessed with creating so many<br class="">

hacking rules. These are really minor changes and it's going to be a<br class="">

relatively short-lived issue that could just be fixed once. If there's a<br class="">

regression, fixing *that* won't be hard or take long.<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">Ok, this comment has peaked my interest again, since I hold pretty much the exact opposite view and am a well known fan of hacking checks. My logic is:</div><div class="">- Hacking checks point out the error for most submitters before review, saving reviewer time and CI cycles, and increasing the comfort level of the submitter (for most people, a -1 feels harsh/negative)</div><div class="">- Hacking checks don't slip up and miss one because they are reviewing at 1am the night before the deadline</div><div class="">- Regressions hurt, and not all of our code is covered by unit tests / CI</div><div class="">- Debugging the output of a hacking check is many times faster than debugging a unit test, even for simple failures (and work is underway to may this even faster)</div><div class="">- Hacking checks that are left around for migrations like this even a few cycles longer than they are needed have zero cost. As long as nobody type 'oslo.foo' then they never need even know of their existence. We can be really lazy about removing them with no harm at all.</div></div></div></div></div></blockquote><div><br class=""></div><div>My comment was based on the observation that we have gone farther than I think is helpful with the checks, because we’ve started holding up other work until new checks can be implemented. That means we’re placing a higher priority on building our own tools than on building the thing we set out to build in the first place.</div><div><br class=""></div><div><div>When I updated tempest to use the graduated libraries instead of incubated code I did most of the work with a few calls to “sed -i”. I also didn’t have to wait for the hacking check to be implemented before I could start the cleanup/graduation work, which means now the work in tempest is *done* and I can move on to other work.</div><div class=""><br class=""></div></div><div>Sometimes adding automation helps because of the need for an ongoing check, but in this case I don’t think it is warranted because of the nature of the change. If we successfully remove the namespace package next cycle and a regression is introduced before then, then broken imports just won’t work and the reason will be clearly stated in the error message Python gives. The problem is both easy to diagnose and easy to fix. We don’t need another check for that.</div><div><br class=""></div><div>Doug</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Am I missing something? I am a general proponent of 'write hacking checks for any mechanical code change'. We've seen definite benefits from this approach and few to no downsides that I'm aware of.</div></div>

</div></div>

__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></body></html>