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