Open Stack

On Wed, May 9, 2018 at 2:23 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> (I added the [qa] topic tag for the QA team, since they own hacking, and
> [requirements] for that team since I have a question about capping.)
>
> Excerpts from Julia Kreger's message of 2018-05-08 12:43:07 -0400:
>> About two hours ago, we started seeing Ironic CI jobs failing pep8
>> with new errors[1]. For some of our repositories, it just seems to be
>> a couple of lines that need to be fixed. On ironic itself, supporting
>> this might have us dead in the water for a while to fix the code in
>> accordance with what hacking is now expecting.
>>
>> That being said, dtantsur and dhellmann have the perception that new
>> checks are supposed to be opt-in only, yet this new hacking appears to
>> have at W605 and W606 enabled by default as indicated by discussion in
>> #openstack-release[2].
>>
>> Please advise, it seems like the release team ought to revert the
>> breaking changes and cut a new release as soon as possible.
>>
>> -Julia
>>
>> [1]: http://logs.openstack.org/87/557687/4/check/openstack-tox-pep8/75380de/job-output.txt.gz#_2018-05-08_14_46_47_179606
>> [2]: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2018-05-08.log.html#t2018-05-08T16:30:22
>>
>
> As discussed in #openstack-release, those checks are pulled in via
> pycodestyle rather than hacking itself, and pycodestyle doesn't have an
> opt-in policy.
>
> Hacking is in the blacklist for requirements management, so teams
> *ought* to be able to cap it, if I understand correctly. So I suggest at
> least starting with a patch to test that.
>
> Doug

Sorry for inconvenience but i agree with Doug on capping the hacking
on project side. hacking in blacklist and never be in g-r sync list
was to avoided the situation like this. hacking compatible version and
cap is maintained by project side only as per their source code.
Almost all the project has capped the hacking version in their
test-requirements.txt and update the version as when project team want
& code is passing the new rules. For example [1].

It is difficult for QA team or release team to verify that hacking
release will not break anyone with new version even there is no new
rule addition in hacking (like this time failure are caused by
pycodestyle). To avoid such failure in future, i am on side of capping
the hacking on project side like majority of the project does. I
searched manually and found below repo which does not cap the
hacking[2].

I am giving try to cap the version on those repo. Project team can
decide and merge them to fix the current gate as well as to avoid such
situation in future.

- https://review.openstack.org/#/q/topic:cap-hacking+(status:open+OR+status:merged)


FYI- W503 was raising failure even before hacking release which was
fixed in Tempest a month ago. [3]


..1 https://review.openstack.org/#/c/397486/

..2
http://codesearch.openstack.org/?q=hacking&i=nope&files=test-requirements.txt&repos=
1. openstack/fuel-ccp-installer
2. openstack/fuel-ccp-tests
3. openstack/ironic
4. openstack/ironic-inspector
5. openstack/ironic-lib
6. openstack/ironic-python-agent
7. openstack/python-ironic-inspector-client
8. openstack/python-ironicclient
9. openstack/kolla-ansible
10. openstack/monasca-analytics
11. openstack/networking-generic-switch
12. openstack/patrole
13. openstack/pyghmi
14. openstack/rally
15. openstack/rally-openstack
16. openstack-infra/storyboard
17. openstack/sushy


.. 3 https://review.openstack.org/#/c/560360/

-gmann

>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev