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