Open Stack

-----Original Message-----
From: Sean Dague <sean at dague.net>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: October 5, 2016 at 07:04:17
To: openstack-dev at lists.openstack.org <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Why do we have project specific hacking rules?

> On 10/03/2016 03:01 AM, Ihar Hrachyshka wrote:
> > Andrew Laski 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).

So hacking doesn't push out to anyone. It's one of the projects that doesn't get updated by global-requirements updates, if I remember correctly.

> 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.

The other problem with this is two-fold:

1. As one of the few people reviewing Hacking with more than a "The code looks good" point of view, it would be nice to have people from different projects affirming that more than one project would like the check in Hacking.

2. I'm not actually paid to work on Hacking or much upstream. What time I use to work on Hacking is my free time and that's already over-utilized.

If people think that absorbing all project-specific rules into Hacking is really that beneficial, I'd expect them to start participating a lot more actively in reviews of those changes. I won't have the time to pull down each one and verify it works as expected and won't break projects if it is enabled.

--  
Ian Cordasco