)]}'
{"release_postversion.sh":[{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"744065d47eef106cc9b344735f324d1535e57b84","unresolved":false,"context_lines":[{"line_number":192,"context_line":"        REQREPODIR\u003d\"$(realpath requirements)\""},{"line_number":193,"context_line":"    fi"},{"line_number":194,"context_line":"    cd $REQREPODIR"},{"line_number":195,"context_line":"    tox -e venv -- edit-constraints upper-constraints.txt $DISTNAME \"${DISTNAME}\u003d\u003d${VERSION}\""},{"line_number":196,"context_line":"    git commit -a -m \"Update $DISTNAME for new release $VERSION\""},{"line_number":197,"context_line":"    git review"},{"line_number":198,"context_line":"fi"}],"source_content_type":"text/x-sh","patch_set":1,"id":"9a41bdd9_a7d2a05a","line":195,"updated":"2015-07-14 18:54:59.000000000","message":"Ok, so this makes sense under the following conditions:\n - the package is py2 and py3 compatible (if its not, it needs to be updated with a marker condition appropriately\n - it has no changes in it\u0027s own requirements. If it changes its own requirements, then it may have knock on effects.\n\nThe canonical way to address both of those is to do this:\n\ngenerate-requirements \u003e base\ngenerate-requirements-with-local-index-for-new-release \u003e changed\ndiff base changed\napply the diff to upper-constraints.txt\ndone\n\nThats obviously a chunk of processing.\n\nI think a better way would be to trigger a constraints generation run of the periodic job after the release is on PyPI. That will handle all the cases automatically, and with ttx\u0027s approval of the one-requirements-core-+A, whoever is doing the release can grab someone from infra-core and get them to immediately ack the change [since if it fails it will fail on check and not disrupt the gate].","commit_id":"1dee5d965ccb66e87b5cf3eea90f48b3ae6d2861"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"d99814327251a4ed0c162429efde20a7f9a82af6","unresolved":false,"context_lines":[{"line_number":192,"context_line":"        REQREPODIR\u003d\"$(realpath requirements)\""},{"line_number":193,"context_line":"    fi"},{"line_number":194,"context_line":"    cd $REQREPODIR"},{"line_number":195,"context_line":"    tox -e venv -- edit-constraints upper-constraints.txt $DISTNAME \"${DISTNAME}\u003d\u003d${VERSION}\""},{"line_number":196,"context_line":"    git commit -a -m \"Update $DISTNAME for new release $VERSION\""},{"line_number":197,"context_line":"    git review"},{"line_number":198,"context_line":"fi"}],"source_content_type":"text/x-sh","patch_set":1,"id":"9a41bdd9_2ded0aef","line":195,"in_reply_to":"9a41bdd9_0a2eeca4","updated":"2015-07-14 21:44:46.000000000","message":"The main trick is that the proposal.slave.openstack.org worker where the update job runs doesn\u0027t run against pypi.python.org but rather against one of our bandersnatch mirrors. Those normally update on a 5-minute pulse if all is going well, but this leaves us open to a race where the update job fires after the upload to pypi.python.org but before the next bandersnatch pulse on pypi.dfw.openstack.org.\n\nThere are options to work around this, but we should probably discuss them in detail.","commit_id":"1dee5d965ccb66e87b5cf3eea90f48b3ae6d2861"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"2f8ab7ebce2b6c432074362f79516ae45e46101d","unresolved":false,"context_lines":[{"line_number":192,"context_line":"        REQREPODIR\u003d\"$(realpath requirements)\""},{"line_number":193,"context_line":"    fi"},{"line_number":194,"context_line":"    cd $REQREPODIR"},{"line_number":195,"context_line":"    tox -e venv -- edit-constraints upper-constraints.txt $DISTNAME \"${DISTNAME}\u003d\u003d${VERSION}\""},{"line_number":196,"context_line":"    git commit -a -m \"Update $DISTNAME for new release $VERSION\""},{"line_number":197,"context_line":"    git review"},{"line_number":198,"context_line":"fi"}],"source_content_type":"text/x-sh","patch_set":1,"id":"9a41bdd9_0a2eeca4","line":195,"in_reply_to":"9a41bdd9_27577059","updated":"2015-07-14 21:33:17.000000000","message":"Yes, it runs daily. Hooking that in should be straight forward. Let me get some eyeballs on this.","commit_id":"1dee5d965ccb66e87b5cf3eea90f48b3ae6d2861"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5230fb9121eb1821427532ea82752488aa64ed73","unresolved":false,"context_lines":[{"line_number":192,"context_line":"        REQREPODIR\u003d\"$(realpath requirements)\""},{"line_number":193,"context_line":"    fi"},{"line_number":194,"context_line":"    cd $REQREPODIR"},{"line_number":195,"context_line":"    tox -e venv -- edit-constraints upper-constraints.txt $DISTNAME \"${DISTNAME}\u003d\u003d${VERSION}\""},{"line_number":196,"context_line":"    git commit -a -m \"Update $DISTNAME for new release $VERSION\""},{"line_number":197,"context_line":"    git review"},{"line_number":198,"context_line":"fi"}],"source_content_type":"text/x-sh","patch_set":1,"id":"9a41bdd9_27577059","line":195,"in_reply_to":"9a41bdd9_a7d2a05a","updated":"2015-07-14 19:05:03.000000000","message":"2/3 compatibility is currently a requirement for all of our library projects.\n\nI don\u0027t know enough about zuul to know if we can trigger one job only after another is completed.\n\nDoes that auto-update job exist yet?","commit_id":"1dee5d965ccb66e87b5cf3eea90f48b3ae6d2861"}]}