our websocket server is a derivative of mod_pywebsocket and we should either upstream our changes or create a version that is a package for reuse and upload it here: http://puppetagain.pub.build.mozilla.org/data/python/packages/ (as per https://bugzilla.mozilla.org/show_bug.cgi?id=770718#c32). Once we have that, we can use the package in talos to run the websocket tests.

I wasn't even aware we had changes. Is there any reason not to fork? Other strategies are also outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=770718#c32 . Another thing that I just thought of....if we make the package a tarball, it could "live" (or at least hangout until we make our packaging story better) in m-c AND talos could point to it via dependency_links. Granted, see above link for several things we would have to do first (setup.py, not doing crazy things with standalone.py, etc). And we would have to run mochitest in a virtualenv with the package installed (which we should do anyway) and/or unpack the tarball and through whatever mechanism add to sys.path

The only real change we're doing to pywebsocket (other than keeping one file, standalone.py, in a different location, which we could fix) is that we have one little kludge to allow us to test HSTS (HTTPS everywhere) headers. See http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/pywebsocket/README-MOZILLA#35 I'd be fine with trying to get that patch upstream. That said, it doesn't take much to apply the patch when we need to upgrade (which has only been once or twice, but it's likely to happen again someday). I'd avoid any fork that makes it difficult to upgrade from the original project--there's a good chance we'll want to upgrade from it. But something non-invasive that lets us use same code in talos would be fine.

(In reply to Jason Duell (:jduell) from comment #2) > The only real change we're doing to pywebsocket (other than keeping one > file, standalone.py, in a different location, which we could fix) is that we > have one little kludge to allow us to test HSTS (HTTPS everywhere) headers. > See > > > http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/pywebsocket/ > README-MOZILLA#35 > > I'd be fine with trying to get that patch upstream. That said, it doesn't > take much to apply the patch when we need to upgrade (which has only been > once or twice, but it's likely to happen again someday). I've ticketed upstream: https://code.google.com/p/pywebsocket/issues/detail?id=127 Since I know nothing about this code, it would be good if someone that did would follow up on this. > I'd avoid any fork that makes it difficult to upgrade from the original > project--there's a good chance we'll want to upgrade from it. But something > non-invasive that lets us use same code in talos would be fine. We have already forked into mozilla-central. Without covering the whole gamut of esoterica.... * if we had this in its own hg repository it would be doable to install packages from it easily * such a repository could be updated as needed from the canonical source. Either the https://code.google.com/p/pywebsocket owners will be active wrt our patches....or they won't. In the latter case, a fork is our only sane option. In the former case, hopefully a fork is a temporary measure. * we will want/need to get this installed in the python path so that we don't have to move standalone.py. virtualenv, my dear brothers

I've ticketed getting this in existing mochitest. We'll want to do this with or without forking or other upstreamy issues: bug 824853

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258