15:00:09 #startmeeting releaseteam 15:00:10 Meeting started Fri Dec 9 15:00:09 2016 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:13 The meeting name has been set to 'releaseteam' 15:00:20 courtesy ping: ttx, dims, sigmavirus, tonyb, fungi, stevemar 15:00:32 o/ 15:00:57 our agenda is under the week R-11 section of the etherpad 15:01:00 #link https://etherpad.openstack.org/p/ocata-relmgt-tracking 15:01:05 o/ 15:01:28 #topic priority work review 15:01:51 we did a quick review last week of priority tasks that were in progress 15:02:18 most of the patches I had up for review as part of my tasks have landed, thank you for the reviews 15:02:43 does anyone else have a status update on priority items? we're going to do a deeper look at the "regular" items next 15:03:28 dhellmann : no rush, but this seems ready https://review.openstack.org/#/c/407190/ 15:03:43 ah, good, I'll review that after the meeting 15:04:18 * stevemar lurks 15:04:26 I think the only other high priority items I haven't seen started were on tonyb's list, and he doesn't usually make the meeting because of when it falls 15:04:37 I had busy evenings all week, and failed to catch up with him 15:04:39 I'll try again next week 15:04:49 #topic ocata remaining TODO status review 15:05:07 we have several items that we didn't mark as high priority still in flight or not started 15:05:21 #link https://etherpad.openstack.org/p/ocata-relmgt-plan 15:05:42 we can go through 1 by 1, or we can go by person 15:05:54 oh, on tonyb's automation bits, we discovered that branch deletion through the api (so by non-admins) will need to wait for a gerrit upgrade 15:05:57 ttx started making some notes in the agenday by person 15:06:18 oops, sorry bout late 15:06:22 dhellmann : my python3 port is stuck behind lazr pypi problem 15:06:23 fungi : ok, I think that was a nice-to-have this cycle anyway, and was really planned for next cycle 15:06:27 * ttx blames stevemar 15:06:32 yep, so still on track i guess 15:06:34 o_O 15:06:56 i'll get started on "new project" checklist this week 15:07:06 or flaper87. Yes. flaper87 15:07:07 dims : good to know; did you add that to the planning etherpad? 15:07:08 fungi : sounds like it 15:07:15 ttx: ah, thats better 15:07:25 I'm sure there's plenty of blame to go around ;-) 15:07:32 i am going through my TODO in https://etherpad.openstack.org/p/ocata-relmgt-plan 15:07:37 ttx, you had a question about the horizon plugins in a couple of projects 15:07:59 yes, I'm wondering if we should still push them to decompose, and if so when 15:08:06 with ocata-2 next week and short cycle 15:08:19 yeah, maybe that's something we can do early next cycle 15:08:32 Last two in that situation are mistral-dashboard, sahara-dashboard 15:08:35 I think we'll have fewer internal automation tasks by then 15:08:40 * dhellmann crosses his fingers 15:09:13 I wanted to do it earlier but it got stuck due to the move from goverannce to releases 15:09:28 yeah 15:09:40 yay all done 15:09:49 k 15:10:07 let's go through the planning list and see what else we have 15:10:21 line 38, announcing release candidates 15:10:38 I'll catch up with tonyb next week and if he doesn't think he'll get to it I'll see if I can take that 15:10:59 it should just mean a change to the regex in project-config to run the job, and then change the announce script to use a template instead of sending release notes 15:11:26 line 47, non-python projects in announce script 15:11:37 that one is a little more complicated, but I think tonyb had some ideas 15:11:37 dhellmann : and switch around the destination mailing list too 15:11:49 (line 42) 15:11:50 dims : oh, good point, should we? 15:12:16 so the -dev list I guess? 15:12:17 rc(s) we announce on dev ML? 15:12:49 yep 15:13:11 ok, line (now) 48 -- I'm content to leave this on the todo list for now unless someone feels motivated to grab it 15:13:36 line 54, updating the signing key 15:13:40 fungi, that's done, right? 15:13:51 yep 15:13:59 in place for a few weeks now 15:13:59 good 15:14:05 marked as done 15:14:11 currently signing releases with it 15:14:17 line 56, add release manager signatures to the new key 15:14:38 I've signed. Has anyone else? I looked today, but I'm not sure I'm doing the right thing to re-download the key and refresh the signatures. 15:14:47 ah! haven't done that 15:14:49 i haven'ed yet 15:14:53 * ttx adds to todo 15:14:58 i see infra root sysadmins and dhellmann listed at https://sks-keyservers.net/pks/lookup?op=vindex&search=0xd47bab1b7dc2e262a4f6171e8b1b03fd54e2ac07&fingerprint=on 15:15:17 #link https://sks-keyservers.net/pks/lookup?op=vindex&search=0xd47bab1b7dc2e262a4f6171e8b1b03fd54e2ac07&fingerprint=on Ocata Cycle Signing Key 15:15:33 ok, please do that soon, I'd like everyone to sign before we start using it for release candidates 15:15:36 as an observer, would it be useful for me to sign it? 15:15:45 sigmavirus ++ 15:15:46 sigmavirus : I think the more the merrier 15:15:58 okay then 15:16:20 anyone's free to do so. if you want to extend the web of trust on it through attesting to it transitively, then cool 15:16:36 righto, line 60: moving the requirements update portion of the release job to its own step 15:16:50 we still periodically get questions about this race condition 15:17:05 I'll talk to tonyb about it, and maybe put it on my list if he's not going to have time 15:17:30 the update on line 63 is similar 15:17:56 we'll have more changes for that one when the requirements team rolls out the script for letting libraries use constraints, so I may leave that on tonyb's list to address as part of that work 15:18:16 dims, you had an update on the python 3 work for line 71 15:18:34 lazr on pypi needs to be updated before we can do that dhellmann 15:18:46 noted 15:19:00 line 109, new project checklist 15:19:17 dims, that one is yours, too 15:19:30 yes, will start this week 15:19:36 sounds good 15:19:52 line 139, adding known release freeze dates to the schedule 15:20:04 this is easy enough to do, but we need to work out what those dates are likely to be first 15:20:26 the week between christmas and new years? others? 15:21:38 I was hoping not to ask everyone what their PTO plans were... 15:21:48 heh, mine is for that week :) 15:22:00 I can make an exception though or coordinate with another glance person to work on it then 15:22:09 I'll propose a patch with that and we can adjust through the review 15:22:11 Probably good to freeze between Dec 23 and Jan 2 15:23:07 yeah, that seems like a good set 15:23:14 line 149, puppet hard-coding version info 15:23:41 this isn't a high priority item, IMHO 15:24:04 line 154, add signing key info to releases.o.o 15:24:42 fungi, this is listed as both of us, but I can do it. Was the idea to list the keys used on a page with the date ranges? 15:25:12 yeah, i was going to do something similar to what i did in the ossa repo to embed a dump of the key 15:25:25 and link it in the page content 15:25:50 ok, that sounds good. do you have a link for reference? 15:25:51 similar to how i did https://security.openstack.org/#how-to-report-security-issues-to-openstack 15:26:28 with links to both the key hosted in the documentation itself, and details from the keyserver network 15:26:46 I may have to ask for help generating that dump file 15:26:53 my gpg-fu is weak 15:27:11 the copy of the key only needs to get added to the release site documentation once, but yeah i'll propose a starter change for that after the meeting and maybe you can help me with the prose 15:27:26 sounds good 15:27:40 lin 157, add links to the package signatures 15:27:47 dims has a patch up for review for this 15:27:52 #link https://review.openstack.org/#/c/407190/ 15:28:11 dims : will that patch complete this, or is there more? 15:28:20 dhellmann : that should be it 15:28:24 cool 15:28:40 line 179, coordinate with the project navigator team on our yaml data changes 15:28:59 ttx, maybe I can get Jimmy's contact info from you out of the meeting? 15:29:25 I did that 15:29:28 oh, ok 15:29:31 (contact them about change) 15:29:38 do they need anything from us? 15:29:55 They said they would read from http://git.openstack.org/cgit/openstack/releases/tree/deliverables/RELEASENAME/PROJECTNAME.yaml 15:30:05 excellent 15:30:08 so they don't 15:30:15 (until they do, but currently they don't) 15:30:39 k 15:30:48 line 197, ICS file for the schedule 15:31:08 this may be another we just put off until pike, given how far we are into the schedule 15:32:13 sorry, cat interruption 15:32:25 line 207, release notes in tarballs 15:32:45 I'm unlikely to get this done this cycle because of the work on a different reno bug 15:33:10 line 213, discoverability of release notes via RSS 15:33:28 this was a nice-to-have, and I haven't seen any work from dmsimard yet 15:33:43 line 219 is the bug that's making the tarball work unlikely to happen 15:33:57 I've made good progress this week and should have a patch series for review by the end of next week 15:34:29 a benefit of switching to using dulwich is that reno seems a bit faster, since it's not shelling out to call so many git commands 15:35:02 line 225, is a branch validation rule 15:35:13 dims is listed, but ttx didn't you work on something related to this? 15:35:27 we had a couple of branch validation things to add and I may be mixing them up 15:35:34 y i have not touched that item at all 15:36:05 ... let me see 15:36:21 I may be thinking of https://review.openstack.org/#/c/404786/ 15:36:47 I'm not sure it's exactly the same thing 15:37:21 my change prevents a mismatch between where the SHA is and the series you ask 15:37:44 not sure that matches "refuse to allow a release from master if the stable branch for the series exists" 15:38:11 I refuse to allow a release from master if the SHA is on the stable branch and not master 15:38:41 I mean, I refuse current-series releases using a SHA that is not on master 15:39:07 I think this task was to handle the reverse case 15:39:15 so I think this is still something we need to do 15:39:45 weird, because the test checks that I think 15:40:06 maybe we snuck in a change and I didn't remember? 15:40:19 could you describe the case you're trying to avoid ? 15:40:37 os-brick 1.6.1 was listed with a tag on master instead of the stable/newton branch 15:40:49 so they had it in the right deliverable file, but the sha pointed to the wrong branch 15:41:17 yes that should get caught now 15:41:29 ok, I'll mark that as done then :-) 15:41:29 test_hash_from_master_used_in_stable_release 15:41:48 we've also in the past (not through release management afaik though) seen people push tags for refs that didn't exist in gerrit at all or were for outdated patchsets or open changes that hadn't merged 15:41:54 oh, maybe this came as part of the refactoring work I did 15:42:09 no, this was caught in that commiyt 15:42:21 It's basically the first stable 15:42:22 fungi : those cases should already be caught, that was maybe the very first rule 15:42:29 heh, nice ;) 15:42:44 I think it's what led me to add the validate job in the first place :-) 15:42:51 first stable tag could be on wrong branch because not protected by descendent test 15:42:59 that commit catches that case 15:43:50 ok 15:44:04 so we still think this test is present, though? because of the unit test? 15:44:56 yes we are covered now 15:45:06 k 15:45:30 line 248 was a manual review that all of the things we publish to PyPI have the "include-pypi-link" flag set 15:45:42 or maybe tonyb was going to script that, I'm not sure 15:46:01 I wonder if we could just look for the job that's going to result in uploading the file, instead of having a separate flag 15:46:06 something to consider for pike 15:46:29 line 249 is a change in the way we handle constraints updates to not rely on the flag 15:46:46 we still want to know whether to include the link in announcements, but we said we would always update constraints 15:47:08 that appears to be everything 15:47:14 is anyone working on something not on the list? 15:47:31 no 15:47:32 nope 15:47:41 signed the key, should be ok now 15:47:47 great 15:48:00 I'll talk with tonyb about his items next week 15:48:10 ttx: good, thanks 15:48:33 I'll probably not have time for a lot more relmgt development work in Jan/Feb due to PTG 15:48:36 we did have a few items that we may need to rebalance; if you find yourself looking for something to do let me know :-) 15:48:44 yeah, that makes sense 15:48:47 which is why I tried to complete everything I signed up for before 15:48:53 ++ 15:49:01 success \o/ 15:49:07 is there a to do item i'm not seeing about normalizing package names in urls linked from the releases site? or has nobody noticed that problem until i spotted it just now? 15:49:42 fungi : we don't have a todo, but we do have a way to adjust links if they're wrong. Which ones are looking wrong? 15:49:43 fungi : i saw one about keystoneauth1 which i fixed 15:50:01 os-vif (i just mentioned it in the release channel) 15:50:18 release artifacts for it use os_vif 15:50:45 ok, we can set the tarball-base variable for that 15:51:00 or maybe normalize the _ automatically? 15:51:13 I'm not sure all packages should have that changed, though, since setuptools didn't always do that 15:51:25 well, comparing to pyton-novaclient we don't have _ in tarballs tehre 15:51:28 glance-store seems to work 15:51:39 yeah, maybe os-vif is just an outlier then 15:51:40 yeah, let's handle it as a one-off with the tarball-base then 15:52:08 probably wouldn't hurt to crawl the releases site and auto-check the links go to actual files though rather than 404 15:52:16 yes, good idea 15:52:16 in case there are others 15:52:19 os-win too 15:52:21 ++ fungi 15:53:02 i spotted it trying to review dims's pgp sigs addition, and first thought we were missing a signatures since os-vif was the first one i tried at random 15:53:53 who wants to take that todo item? 15:54:23 there's a linkchecker builder built into sphinx, fwiw 15:54:46 oh, that sounds like the better path forward probably 15:54:58 dhellmann : add to team backlog? 15:55:07 maybe we can add that to the doc build as a validation step 15:55:09 dims : yep, line 203 15:55:42 yeah, it seems less urgent now that i'm comfortable this isn't a widespread issue with our artifact publishing and is just some configuration we need to tweak for a few deliverables 15:55:54 yeah 15:55:58 #topic open discussion 15:56:08 we have a few more minutes, is there anything else to discuss? 15:56:40 if the link checker extension for sphinx turns out to be too fragile in the normal validation job, we could make it a separate experimental job and run it on demand or something 15:56:50 that's a good idea, too 15:56:58 dhellmann : jroll : was the ironic requirements thing discussion wrap up? 15:57:01 yeah, since it really tries the links we might find timeouts 15:57:25 git:// url in requirements 15:57:32 worth trying directly first though. i just don't know how much fragility cloud networks will contribute to checking hundreds/thousands of external urls 15:57:33 dims : not really. I'll revisit that next week. There was a patch to their master branch to at least point to a sha instead of a branch 15:57:43 dims: we pinned to a sha https://github.com/openstack/python-ironic-inspector-client/commit/790ef1adb5382de844157f72e2ab596cf2e51a62 15:57:44 ok thanks dhellmann 15:57:47 fungi : right 15:57:52 jroll : ah. thanks 15:58:03 thanks, jroll 15:58:39 if there's nothing else, we can close a couple of minutes early 15:59:02 thanks dhellmann 15:59:12 thanks, everyone, see you in #openstack-release 15:59:13 thanks! 15:59:16 #endmeeting