d1a5ea03c2
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
8 lines
248 B
YAML
8 lines
248 B
YAML
---
|
|
features:
|
|
- The hacking check factory ``incubating_factory`` has been added
|
|
to ``neutron_lib.hacking.checks`` allowing adopters to test
|
|
compliance on incubating hacking checks. See the usage documentation
|
|
for additional details.
|
|
|