openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: remove the announce flag from the release wrapper scripts https://review.openstack.org/275986 | 00:03 |
---|---|---|
*** bdemers has quit IRC | 00:19 | |
*** bdemers_ has joined #openstack-release | 00:19 | |
openstackgerrit | Doug Hellmann proposed openstack/reno: add earliest_version option to scanner https://review.openstack.org/275991 | 00:23 |
*** nikhil has quit IRC | 01:21 | |
*** nikhil has joined #openstack-release | 01:35 | |
*** nikhil_k has joined #openstack-release | 02:24 | |
*** nikhil has quit IRC | 02:27 | |
*** dims has joined #openstack-release | 03:38 | |
*** amotoki has joined #openstack-release | 03:52 | |
*** dims has quit IRC | 03:53 | |
*** bdemers_ has quit IRC | 04:04 | |
*** bdemers has joined #openstack-release | 04:05 | |
*** SlickNik has quit IRC | 04:11 | |
*** SlickNik has joined #openstack-release | 04:12 | |
*** sigmavirus24_awa has quit IRC | 04:13 | |
*** jroll has quit IRC | 04:13 | |
*** bdemers_ has joined #openstack-release | 04:13 | |
*** bdemers has quit IRC | 04:13 | |
*** sdague has quit IRC | 04:13 | |
*** sigmavirus24_awa has joined #openstack-release | 04:14 | |
*** sdague has joined #openstack-release | 04:14 | |
*** jroll has joined #openstack-release | 04:14 | |
*** SergeyLukjanov has quit IRC | 04:19 | |
*** mriedem_afk has quit IRC | 04:19 | |
*** tristanC has quit IRC | 04:19 | |
*** smcginnis has quit IRC | 04:19 | |
*** Daviey has quit IRC | 04:19 | |
*** tristanC has joined #openstack-release | 04:19 | |
*** Daviey has joined #openstack-release | 04:19 | |
*** SergeyLukjanov has joined #openstack-release | 04:20 | |
*** smcginnis has joined #openstack-release | 04:20 | |
openstackgerrit | Ben Swartzlander proposed openstack/releases: Release manila-ui 1.3.0 https://review.openstack.org/275310 | 04:41 |
*** bnemec has joined #openstack-release | 08:02 | |
*** openstackgerrit has quit IRC | 09:17 | |
*** openstackgerrit has joined #openstack-release | 09:17 | |
*** mugsie has quit IRC | 10:39 | |
*** mugsie has joined #openstack-release | 10:40 | |
*** bnemec has quit IRC | 10:40 | |
*** bnemec has joined #openstack-release | 10:42 | |
*** bnemec has quit IRC | 11:01 | |
*** dims has joined #openstack-release | 11:12 | |
dims | ttx : can we let this in please? i can clean out a whole lot of config files | 11:27 |
dims | https://review.openstack.org/#/c/274939/ | 11:27 |
dims | ttx ^^ | 11:27 |
ttx | on it | 11:28 |
ttx | dims: shouldn't that one also change the upper-contraints to match ? | 11:36 |
ttx | oh, already at 0.17.3 | 11:36 |
dims | ttx : the bot merged a chance to u-c already | 11:36 |
dims | yep | 11:36 |
*** bnemec has joined #openstack-release | 11:36 | |
ttx | alright then | 11:36 |
dims | thanks ttx | 11:37 |
*** dtantsur|afk is now known as dtantsur | 12:58 | |
dhellmann | ttx, dims: you saw that the new job to send announcement emails merged yesterday, right? https://review.openstack.org/#/c/272767/ | 13:19 |
*** gordc has joined #openstack-release | 13:22 | |
dims | dhellmann : y, one question i had was if the pypi upload fails, does it still send the announce? | 13:23 |
ttx | dhellmann: yes, review is next on my todo | 13:23 |
dhellmann | dims : great question, I'm not sure. probably not, since the announce job depends on the upload job | 13:26 |
dims | dhellmann : cross my fingers :) | 13:33 |
ttx | dhellmann: lgtm (good thing since it merged already :) | 13:37 |
ttx | dhellmann: so the main issue with this approach is that it ties the announce to a specific tarball (vs. a deliverable) | 13:38 |
*** david-lyle has quit IRC | 13:38 | |
ttx | so at release time we end up sending several mails for a single 'release' | 13:39 |
ttx | I think we can survive that for now | 13:39 |
ttx | but it kind of reduces the value of the "deliverable" concept, which was supposed to help with decomposition across multiple git repos | 13:40 |
ttx | but it's a tough one to crack, especially with the infrastructure happily ignoring that subtlety for now | 13:42 |
ttx | the integration was in fact manually done by the human at the announce step | 13:43 |
ttx | one way to work around it with the current structure would be to have the first -announce-release jobs in a deliveravle be NOOPs and the last one for a deliverable picking up the tab. Hard to avoid races though | 13:45 |
openstackgerrit | gordon chung proposed openstack/releases: ceilometerclient 1.5.2 - liberty https://review.openstack.org/275367 | 13:47 |
ttx | that would replicate how humans used to do it | 13:48 |
*** sigmavirus24_awa is now known as sigmavirus24 | 13:51 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 13:52 | |
dhellmann | ttx: crazy idea: have the announce job on a repo tag the releases repo, and have a job on the releases repo respond to the tag | 14:04 |
openstackgerrit | Dean Troyer proposed openstack/releases: Release OpenStackClient 2.1.0 https://review.openstack.org/276251 | 14:04 |
dhellmann | ttx: but yeah, I think we can live with it for the time being | 14:04 |
*** dims_ has joined #openstack-release | 14:10 | |
*** dims has quit IRC | 14:12 | |
ttx | dhellmann: heh, that would be a pretty nasty hack :) Although that could let us feed information back to releases repo... think a SHA1 for the generated tarballs | 14:24 |
ttx | but then you're back on privileges nodes for the tag signing | 14:25 |
*** wshao has joined #openstack-release | 14:29 | |
dhellmann | ttx: what if we submit a patch with the sha, instead of tagging? | 14:33 |
dhellmann | it makes the release a 2 step process (approve the release, wait for and approve the sha patch to trigger the announcement) | 14:33 |
ttx | That could be acceptable. We need to sit on top of the reviews on that repo anyway | 14:34 |
dhellmann | ttx: if a deliverable has several repos, we would have to wait for all repos to have an associated sha before announcing, but that's an easy check | 14:34 |
dhellmann | I'll make a note of that as an improvement for next cycle. I'm more worried about release notes translations, I think, this cycle. | 14:35 |
ttx | dhellmann: the job would have to propose changes on top of one another | 14:35 |
dhellmann | ttx: that would be idea, yeah, but adding individual lines shouldn't introduce merge conflicts, would it? | 14:35 |
ttx | I wonder if they would be separated enough. I guess they would | 14:36 |
dhellmann | we could design it to ensure that. maybe that info goes into separate files, for example | 14:37 |
ttx | as a workaround for this cycle we could make the announce job noop on multi-repo deliverables for this cycle, up to the human to collect them in a single one | 14:37 |
dhellmann | we still need the tool to support doing that, and that's going to be some work | 14:37 |
ttx | or maybe have the tag contain the deliverable:yes info | 14:38 |
dhellmann | hmm, that might work | 14:38 |
ttx | I'll think about it, worst case scenario we'll just multiannounce for this cycle | 14:38 |
dhellmann | ok | 14:38 |
ttx | I just would like to avoid training people to ignore the deliverables concept, even if just for one cycle | 14:39 |
dhellmann | if we need a flag, we could allow announce-to to be empty, and not announce in that case | 14:39 |
ttx | oh. We could indeed just remove announce-to from multi-repo deliverables | 14:39 |
ttx | then it's just a question of collating manually | 14:40 |
ttx | anyway, don't worry about it, I'll look into it | 14:40 |
ttx | famous last words | 14:40 |
dhellmann | OTOH, I wonder how many multi-repo deliverables we really want. Doesn't it confuse things like where to go look for the release notes in the first place? | 14:40 |
dhellmann | I need to think about it more, too | 14:40 |
ttx | hmm | 14:40 |
ttx | Ideally those would have a single release note | 14:41 |
ttx | but that may be hard to retrofit | 14:41 |
dhellmann | but that means if I have a patch in repo B, I have to put a reno file in repo A | 14:41 |
ttx | right, that's what I mean by hard to retrofit | 14:41 |
dhellmann | yeah | 14:41 |
ttx | maybe just adding a "this component is part of the neutron 7.0.2 deliverable" on top of the announce is a good tradeoff | 14:42 |
openstackgerrit | Doug Hellmann proposed openstack/releases: skeleton version of newton schedule https://review.openstack.org/275911 | 14:56 |
dhellmann | ttx: that's certainly easy enough to do | 14:56 |
dhellmann | ttx, dims_ : I'm going to release keystoneclient and try out the new announce job | 15:03 |
*** doug-fish has joined #openstack-release | 15:03 | |
dhellmann | ttx, dims_: do you have an issue with me self-approving the tool changes under that patch? | 15:04 |
dims_ | dhellmann : please go for it | 15:04 |
* dims_ prototyping a jenkins job for running nova, glance etc with oslo master | 15:05 | |
dhellmann | dims_ : ack, thanks | 15:05 |
*** sigmavirus24_awa is now known as sigmavirus24 | 15:06 | |
*** nikhil_k is now known as nikhil | 15:08 | |
*** wshao has quit IRC | 15:11 | |
openstackgerrit | Merged openstack/releases: show more change detail, including ancestry https://review.openstack.org/275829 | 15:17 |
openstackgerrit | Merged openstack/releases: do not merge stderr & stdout when checking ancestors https://review.openstack.org/275853 | 15:20 |
openstackgerrit | Merged openstack/releases: release keystoneclient 2.1.2 https://review.openstack.org/275685 | 15:23 |
dhellmann | ugh, failed | 15:28 |
dims_ | dhellmann : where exactly? | 15:46 |
dhellmann | dims_ : bug in the job definition, we have the fix merging now | 15:47 |
* dhellmann my kingdom for a backslash | 15:47 | |
dims_ | ack thanks dhellmann :) | 15:47 |
dims_ | dhellmann : there's just no way to try job definitions :( | 15:48 |
dhellmann | dims_ : yeah :-/ | 15:48 |
*** david-lyle has joined #openstack-release | 16:24 | |
dhellmann | stevemar : keystoneclient 2.1.2 is released, but the announce job failed. we have a fix in the queue and will re-run that asap, but I thought I'd let you know | 16:26 |
dhellmann | stevemar, bknudson_: you should go ahead and make the constraints update | 16:26 |
stevemar | dhellmann: ah okay - i saw it was merged, haven't gotten to the ML folder in my email yet :) | 16:27 |
smcginnis | Hey all, any plans to add gpg signatures on https://tarballs.openstack.org/ | 16:38 |
smcginnis | I'm getting pinged on the lack of that. | 16:39 |
dhellmann | smcginnis : yes, let me find that spec | 16:40 |
smcginnis | dhellmann: Cool, thanks! | 16:40 |
dhellmann | smcginnis : http://specs.openstack.org/openstack-infra/infra-specs/specs/artifact-signing.html | 16:40 |
dhellmann | it's an infra spec, but we're interested/involved, too | 16:40 |
smcginnis | dhellmann: Perfect, thanks. I can at least point them to this. | 16:41 |
dhellmann | smcginnis : cool | 16:41 |
smcginnis | Sorry, one more question. | 16:42 |
smcginnis | Am I supposed to hit the Create Release link here: https://launchpad.net/cinder/+milestone/2015.1.3 | 16:42 |
smcginnis | Or does it not matter anymore? | 16:42 |
dhellmann | smcginnis : you don't need to do that any more. We're going to be referring folks to the docs published out of the releases repo (docs.openstack.org/releases now and releases.openstack.org any day now) | 16:43 |
smcginnis | dhellmann: OK, thanks. Just want to make sure I'm not missing anything. | 16:43 |
dhellmann | smcginnis : yep, thanks for double-checking | 16:44 |
dims_ | dhellmann : stevemar : we may have broken something... http://logs.openstack.org/57/273957/1/gate/gate-tempest-dsvm-neutron-full/f2eaa44/logs/devstacklog.txt.gz | 16:53 |
dims_ | stevemar : bknudson_ : 3 more logs with the same problem | 16:54 |
stevemar | dims_: oh nice | 16:54 |
bknudson_ | something with the requirements? | 16:54 |
dims_ | http://paste.openstack.org/show/485987/ | 16:54 |
dims_ | links to 4 jobs that failed a short while ago | 16:55 |
stevemar | i feel like just releasing from master at this point | 16:55 |
dims_ | stevemar : need to make sure those were because of the release pushed out or something else first | 16:56 |
openstackgerrit | Greg Hill proposed openstack/releases: Add taskflow 1.27.0 https://review.openstack.org/276352 | 16:56 |
stevemar | dims_: if it quacks like a duck and looks like a duck | 16:57 |
stevemar | let me check pip freeze | 16:57 |
stevemar | what the... python-keystoneclient==1.3.4 | 16:57 |
bknudson_ | old school | 16:57 |
*** jgriffith is now known as jgriffith_away | 16:58 | |
stevemar | looks like those are all kilo related | 16:58 |
dims_ | stevemar : whew ok | 16:59 |
stevemar | *wipes sweat from brow* | 17:00 |
dims_ | we still have to tell mriedem :) | 17:00 |
dims_ | we got off easy :) | 17:00 |
stevemar | dims_: maybe testtools needs a pin on kilo? | 17:01 |
stevemar | looks like they are pulling in fixtures 1.3.0? | 17:01 |
stevemar | dims_: yeah testtools released today https://pypi.python.org/pypi/testtools | 17:02 |
*** bnemec has quit IRC | 17:02 | |
dims_ | ah cool | 17:02 |
stevemar | dims_: and kilo says fixtures>=0.3.14,<1.3.0 | 17:03 |
dims_ | stevemar : let's take it to the stable channel | 17:06 |
*** dtantsur is now known as dtantsur|afk | 17:18 | |
bswartz | dhellmann: why did you ask fro the manilaclient verison to be bumped to 1.7.0 instead of 1.6.1? Isn't a bugfix release just a +0.0.1 version bump? | 17:52 |
dhellmann | bswartz : the minimum required versions of related libraries have changed | 18:07 |
bswartz | ah, I see | 18:09 |
*** amotoki has quit IRC | 18:43 | |
*** dansmith has quit IRC | 19:05 | |
*** dansmith has joined #openstack-release | 19:05 | |
*** david-lyle has quit IRC | 19:11 | |
*** georgewang has joined #openstack-release | 19:50 | |
georgewang | hi, networking-sfc submit README.rst after mitaka release, it causes the content in http://docs.openstack.org/developer/networking-sfc/ out of sync with https://pypi.python.org/pypi/networking-sfc/1.0.0 | 19:52 |
georgewang | can release team help update the pip document also? Thanks | 19:52 |
*** nikhil_k has joined #openstack-release | 19:52 | |
*** nikhil has quit IRC | 19:55 | |
*** stevemar has quit IRC | 19:56 | |
*** jgriffith_away is now known as jgriffith | 20:19 | |
sdague | dims_: / dhellmann it looks like the oslo.messaging release has gone poorly, all the python 3.4 constraints jobs are failing | 20:20 |
*** r1chardj0n3s has left #openstack-release | 20:20 | |
dhellmann | georgewang : your pypi readme will be updated on your next release, or someone with access to pypi can edit it directly (I don't have that permission myself) | 20:22 |
dhellmann | sdague : what repo? | 20:23 |
sdague | ? | 20:23 |
dhellmann | sdague : 3.4 constraints jobs? | 20:23 |
sdague | https://jenkins06.openstack.org/job/gate-neutron-python34-constraints/1689/ | 20:23 |
sdague | No matching distribution found for oslo.messaging===4.1.0 (from -c /home/jenkins/workspace/gate-neutron-python34-constraints/upper-constraints.txt (line 213)) | 20:23 |
sdague | fungi said the wheel looked wrong on pypi | 20:24 |
dhellmann | looks like something didn't get uploaded | 20:24 |
fungi | yeah, i'm juggling 10 conversations in different places but was on my way over here to say something | 20:24 |
sdague | this seems like an excellent new thing to get tested on updating upper-constraints | 20:24 |
dhellmann | sdague : the constraints job should already be trying to install things, and it runs the dsvm jobs, doesn't it? | 20:25 |
dhellmann | fungi : is this something we can recover from by rerunning the existing release, or should I tag another one? | 20:25 |
dhellmann | sdague : ah, requirements updates don't try with python 3 | 20:27 |
dhellmann | I wonder if we're at a point yet where all of our requirements can be installed under python 3 | 20:27 |
sdague | that I don't know | 20:29 |
sdague | however, it probably wouldn't be too bad to make sure they exist | 20:29 |
fungi | the constraints job is supposed to try to do python 2 and python 3 | 20:31 |
fungi | dhellmann: i should be able to complete the upload | 20:31 |
dhellmann | fungi : ok, thanks, I know you have a lot going on this week | 20:31 |
fungi | i'm trying to find a second to dig up the logs, but it's almost certainly another case of pypi returning an error after a successful upload of the wheel | 20:31 |
*** jgriffith is now known as jgriffith_away | 20:31 | |
sdague | fungi: cool, that would be good. right now there are enough neutron jobs in the gate, it's just going to chew on the entire node allocation until this gets sorted | 20:32 |
dhellmann | fungi : http://logs.openstack.org/68/68799083b19f07f321ec1666071ca58bdd42d1f4/release/oslo.messaging-pypi-both-upload/bc12f21/console.html | 20:32 |
dhellmann | bad gateway | 20:32 |
fungi | infra's still pretty short-staffed this week (though not as bad as last week) | 20:32 |
dhellmann | and yes, the py2-non-any wheel is there | 20:33 |
fungi | yeah, dstufft says this is something weird with their fastly proxying for http post method | 20:33 |
fungi | it's been going on for like a year though | 20:34 |
dhellmann | I could try to patch twine to retry, or confirm the error by looking for the file | 20:34 |
dhellmann | or I could patch our job to do that | 20:34 |
fungi | there are some subtle issues around possible approaches to making it more robust, which we were discussing in the infra channel earlier this week | 20:35 |
dhellmann | ok | 20:35 |
*** stevemar has joined #openstack-release | 20:36 | |
fungi | pypi upload of the sdist is complete now | 20:36 |
dhellmann | fungi : thanks! | 20:37 |
fungi | yw, sorry about the delay | 20:37 |
dhellmann | fungi : no worries! | 20:37 |
*** bdemers has joined #openstack-release | 20:38 | |
* dims_ back from picking up kid from school | 20:38 | |
dims_ | fungi : dhellmann : this should have triggered doubts in my head - https://review.openstack.org/#/c/276058/ | 20:40 |
dims_ | fungi : thanks! | 20:40 |
dhellmann | dims_ : ah! | 20:40 |
dhellmann | sdague, fungi, dims_ : I don't see a job with an obvious name indicating that it is trying to install everything while checking the requirements. Did we stop doing that? There used to be a pbr script... | 20:41 |
sdague | I thought that was - gate-requirements-integration-dsvm | 20:41 |
dims_ | gate-requirements-integration-dsvm-resolver? | 20:41 |
*** SlickN1k has joined #openstack-release | 20:42 | |
fungi | the -resolver version is lifeless's experimental sat solver branch of pip i think | 20:42 |
sdague | yeh that's different | 20:42 |
sdague | however, that job generates the constraints, but does not attempt to use them I don't think | 20:42 |
sdague | also, only py27 I'm pretty sure | 20:43 |
fungi | i thought it also had a py34 stage | 20:43 |
dims_ | gotcha sdague | 20:43 |
fungi | as part of the same job | 20:43 |
sdague | fungi: maybe, though if it isn't using the constraints file, it would not have hit this | 20:43 |
fungi | fair point | 20:46 |
fungi | i meant the constraints generator job is supposed to do a py34 pass | 20:46 |
openstackgerrit | Ben Swartzlander proposed openstack/releases: Release python-manilaclient 1.7.0 https://review.openstack.org/270834 | 20:47 |
*** bdemers_ has quit IRC | 20:47 | |
*** SlickNik has quit IRC | 20:47 | |
*** bswartz has quit IRC | 20:47 | |
*** ttx has quit IRC | 20:47 | |
*** v12aml has quit IRC | 20:47 | |
*** SlickN1k is now known as SlickNik | 20:47 | |
dims_ | fungi dhellmann : looks like we need additional steps in the pypi uploader job to see if it can pull down everything it just uploaded? | 20:47 |
dhellmann | dims_ : we were just talking about that. I'd want to add it to twine, if we could. Do you have someone who can help dstufft with that? | 20:48 |
dims_ | dhellmann : i can check | 20:49 |
*** ttx has joined #openstack-release | 20:49 | |
*** v12aml has joined #openstack-release | 20:49 | |
*** bswartz has joined #openstack-release | 20:50 | |
fungi | yeah, twine confirming what it uploaded is indexed, rather than just relying on the http response, might help | 20:51 |
*** stevemar has quit IRC | 20:52 | |
fungi | problem is this seems to be an infrastructure/implementation issue with pypi.python.org causing a false negative result. it's sort of an odd wishlist item to ask to have the tool double-check that errors are really failures, though that's the situation we find ourselves in | 20:52 |
*** gordc has quit IRC | 20:52 | |
dhellmann | fungi : yeah, dstufft thinks the fix in twine might be pretty simple, so if we can find someone with time to make the patch I'll set up introductions and see if we can get it dealt with, hacky though that might be | 20:53 |
fungi | awesome | 20:53 |
dhellmann | dims: ^^ | 20:53 |
dims_ | fungi : would doing a pip install with the version that we just uploaded work? | 20:53 |
fungi | that someone != me btw ;) | 20:54 |
dhellmann | fungi : ditto | 20:54 |
fungi | dims_: i don't know what sort of latency we should be expecting there, but also that doesn't necessarily cover it in situations like this one | 20:54 |
dhellmann | dims_ : dstufft said we probably just need to "pass a Retry instance" to the post code | 20:54 |
dims_ | fungi : ack | 20:54 |
dhellmann | looking at the requirements-integration job, I see it installing the projects listed in the job definition, but not using the constraints file | 20:55 |
fungi | well, also the retry needs to idempotently noop in cases where the file was successfully uploaded and pypi refuses the retry because it won't let the file be overwritten | 20:55 |
dims_ | dhellmann : can you create an issue in twine? we can add notes there and point some folks to it? | 20:55 |
dims_ | s/can you/can you please/ | 20:55 |
dims_ | i may be getting an intern shortly in ukraine, so this may be a quick one to test their skills | 20:56 |
fungi | there's supposedly already some implementation in twine to skip files which are already on pypi when uploading, so presumably that could be used to determine whether there is a need to retry on some failures | 20:56 |
dims_ | fungi : ack i'll poke at the code in a little bit too | 20:57 |
dhellmann | dims_ : https://github.com/pypa/twine/issues/167 | 20:57 |
fungi | worth noting, also, is that we're consuming twine from ubuntu's packages in 14.04 lts. we switched away from installing it from pypi because things like requests getting updated broke our release process not long ago too | 20:58 |
fungi | and we'd rather not run non-distro packages on privileged job workers | 20:58 |
fungi | so the cycle to consume this feature would likely be longish | 20:58 |
dims_ | dhellmann : ah thanks! | 20:59 |
fungi | like if it somehow gets into 16.04 lts then maybe we can have it soon, but otherwise we may need to consider other options | 20:59 |
dims_ | fungi : ouch ok | 21:00 |
dhellmann | fungi : hmm, that makes fixing it upstream a bit less useful, at least at first. We might need to modify the job, too. | 21:12 |
dims_ | dhellmann : right | 21:17 |
*** gordc has joined #openstack-release | 21:49 | |
openstackgerrit | Doug Hellmann proposed openstack/releases: add a flag for whether to report the PyPI link for releases https://review.openstack.org/276467 | 22:05 |
openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: remove notable changes option https://review.openstack.org/276468 | 22:05 |
openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: process pypi flag for release announcements https://review.openstack.org/276469 | 22:05 |
openstackgerrit | gordon chung proposed openstack/releases: ceilometerclient 1.5.2 - liberty https://review.openstack.org/275367 | 22:47 |
*** david-lyle has joined #openstack-release | 22:48 | |
*** david-lyle has quit IRC | 22:52 | |
*** gordc has quit IRC | 23:28 | |
*** dims_ has quit IRC | 23:31 | |
*** dims has joined #openstack-release | 23:32 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 23:35 | |
georgewang | To update the networking-sfc pypi documentation, I see dhellmann suggested to wait for next release or ask someone to edit pypi directly | 23:41 |
georgewang | My question is when is the next release or do you know who can access to modify the pypi? | 23:42 |
georgewang | thanks | 23:42 |
lifeless | fungi: sdague: constraints generation does 2.7 and 3.4 | 23:53 |
dhellmann | georgewang : you'd have to ask the contributor team about either of those things | 23:53 |
lifeless | and merges them | 23:53 |
fungi | lifeless: it seems to have squeaked by in a corner case where a py2-only wheel gets uploaded and there's no sdist | 23:53 |
dhellmann | lifeless : we discovered that since the python3 compatible sdist wasn't uploaded, the constraints had different versions for py2 and py3. dims fixed that by hand, and that change passed the test, so we have a gap in coverage somewhere | 23:54 |
fungi | likely not a situation to optimize for, but might be interesting to figure out why | 23:54 |
lifeless | sorry, I don't have full context | 23:54 |
fungi | oh, that 'splains it | 23:54 |
fungi | so the constraints change that merged was a "modified" one | 23:54 |
dhellmann | lifeless : the oslo.messaging release broke part way through because of pypi errors, so only 1 of 2 files was uploaded | 23:54 |
lifeless | constraints *should* have different versions for py2 and py3 in that sort of case | 23:54 |
lifeless | working-as-designed | 23:55 |
dhellmann | that happened to be a py2 wheel | 23:55 |
dhellmann | right, but it got "fixed" and the fix passed our tests, which means we can constrain to a thing we can't install under python 3 | 23:55 |
lifeless | dhellmann: yah, it would be wonderful if the pypi upload process could be transational | 23:55 |
fungi | so presumably the generated constraints file said use new oslo.messaging on py2 and older oslo.messaging on py3, and dims "fixed" it? | 23:55 |
dhellmann | fungi : right | 23:55 |
fungi | now i understand why | 23:55 |
dhellmann | [Thu 03:40:11 PM] <dims_>fungi : dhellmann : this should have triggered doubts in my head - https://review.openstack.org/#/c/276058/ | 23:56 |
lifeless | its the issing unit tests thing | 23:56 |
fungi | dhellmann: thanks, i looked at the change but it didn't click that it was a modified change | 23:56 |
* dims peeks | 23:56 | |
fungi | and then i got dragged into other fires | 23:56 |
lifeless | if we can start running unit tests of nova on requirements checks, we'd catch things like that | 23:56 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!