14:00:13 #startmeeting releaseteam 14:00:14 Meeting started Fri Jul 22 14:00:13 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:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:17 The meeting name has been set to 'releaseteam' 14:00:20 courtesy ping: ttx, dims, lifeless, tonyb, stevemar, fungi 14:00:30 * fungi grabs courtesy coffee 14:00:37 #link our agenda https://etherpad.openstack.org/p/newton-relmgt-tracking 14:00:40 see R-11 14:01:04 o/ 14:01:13 hola, ttx 14:01:59 ok, let's start 14:02:05 #topic release automation update 14:02:19 oh, that 14:02:26 fungi, it looks like we jumped the gun on the release job and had to turn it back off? 14:02:39 yeah, but now it's fine and being turned back on 14:02:44 ah, good 14:02:53 so we can plan to run some tests next week 14:02:53 i approved that moments ago 14:03:02 #link https://review.openstack.org/344302 Revert "Temporarily disable the tag-releases job" 14:03:17 I have a bug or two I need to work on today, so I am not likely to have time to run tests today, but monday 14:03:43 there was also a change to make that job more verbose, let me find that... 14:03:58 the only other outstanding patch is the documentation on key management process, which i plan to approve early next week if nobody has further feedback on it and then bring it up at the infra meeting on tuesday to get the root sysadmins to start signing it 14:04:07 o/ (partially here) 14:04:08 #link https://review.openstack.org/#/c/343666/ shows the clone output 14:04:11 and that has merged 14:04:23 #link https://review.openstack.org/339248 Document signing key management 14:04:34 is what i'll merge early next week hopefully 14:05:00 I'll add that to my review queue, though I suspect the infra team's input is more important 14:05:43 is there anything else blocking us from testing a release using the release-test repo next week? 14:05:50 nothing to my knowledge 14:05:56 great 14:06:21 #topic deliverables that missed n1 and n2 milestones 14:06:33 we have 4 deliverables from 3 teams that missed the milestones 14:06:48 aodh, ceilometer, trove-image-builder, murano-apps 14:07:13 the latter 2 are not planning releases and need a new release tag. I can propose changing those to release:none 14:07:26 the first two propsoed to change to cycle-with-intermediary 14:07:26 jd__ has already proposed changing aodh and ceilometer to cycle-with-intermediary 14:07:36 #link aodh / ceilometer change to cycle-with-intermediary https://review.openstack.org/#/c/342917/ 14:07:41 yep 14:07:55 that goes a bit against the model freeze but maybe that's backwardcompat 14:08:02 that's a bit late in the cycle to change, but it seems more a more accurate reflection of their intent 14:08:25 frankly it's easier to migrate from milestone to intermediary release 14:08:40 especially if you have one release ready 14:09:08 yes. I'll have to make sure that jd__ is aware that we expect at least one release before the final 14:09:15 dhellmann: ttx: we'd be ok to switch for O, fwiw 14:09:16 My concern is that if they are changing only so that they don't have to care about milestones, then we'll likely have to chase them down to make at least one intermediary releases before the end 14:09:36 ttx: very likely :) 14:09:58 well, we aren't going to do that. projects that fail to release, will just be delisted. 14:10:13 fail to release intermediate or final? 14:10:34 both 14:10:35 jd__: intermediary-released is not a way to do less tagging 14:10:51 it's a way to produce full-featured releases more often than every 6 months 14:10:58 intermediate means you will still be doing at least 2 releases between now and the end (an intermediate one, and the final)_ 14:12:13 what's the tag for "we release every 6 months or so and that's it?" ;) 14:12:22 jd__ : independent 14:12:46 jd__: if you can't be around to do milestones, we doubt taht you can be around to do a RC1 and a final 14:13:17 if you don't have a lot of changes, a milestone model is appropriate because you aren't preparing full releases but you're still indicating that you're actively maintaining the project 14:13:28 the thing is that there has been _0_ value on milestones and RCs, TBH 14:13:41 (for us at least) 14:13:55 so I don't really mind not changing the model and having dhellmann running after me 14:13:56 you don't prepare the milestones for yourselves, you prepare them for your users 14:13:59 but I'm not sure it's sane 14:14:05 RC1 is when you branch, so it's kinda useful 14:14:24 ttx: in Gnocchi we branch at .0, it's good enough, then we do a lot of micro releases 14:14:27 I agree that further RCs are less useful, but then you don't have to do any 14:14:30 jd__ : I'm not going to chase anyone. I'm done with that. From this point on, projects are expected to follow the deadlines, unless they're really new to the process. 14:15:03 branching at 0 and making micro releases sounds like the cycle-with-intermediary process 14:15:05 we have 0 user using the milestones or the RC as far as we know 14:15:16 I had 0 complaint about missing b1 14:15:24 dhellmann: I guess they could do intermediary-release and do just one. The risk is taht they miss and get delisted, but if they are fine with that 14:15:24 except from dhellmann ;) 14:16:14 the risk to skipping rc branching is that there's a window where you'll be testing your future stable branch against everyone else's master branch that has already started to merge changes for the next cycle 14:16:28 fungi : good point 14:16:38 and _not_ testing against anyone else's stable branches _until_ you release 14:16:49 fungi: that's what intermediary-released projects end up with anyway 14:16:54 so you have the chance for your release to be insta-broken basically 14:16:56 preparing a .0 release around the rc period mitigates that 14:17:21 actually the version doesn't matter, because we can branch from anywhere 14:17:27 The only reason why we want intermediary-released stuff to have at least one release before newton-3 is so that we have something to fall back if they don't do a final 14:17:50 right 14:17:56 If the whole team is fine with being delisted if jd__ forgets to do the release in time... 14:18:13 dhellmann: yeah, if the .0 candidate commit is contemporary with everyone else branching (even if it doesn't get tagged right away) that's one way to mitigate 14:18:15 RCs and previous intermediary releases are failsafe 14:18:29 jd__ : what do you think? 14:18:52 It's well known that jd__ never makes a single mistake 14:19:17 I think ttx just summarize everything perfectly *bright smile* 14:19:21 or never gets run over by a bus 14:19:32 or is never stuck in trains in the middlme of nowhere 14:19:36 dhellmann: I honestly don't know 14:19:55 I am really ok to stick with the current model, if you don't frown upon us missing milestones 14:20:04 jd__ : would you be prepared to do a release around the time we're prepping the rc1s so that we can set up your branch along the same schedule as everyone else? 14:20:06 I proposed to change so you would do less frowning 14:20:11 "around the time of or before" 14:20:12 I wanna be your friend :( 14:20:20 dhellmann: sure 14:20:26 I want to not have to think about individual projects... 14:20:49 ok, if you're prepared for that then I think the intermediary model makes sense. 14:20:50 if you're good ignoring us until it's time for RC 14:21:00 jd__: basically we use milestones so that you prove that you read emails and can internalize the release schedule 14:21:13 so that we trust that you'll do teh RC1 in time and not block everyone 14:21:22 ttx: of… course… we… read… how did you call that already, emails? :p 14:21:44 * fungi has heard of emails 14:21:58 I read dhellmann's mails at least, and I think "holy crap, time's flying" 14:22:11 good, that's the intent behind them :-) 14:22:22 "I better not lose time doing milestone, let's keep coding to be ready for RC1" ;-) 14:22:52 jd__: a milestone taks around 30 seconds 14:23:09 ttx: what about doing them automatically with a bot? 14:23:10 and goes a long way into proving you know the release schedule enough not to f*ck us up 14:23:37 the release schedule for Telemetry is basically just 6 months of doing stuff, and then tagging :) 14:23:45 jd__: sure why not, just don't forget to program release in as well 14:24:07 jd__ : there are some scripts in the releases repo you could use to automate them 14:24:32 ok, so I think we agree on the change to cycle-with-intermediary model 14:24:33 dhellmann: but if they don't need RCs I guess single intermediary is an option 14:25:06 and we'll review the results next cycle and consider whether that's working or if there's little enough involvement from the telemetry team to move to release:independent 14:25:28 ++ 14:26:00 #agreed the aodh and ceilometer projects can change to the cycle-with-intermediary model and we'll review the results next cycle and consider whether that's working or if there's little enough involvement from the telemetry team to require a move to release:independent 14:26:21 (also, if they miss end release they will de facto move to independent) 14:26:22 jd__ : I did leave a request for detail on https://review.openstack.org/#/c/342917/, so if you update that I'll +1 it 14:26:28 dhellmann: ack! 14:26:36 ttx: yes 14:27:01 #agreed if aodh and ceilometer miss the final release for newton, that will result in changing to release:independent automatically 14:27:19 ok, I think expectations are clearly documented now 14:27:42 the other 2 projects were described as not releasing by their respective PTLs, so I'll make those changes today 14:27:49 while we are at it, we can do the other gov reviews 14:27:55 mistral-lib addition to mistral deliverable https://review.openstack.org/#/c/340853/ 14:27:59 #action dhellmann change release model of murano-apps and trove-image-builder to release:none 14:28:15 + a question whether you need me to afst-track any or they can wait for the traditional week 14:28:27 fast-track* 14:28:44 let's go ahead and approve them in case those teams want releases 14:29:06 https://review.openstack.org/#/c/345593/ https://review.openstack.org/#/c/340853/ ? Or more ? 14:29:22 those 2 at least, let me look at what else is open 14:30:13 there are a few others I haven't reviewed yet, but I think they all apply to teams using the independent model and tagging their own releases 14:30:22 I'll try to work through that review list today 14:30:56 ok, all set 14:31:06 but we should fast-track the 2 you mentioned and the 1 for telemetry, when those details are added 14:31:28 ok, moving on to our next important topic 14:31:31 #topic team mascot 14:31:32 I'll fast-track the Telemetry one once it has your +2 14:31:39 ack 14:31:49 we've discussed this a couple of times, but I need to submit our final request 14:32:16 how did the discussion of giant squid go? 14:32:26 did we decide to fall back to "herding dog"? 14:32:37 We can propose both. 14:32:39 giant squid (also colossal squid) are perfectly within the bounds of nonfiction 14:32:43 +1 to giant squid 14:32:48 Several teams suggested some kind of squid/kraken 14:32:58 colossal squid are a little cooler, but whatevs 14:33:07 so it may or may not work, but we can propose it as #1 14:33:08 hmm, ok, we might have missed our chance at that one then 14:33:18 ok, I'll send in those 2 entries 14:33:28 did we have any others? 14:33:30 do we need a 3rd choice ? 14:34:14 conch? 14:34:27 (sounding the release horn) 14:34:30 ah 14:35:15 ++ fungi 14:35:17 or a ram 14:35:34 sea life seems to be popular in general across teams. maybe plants would be a good alternative? nobody seems to be picking any even though they're perfectly valid 14:35:50 or coral, since we are coralling projects. And it's an unlikely animal 14:35:57 hah--yes 14:36:17 (it also has a peculiar way of releasing eggs) 14:36:31 corraling heh 14:36:37 corralling actually 14:36:56 not to be confused with carolling 14:37:06 https://www.youtube.com/watch?v=Pk7yqlTMvp8 14:37:15 fungi I suggested barley and hops for infra those are fun plants 14:37:34 ttx: LOL 14:37:47 clarkb : ++ 14:38:23 ok, how many of those ideas should I include in our list? 14:38:59 I'll admit the whole coral idea is pretty far-stretched 14:40:09 yeah, I'm not sure I want to have to explain that to everyone every time they see the logo :-) 14:40:15 We could still the beaver since they vut branches 14:40:17 steal* 14:40:25 but someone else wanted ti 14:40:31 it* 14:40:35 the requirements team, I think? 14:40:44 they want to build dams 14:41:19 oh well, let's only propose 2, and come back to drawing table if both miss 14:41:21 something like that 14:41:31 yeah, ok, so giant squid and then border collie 14:42:11 ok, moving on 14:42:14 ++ 14:42:18 #topic priority reviews 14:42:27 it looks like all of the items I listed are merged, do we have any others? 14:42:33 nope 14:42:38 not from me 14:42:44 good 14:42:48 #topic governance reviews 14:42:57 oh, we covered this earlier 14:43:04 #topic open discussion 14:43:20 is there anything else we need to note? 14:43:24 I'm off starting Tuesday next week (real vacation ,yay) 14:43:31 congrats! 14:43:33 so yet again missing my release day 14:43:38 we'll cover, no worries 14:43:46 speaking of that, thanks dims for covering for us this week 14:43:58 yay, thanks++ 14:44:18 maybe for r-9 we can plan a status check to see where we are on our todo list 14:44:22 dhellmann : fungi : i think we need to retrigger ci jobs for https://review.openstack.org/#/c/344547/ (or cleanup tag and retag?) 14:44:53 dims_ : are they asking to reuse a version number? 14:45:22 dhellmann : i think when we cut the tag the jobs were not in place to actually cut the artifacts 14:45:29 ah 14:45:45 dims_ : are the tags on the right commits now? 14:45:49 would be good to find a way to detect that before it requires manual intervention 14:46:02 fungi : we've added a validation step for that to the releases repo 14:46:14 cool 14:46:15 we were missing this new release type, since they use different jobs, but we've corrected for it 14:46:32 that's actually part of what broke us when mistral-extra stopped doing releases 14:47:01 dhellmann : i think we have to delete the tag 14:47:05 we need a job that prevents removing the release jobs from zuul/layout.yaml if the deliverable is still described in the governance repo, requirements repo, or releases repo 14:47:13 okay, so there is an existing 1.4.13.0 tag on xstatic-angular-smart-table and they didn't need to alter the contents of their repo? 14:47:26 we can't delete tags. they'd need to be 1.4.13.1 or something this time 14:47:36 if they need to tag a different commit 14:47:37 * dims_ goes and re-reads comments 14:48:07 the validation job passed, so they're either using new version #s or the version is on the same commit 14:48:13 also i'm surprised that a four-component version number worked. i didn't realize we had edited our release pipeline regexes to accommodate that 14:48:40 maybe we should recheck that 14:48:49 because the job output says this is a new version 14:49:03 ref: ^refs/tags/[0-9]+(\.[0-9]+)*$ 14:49:34 oh, right, it's supported any number of version components for ages. it's pbr that freaks out on anything other than 3 14:49:36 fungi : they have a separate release job: xstatic-publish-jobs 14:49:39 dhellmann : let's talk to robcreswell 14:49:48 and xstatic packages are non-pbr so probably fine 14:50:14 dims_ : ack. I'm going to drop a recheck on that patch now that we've merged the new validation changes 14:50:36 ++ dhellmann 14:51:25 aha. the existing tag is 1.4.13 14:51:31 fungi : we'll send robcreswell to the infra channel if we need something re-run 14:51:33 and they're asking for 1.4.13.0 14:51:56 ah, that explains it 14:52:00 ok, so maybe this will just work? 14:52:28 we'll see 14:52:37 we're about out of time, is there anything else to cover? 14:52:41 probably? i have no idea if other xstatic packages we're maintaining use 4-component versions, but hopefully 14:53:28 they do 14:53:49 I hope we didn't build any 3 digit assumptions into any of the release tools 14:53:50 the first 3 are the upstream package ver and 4th is xstatic appended 14:55:00 clarkb : ok, cool, so we can try processing this normally early next week (since it's a lib, not on a friday) 14:55:03 yeah, i know that's what it's supposed to be, just didn't know if we'd worked out the kinks (i'm betting the solution ended up being just don't use pbr for xstatic packages) 14:55:13 probably 14:55:51 alright, I think we're done, so let's close the meeting 14:55:56 thanks everyone! 14:56:23 #endmeeting