Open Stack

On 13 March 2015 at 17:36, Doug Hellmann <doug at doughellmann.com> wrote:


> I wish we, as a community, were less obsessed with creating so many
> hacking rules. These are really minor changes and it's going to be a
> relatively short-lived issue that could just be fixed once. If there's a
> regression, fixing *that* won't be hard or take long.
>
>
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:
- 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)
- Hacking checks don't slip up and miss one because they are reviewing at
1am the night before the deadline
- Regressions hurt, and not all of our code is covered by unit tests / CI
- 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)
- 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150315/e4788d32/attachment.html>