Comment 5 for bug 1609478

Reviewed: https://review.openstack.org/350723
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=d1a5ea03c28f0da5651c3432072396d1ea6195ba
Submitter: Jenkins
Branch: master

commit d1a5ea03c28f0da5651c3432072396d1ea6195ba
Author: Boden R <email address hidden>
Date: Wed Dec 7 14:11:33 2016 -0700

    Separate hacking check factories

    Neutron-lib adopters should be using neutron-lib's hacking
    checks (factory) to validate compliance, but are susceptible
    to breakage when new checks are released in neutron-lib (see
    partial bug). What we need is a way to roll-out adopter hacking
    checks in a controlled manner, giving consumers the opportunity
    and tools to comply with new checks.

    This patch begins to address this need by:
    - Separating neutron-lib hacking checks into 3 separate factories;
    adopter, incubating and neutron-lib internal (private).
    - Moving any existing checks into their respective factory.
    - Updating the usage docs on how to adopt our hacking checks.
    - Trusty ole unit test; for obvious reasons.

    This patch plays a part in a longer term hacking check strategy:
    - Adopters must run neutron-lib's hacking check factory() or its
    equivalent via their pep8 checks. This is part of their pep8 gate job
    once they update their tox.ini to use neutron's factory().
    - Adopters must run a non-voting neutron-lib-pep8-incubating gate job
    that runs pep8 with neutron-lib's incubating_factory(). This is means
    to warn adopters of upcoming checks without failing their gates.
    This job will be created (by me) assuming reviewers agree to this approach.
    - We'll communicate hacking checks via the standard means (see usage
    docs herein).

    Closure of Bug #1609478 will follow completion of the strategy above.

    Partial-Bug: #1609478
    Change-Id: I5b8d5c41f1bf463109baf9c26ae9d9db5719097d