14:00:24 <dhellmann> #startmeeting releaseteam
14:00:25 <openstack> Meeting started Fri Jul  8 14:00:24 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:29 <openstack> The meeting name has been set to 'releaseteam'
14:00:33 <dhellmann> courtesy ping: ttx, dims, lifeless, tonyb, stevemar, fungi
14:00:48 <fungi> sweet release
14:01:08 <dhellmann> oh, that's a good theme for a mascot
14:01:16 <dhellmann> I had been thinking along the lines of "release the hounds"
14:01:38 <dhellmann> apparently "made up" animals like a kraken are verboten
14:01:57 <fungi> which is unfortunate since infra has/had a mascot that is a made up animal
14:02:05 <dhellmann> yeah
14:02:13 <dhellmann> you should be grandfathered in, since you already have it
14:02:20 <fungi> though i do like hounds. it's also a great simpsons reference
14:02:29 <dhellmann> a bunch of the teams already have art
14:02:39 <ttx> been trying to get Heidi to relax that rule, but she made a (good) point that mythological or imaginary animals are not universal in culture
14:02:41 <fungi> i would rather have oort
14:02:42 <dhellmann> ttx suggested a herding dog
14:03:07 <ttx> so what is obviously a Kraken here might not mean anything in India
14:03:10 <dhellmann> ttx: yeah, that's a good point
14:03:23 <dhellmann> aw, they get the bad movies too, don't they? ;-)
14:03:23 <ttx> especially once rendered into art form
14:04:08 <dhellmann> anyway...
14:04:11 <dhellmann> our agenda is at https://etherpad.openstack.org/p/newton-relmgt-tracking
14:04:12 <dhellmann> this week is R-13
14:04:17 <dhellmann> #topic automation update (fungi)
14:04:25 <fungi> oh, right, that stuff
14:04:30 <dhellmann> pfft, work
14:04:52 <fungi> there is a job worker in existence as of this week, named signing01.ci.openstack.org (known simply by the node label "signing" in jobs)
14:05:04 <dhellmann> cool
14:05:14 <fungi> i've confirmed that the jenkins user on it is able to do basic gpg signing operations
14:05:28 <dhellmann> I had intended to start working on a job definition this week, but haven't yet so that's on my priority list for next week
14:05:32 <fungi> it automatically uses the infrastructure signing subkey we puppet onto it with no trouble
14:05:56 <dhellmann> and it can propose patches?
14:06:11 <fungi> i've got some additional process documentation proposed with a transcript of key generation steps and the config used on the bastion where the key is generated
14:06:24 <fungi> #link https://review.openstack.org/#/q/topic:artifact-signing artifact signing changes
14:06:50 <fungi> i'm working today on adding the change for its release account credentials in gerrit so it can push tags
14:07:14 <fungi> it's to teh stage now where it would be sufficient for signing and uploading tarballs et al
14:07:21 <fungi> so next step is tag pushing support
14:07:31 <dhellmann> k
14:07:52 <dhellmann> sounds like we're (you're) making good progress
14:08:07 * stevemar sneaks in late
14:08:10 <fungi> though the job should just be written like other gerrit-using jobs and it can be reviewed in parallel
14:08:35 <dhellmann> ok, good
14:08:52 <fungi> there's really nothing significantly different other than making sure the job uses node: signing
14:09:01 <dhellmann> the scripts that job needs are in place, so it should be a relatively straightforward wrapper job
14:09:23 <dhellmann> yeah, it's just a matter of me carving out a block of time to do that
14:09:43 <fungi> i'll make sure it's in my priority review queue too once you propose it
14:09:45 <dhellmann> are you blocked on anything?
14:09:47 * dims shows up fashionably late...sorry
14:09:52 <fungi> just available time, like everyone
14:10:00 <dhellmann> too true
14:10:06 <fungi> all those spinning plates
14:10:11 <dhellmann> ok, good then, let's keep moving
14:10:17 <dhellmann> #topic N2 TODOs remaining tasks review
14:10:17 <stevemar> :)
14:10:38 <dhellmann> ttx put together a list of the todo items we assigned as N2 priorities in the tracking etherpad
14:11:02 <dhellmann> let's run through them and identify any that are completed
14:11:13 <dhellmann> #info document what independent project should do to use the release automation
14:11:49 <dhellmann> I haven't started that, but I think we agreed it would go in the readme for the releases repo, right?
14:12:19 <ttx> yes
14:12:29 <dhellmann> #info Final release / Propose stable/newton ACLs (ttx)
14:12:56 <dhellmann> this is part of the new end of release process, right?
14:12:57 <ttx> I'm trying to get that done today
14:13:00 <ttx> yes
14:13:07 <ttx> not urgent, but goot to do n2
14:13:09 <ttx> good
14:13:20 <dhellmann> sure
14:13:35 <ttx> I need to extract cycle-with-milestones targets
14:13:47 <dhellmann> are you at all worried about adding new projects between now and the end of the cycle?
14:14:11 <ttx> hmm, not so much
14:14:13 <dhellmann> this feels like something where we might have a race condition if we do it too early (even though we said we would do it early when we talked about it)
14:14:19 <ttx> that would clearly be an edge case
14:14:24 <dhellmann> I guess we can just review them at that point
14:14:43 <ttx> since we ask that projects go through a number of milestones before we do them for a release
14:14:56 <dhellmann> oh, I was thinking of new official projects
14:14:59 <ttx> things not announced by N2 would skip release in my book
14:15:17 <ttx> dark spot there
14:15:24 <dhellmann> ok, something to think about
14:15:31 <dhellmann> a quick review at the end of cycle should cover it
14:15:43 <dhellmann> certainly if they haven't joined by n3 we can say they weren't officially part of the cycle
14:15:50 <dhellmann> n2 feels a bit early to make that call
14:16:03 <ttx> uh training-labs is still cycle-with-meilstones :)
14:16:18 <dhellmann> I'll ping loquacities about that
14:16:26 <ttx> so should we do the patch closer to N3 ?
14:16:45 <ttx> post-N2 sounds like a minimum
14:17:21 <dhellmann> do we want to declare some sort of cut-off point for adding new projects to a cycle?
14:17:49 <ttx> for cycle-* things yes
14:18:01 <ttx> for mme that would be N2
14:18:15 <ttx> always been x2 in the past
14:18:28 <dhellmann> I can go along with that. We should add that to the schedule. Do we need to coordinate with the TC?
14:18:32 <ttx> if you're not there by x2 you're not part of the release
14:18:54 <ttx> We could document it, but that's how we always operated historically so I don't think we need approval
14:19:13 <dhellmann> ok, I wasn't aware of prceedent
14:19:17 <dhellmann> precedent
14:19:25 <dhellmann> I'll work on a patch to update the schedule to document it
14:19:38 <dhellmann> do we need to mention that in the tag definitions?
14:19:41 <ttx> basically you had to do at least two milestones to be included in release
14:20:09 <dhellmann> that seems like a good cut-off
14:20:39 <dhellmann> ok, documenting it in our schedule should be good enough
14:20:42 <ttx> now the messaging around it has changed, but the cut-off is still valid imho
14:20:43 <dhellmann> #info Final release / Get all groups created and seeded with Release Managers (ttx)
14:20:53 <ttx> Let's move the ACL patch to N3
14:21:01 <dhellmann> this is probably blocked on the previous item, right?
14:21:02 <ttx> i.e. to be done post-n2
14:21:05 <dhellmann> agreed
14:21:16 <ttx> next one is blocked on previous one yes
14:21:22 <dhellmann> ok
14:21:58 <dhellmann> is there anything else on those 2 items?
14:22:17 <ttx> nope
14:22:21 <dhellmann> #info Reno / Add setuptools integration to reno so release notes show up in the sdist build (dhellmann)
14:22:38 <dhellmann> I've started this, but the pbr folks want more testing than I initially wrote so it's going to need some more work
14:23:11 <dhellmann> #info Reno / Figure out how to deal with translations (?)
14:24:08 <dhellmann> we know generally how this will work (sphinx ties in with the existing translation platform) and AJaeger did some initial experimentation
14:24:31 <dhellmann> I'm comfortable moving this to N3 priority, since I think some of the other work that is also slipping is more important
14:24:33 <dhellmann> thoughts?
14:25:13 <ttx> yeah
14:25:22 <dhellmann> #info Reno / add better test coverage for sphinx extension to avoid future issues like with collapsing pre-releases not working for mitaka (?)
14:25:25 <ttx> we could hack on reno on the side at EuroPython
14:25:29 <dhellmann> #undo
14:25:30 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0x7f2b35e0f690>
14:25:46 <dhellmann> either that or the release job
14:25:57 <ttx> since I took a few action items there too and it's unlikely to get done unless I force myself
14:25:57 <dhellmann> I want that automation more than anything else on our list :-)
14:26:25 <dhellmann> but yeah, I like the idea of sitting down and working on some of it together
14:26:38 <dhellmann> #info Reno / add better test coverage for sphinx extension to avoid future issues like with collapsing pre-releases not working for mitaka (?)
14:26:53 <dhellmann> that's a good example of something we could do as a background task
14:27:24 <dhellmann> I think I put the priority at n2 because of the issue we had, but that issue is gone and we haven't made big changes to the rendering code other than adding the caching
14:28:09 <dhellmann> #info Automation / move tagging-related scripts that need to run on a privileged worker to project-config repo (dhellmann) DONE
14:28:29 <dhellmann> those scripts are moved over now
14:28:33 <ttx> yay
14:28:48 <dhellmann> #info Automation / add validation to releases repo to ensure the patch in question is actually on the right branch (?)
14:29:06 <dhellmann> this was a nice-to-have that I thought I would get to quickly but didn't
14:29:25 <fungi> i can confirm they're also present in /usr/local/jenkins/slave_scripts/release-tools/ on the signing node
14:29:28 <dhellmann> the biggest issues are usually with the independent projects, and we can't predict from the inputs which branch the tag needs to be on
14:29:38 <fungi> or rather, i just did confirm
14:29:56 <dhellmann> fungi : oh, good, I forgot to confirm with you that copying from the subdir worked as expected (I think we predicted it would but there was no example of that)
14:30:46 <dhellmann> ok, I think that covers everything we already had for N2
14:30:56 <dhellmann> are there any items that have come up that we need to resolve before next thursday's deadline?
14:31:08 <ttx> none from here
14:31:27 <dhellmann> #topic n2 deadline
14:32:10 <dhellmann> I mentioned the deadline in the countdown email yesterday. For N1 we didn't spend a lot of time reminding liaisons to set up their tags, and I was going to stick with that policy for N2 as well.
14:32:31 <dhellmann> IIRC, we only had a couple of teams miss N1
14:33:05 <dhellmann> hmm, 6 projects actually
14:33:27 <dhellmann> maybe I'll go ahead and send a separate reminder early next week
14:33:53 <ttx> yeah
14:34:04 <dhellmann> ok, noted
14:34:38 <dhellmann> #topic priority reviews
14:34:55 <dhellmann> I didn't spot anything in progress that needed to be mentioned, but let me know if I missed something you want reviewed.
14:35:17 <ttx> nothing left on my side.
14:35:25 <dhellmann> we'll have more for next week's meeting
14:35:31 <dhellmann> #topic open discussion
14:35:50 <fungi> oh, there was a requirements freeze related thread on the -dev ml while you were sequestered
14:35:54 <fungi> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/098196.html [openstack-dev] [constraints] Updating stable branch URL
14:36:13 <fungi> could use some release team input on current process and/or proposed changes to the same
14:36:21 <dhellmann> FYI, I'll be going offline right after our meeting next week to prepare for the trip to EuroPython. It shouldn't affect the N2 tagging, though.
14:37:14 <ttx> I'll be off traveling Wednesday, then mostly off Thursday/Friday
14:37:35 <ttx> Something about a revolution in the 18th century
14:37:38 <dhellmann> fungi : so the issue is that the URL for the constraints file needs to change after a stable branch is created?
14:37:48 <fungi> summary is that projects consuming constraints need to adjust the url of the constraints file they're downloading when they branch. it doesn't affect automation, but it does affect individual developers running tox locally. the question is basically when and how to update that as part of the release process
14:38:05 <fungi> (and whether, i suppose)
14:38:27 * dhellmann imagines ttx wearing a tricorne
14:38:52 <dhellmann> fungi : that sounds like something we could solve with an apache redirect
14:39:08 <fungi> i'm not following
14:39:34 <fungi> how does teh redirect know which branch of the constraints file to send them to?
14:39:38 <dhellmann> if we set up a URL for something.openstack.org/constraints/$series that points to the actual file, we can change the redirect with one patch
14:40:05 <dhellmann> alternately instead of hard-coding a url in the tox file, we could have a little tool that knows how to build the url based on the current branch (maybe reading the .gitreview file?)
14:40:14 <fungi> well, you still need to change $series in those repos though
14:40:34 <dhellmann> true
14:40:42 <dhellmann> so reading the .gitreview file?
14:40:43 <fungi> yeah, that was an alternative proposal, add more scripts to be copied around between projects that know how to retrieve teh right constraints file
14:40:46 <dhellmann> that already has the series in it
14:41:05 <dhellmann> or something that can be pip installed
14:41:23 <fungi> concern there was further complicating tox.ini or adding wrappers to everyone's test runner )e.g. reintroducing run_tests.sh basically)
14:42:03 <fungi> having something pip-installable probably introduces some circular logic we'd have to break, and means multiple pip install stages
14:42:03 <dhellmann> does tox.ini support interpolation using other values in the file?
14:42:13 <dhellmann> I guess we could extend the branching script to modify tox.ini
14:42:40 <fungi> tox.ini supports parameters which can either be defined in the tox.ini or passed as envvars when calling tox or as parameters on the command-line, afaik
14:43:16 <dhellmann> so if we have a SERIES=X parameter in the file, that makes it easier for a script to modify
14:43:44 <fungi> yep, we could certainly make the automated editing of tox.ini easier and less accident-prone
14:43:52 <dhellmann> then we just have to deal with the ordering of branches in projects vs. requirements
14:44:05 <fungi> but "release tools adjusting tox.ini" was still basically the simplest solution anybody settled on
14:44:14 <dhellmann> yeah
14:44:44 <fungi> and correct, the question we left that thread at was when to make that change relative to requirements freeze/branching
14:45:56 <fungi> one suggestion was to branch requirements last instead of first in the release process to shorten the window where things were messy for local constraints use by devs, but i thought there was a reason we had ended up branching requirements first (though couldn't remember then if we did and if so what the reason was)
14:46:43 <fungi> so anyway, more accurate process information and insights from someone on the release team seemed warranted
14:47:19 <dhellmann> hmm
14:47:34 <dhellmann> I thought we branched it later. I'll have to go look back at what we did.
14:47:39 <dhellmann> this is why I want a release manager's guide...
14:48:10 <dhellmann> I'll look into that and respond to the thread
14:48:15 <fungi> yeah, i honestly couldn't recall and haven't had the time to dig back and figure it out
14:48:24 <fungi> thanks!
14:48:47 <dhellmann> ok, anything else?
14:48:52 <fungi> nothing from my end
14:49:11 <dhellmann> if no one else has anything, we can end a bit early today
14:49:36 <ttx> dhellmann: I'll have to skip my release day next week
14:49:43 <ttx> and won't be of much use for N2
14:49:48 <dhellmann> ttx: ok, dims and I will take care of it
14:50:02 * ttx will likely be in a car
14:50:39 <dhellmann> alright, let's call it and spend the remaining 10 minutes on something else
14:50:42 <dhellmann> thanks everyone!
14:50:45 <dhellmann> #endmeeting