neutron-lib/releasenotes/notes/separate-hacking-factories-6fc36b38de95662a.yaml
Boden R d1a5ea03c2 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
2016-12-07 14:38:39 -07:00

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.