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