Looks like I'll need to update revscoring for some work that @Ladsgroup is doing for editquality. See https://github.com/wiki-ai/editquality/pull/111

https://github.com/wiki-ai/wikiclass/pull/57
https://github.com/wiki-ai/draftquality/pull/16

I'm waiting on @Ladsgroup to finish up the changes to editquality and then we'll be complete.

Change 401822 had a related patch set uploaded (by Halfak; owner: halfak):
[research/ores/wheels@master] Rebuilds wheels using Debian Stretch

https://gerrit.wikimedia.org/r/401822

https://github.com/wiki-ai/ores/pull/245

Change 401822 merged by Ladsgroup:
[research/ores/wheels@master] Rebuilds wheels using Debian Stretch

https://gerrit.wikimedia.org/r/401822

Just tried using the wheel on stretch in the new ORES cluster and I get

MarkupSafe-1.0-cp34-cp34m-linux_x86_64.whl is not a supported wheel on this platform.

@akosiaris Our Stretch patches are available on the stretch_conversion branch. That includes Python 3.5 wheels...

In T184135#3952838, @awight wrote:

@akosiaris Our Stretch patches are available on the stretch_conversion branch. That includes Python 3.5 wheels...

Just tried this, it did not work. On the contrary, I still get

MarkupSafe-1.0-cp34-cp34m-linux_x86_64.whl is not a supported wheel on this platform.

stretch_conversion on tin seems to not be using does not yet use a valid for stretch commit from the wheels submodule (i.e. https://phabricator.wikimedia.org/source/ores-deploy-wheels/) but it is still using d7fa640c59aebc3c080b43516c76235e1fca5cf9. I 'd use master but I 'd rather you gave a thumbs up on this before I proceed.

I am guessing we can call this resolved with the stretch_conversion branch is merged into master ?