[openstack-dev] [all] Why do we have project specific hacking rules?

Sean Dague sean at dague.net
Wed Oct 5 12:02:14 UTC 2016


On 10/03/2016 03:01 AM, Ihar Hrachyshka wrote:
> Andrew Laski <andrew at lascii.com> wrote:
>>
>> A further hindrance to moving these checks to be OpenStack wide is that
>> each check violation is a failure. So in order to roll a new check out
>> across projects it requires a lot of churn in each project which
>> violates the checks. I would prefer to leave it up to each project to
>> make the decision to incorporate a new check and take the review load.
>> Ultimately what I think sounds good would be a central listing of checks
>> that are in use across projects and then leave it up to each project to
>> replicate those that they like.
> 
> Late flake8 releases support off_by_default decorator that allows to add
> checks that are not triggered unless explicitly enabled in tox.ini with
> select= directive. That should allow to maintain code in single place
> while still having projects to opt-in new checks.

There could definitely be an effort to move more content up into hacking
proper. It would require some genericizing and need folks focused on it.

One of the challenges is realizing that hacking updates push out to 50+
projects. The project specific checks are often things where people have
gotten the point of getting bored -1ing people for the same issues over
and over again. Or using hacking a bit as a light weight unit test to
make sure certain code doesn't exist (all those "don't use this code"
checks).

Joe Gordon used to be pretty aggressive in moving these checks up into
hacking when they seemed to get enough concensus. But since he left the
community, there has been less push on this.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list