> On Mar 15, 2015, at 7:35 AM, Duncan Thomas <duncan.tho...@gmail.com> wrote: > > On 13 March 2015 at 17:36, Doug Hellmann <d...@doughellmann.com > <mailto:d...@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.
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. 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. 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. Doug > > 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. > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
