14:01:22 <dhellmann> #startmeeting releaseteam
14:01:23 <openstack> Meeting started Fri Apr  1 14:01:22 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:26 <openstack> The meeting name has been set to 'releaseteam'
14:01:28 <ttx> o/
14:01:34 <dhellmann> courtesy ping: ttx, dims, lifeless, ajiang
14:01:55 <dhellmann> that should have been AJaeger
14:02:08 <dhellmann> our agenda is under R-1 in https://etherpad.openstack.org/p/mitaka-release-tracking
14:02:19 <dhellmann> #topic dead links on mitaka page
14:02:29 <dhellmann> thanks for doing that review, ttx
14:02:31 <dhellmann> #link https://etherpad.openstack.org/p/dude-where-are-my-tarballs
14:02:41 <ttx> I have to admit I found more than I expected
14:02:42 <dhellmann> we have some fixes in the queue already, some are easy
14:02:49 <dhellmann> #info fix tarball base setting for a few projects: https://review.openstack.org/300457
14:02:59 <dhellmann> some are harder
14:03:02 <dhellmann> #info drop unpublished murano-apps: https://review.openstack.org/300473
14:03:13 <dhellmann> I don't know if we want to do that, or just turn their tarball link setting to "none"
14:03:49 <dhellmann> I added that setting for one of the deployment projects (ansible or puppet?) since they don't build tarballs
14:04:05 <dhellmann> what do you think? delist or just turn off the links?
14:04:06 <ttx> checking 300457
14:04:58 <ttx> +2
14:05:10 <ttx> looking at murano-apps
14:05:44 <ttx> We could no-tarball it
14:05:55 <ttx> as a first step
14:05:58 <dhellmann> yeah, that feels better, I'll make that update
14:06:06 <ttx> then discuss with PTL if it makes sense to even list
14:06:36 <ttx> what about monasca-thresh
14:06:39 <dhellmann> yeah, same for astara
14:07:31 <dhellmann> I was going to treat monasca-thresh the same way, but haven't submitted that one
14:08:10 <ttx> feels like an oversight in the case of monasca-thresh, not even sure how functional monasca is without it
14:08:18 <dhellmann> they have a bunch of missing parts to their release build, I need to discuss with rolland when he comes online
14:08:25 <dhellmann> yeah
14:08:38 <ttx> murano-apps is a different animal
14:08:46 <ttx> it probably has no jobs on purpose
14:09:18 <dhellmann> what is that?
14:09:30 <ttx> hmm
14:09:36 <ttx> so monasca-thresh is a Java component
14:10:18 <dhellmann> hmm, I don't think we even know how to publish that
14:10:23 <ttx> (cue told you so music about accepting Java bits without toolchain to handle them)
14:11:04 <dhellmann> yeah
14:11:11 <dhellmann> I see a couple of options:
14:11:15 <dhellmann> 1. no-tarball
14:11:16 <ttx> dhellmann: yeah, so no-tarball them and then open another review to just drop it from "mitaka"
14:11:19 <dhellmann> 2. delete entirely
14:11:30 <dhellmann> 3. build the "tag but don't show" feature
14:11:41 <ttx> personally I don't think something without a proper job to build a source code tarball can be "released"
14:11:49 <dhellmann> wfm
14:12:06 <dhellmann> if we're going to delete it, there's no need to no-tarball them, right?
14:12:12 <ttx> so I'll +2 the removal from mitaka, but will let the PTL defend themselves before
14:12:19 <dhellmann> ah
14:12:27 <ttx> sure. I just want to remove the 404
14:12:30 <ttx> immediately
14:12:38 <dhellmann> sure
14:12:43 <ttx> and then decide what is the long-term solution
14:13:04 <dhellmann> are we talking removing all of monasca, or just thresh?
14:13:34 <ttx> murano-apps is a collection of murano packages, which is a bit specific too
14:13:54 <ttx> just thresh...
14:14:04 <ttx> I bet people can find it somewhere else like on maven
14:14:20 <ttx> which is why nobody bothered to create tarball jobs
14:14:51 <ttx> also source code is kind of a dirty thing in Java land. they release jars
14:15:10 <dhellmann> ah
14:15:18 * dhellmann is ignorant of these things
14:15:25 <ttx> don't even get me started
14:15:30 <dhellmann> let's keep moving, then :-)
14:15:33 <dhellmann> #info add missing release jobs: https://review.openstack.org/300474
14:15:52 <dhellmann> those are the projects where it seemed to make sense to add the missing jobs
14:18:40 <dhellmann> looks like there's a validation failure, so I'll keep working on that
14:18:40 <ttx> for fun, http://ttx.re/the-real-problem-with-java-in-linux-distros.html
14:18:40 <dhellmann> #info add validation for release jobs: https://review.openstack.org/300492 and https://review.openstack.org/300493
14:18:40 * dhellmann adds blog post to his reading list
14:18:40 <ttx> bit old, still valid :)
14:18:40 <dhellmann> there's sample of the combined validation output in http://paste.openstack.org/show/492734
14:18:40 <dhellmann> I should probably not require the jobs when we have tarball mode set to none, so I'll add that as a third patch
14:18:40 <dhellmann> is there anything else on the links topic?
14:18:45 <ttx> does that cover them all ?
14:19:00 <ttx> do we have a fix for monasca-log-api
14:19:30 <dhellmann> oh, I missed that one at the top
14:19:42 <dhellmann> I'll no-tarball that, too
14:20:04 <ttx> What about monasca-ceilometer
14:20:14 <ttx> not in https://review.openstack.org/#/c/300474
14:20:22 <ttx> intentional ?
14:20:35 <dhellmann> ah, andreas pointed out they didn't have the venv setting in tox, so I'll treat it the same as log-api
14:20:50 <ttx> ok
14:21:01 <ttx> They also don't have the zuul layout thing I suspect
14:21:06 <dims> o/ fashionably late. sorry
14:21:08 <dhellmann> probably
14:21:12 <dhellmann> hi, dims
14:21:52 <dhellmann> unfortunately I often don't see rolland on irc, so I'll try email to contact him
14:22:24 <dhellmann> ttx, should I copy you or openstack-dev on that email since I won't be around a lot of next week?
14:22:51 <dhellmann> I'll send it to the dev list, no reason not to do this publicly
14:22:55 <ttx> ack
14:23:06 <dhellmann> ok, moving on then
14:23:09 <dhellmann> #topic cinder
14:23:24 <dhellmann> I asked yesterday on irc and the cinder cores I could find seemed surprised that they might need an rc3
14:23:29 <dhellmann> smcginnis wasn't online at the time
14:23:47 <ttx> well, they don't need it that much
14:23:50 <dhellmann> I expect they'll want a patch release after the final for those translations
14:23:52 <dhellmann> yeah
14:23:59 <ttx> could have been useful to refresh translations to pick up Wed/Thu
14:24:16 <ttx> but not critical if they missed
14:24:22 <dims> ++
14:24:25 <ttx> a bit worrying that they would not be available/around though
14:24:31 <dhellmann> the thing with master is concerning, but can be dealt with
14:24:43 <ttx> yeah, I just don't want to forget about it
14:24:50 <dhellmann> yeah, I'm not sure about the story there
14:25:02 <dhellmann> ok, it's noted on the dashboard, too
14:25:18 <dhellmann> do you think we need to push them to deal with merging the patch?
14:25:48 <ttx> it's like every time you think you can propose both master and stable/mitaka (saying master will merge anytime now) it takes ages to merge in master and merges straight away in stable
14:26:08 <dhellmann> maybe we should encourage them to use depends-on
14:26:14 <ttx> which is why I try to strictly enforce the "must merge in master first" rule
14:26:21 <dhellmann> I wonder if that works across branches of the same repo
14:26:22 <ttx> dhellmann: well no
14:26:34 <ttx> dhellmann: we use teh same changeID
14:26:39 <dhellmann> oh, right
14:26:41 <dims> right, won't help
14:26:57 <ttx> and wouldn't prevent them from merging anyway
14:27:15 <dhellmann> last cycle we met with ptls regularly, this cycle not at all
14:27:24 <dhellmann> maybe next cycle we need to do a pre-release meeting near the end of the cycle?
14:27:38 <dhellmann> "we won't process your release until you come around and have this chat"
14:27:38 <ttx> what we need is some kind of magic check that would look into a stable change and check that it's a straight backport (or has a #different_but_this_is_normal warning tag in the commit message)
14:28:08 <ttx> that way you wouldn't unintentionaly shoot yourself in the foot
14:28:43 <dhellmann> what about just a check that looks for the cherry-pick in the commit message, and requires a change with that id in master?
14:28:48 <ttx> not sure what the solution is, but that's something we should discuss
14:28:48 <dhellmann> it wouldn't have to look at the contents
14:29:03 <ttx> that would be great already
14:29:15 <dims> ttx : dhellmann : how about language in the bot adding a snippet saying "This change should be merged in master first before you approve in stable"?
14:29:21 <ttx> you need a way to disable it though, some patches just don't get to master (like different translations)
14:29:30 <dims> so at least they have a heads up
14:29:32 <dims> y
14:29:49 <ttx> let's brainstorm that in postmortem / in Austin
14:29:51 * dhellmann adds a note to https://etherpad.openstack.org/p/newton-relmgt-plan
14:29:54 <dims> ++
14:30:00 <ttx> nothing we can change now
14:30:07 <dhellmann> ttx: if there's no cherry-pick reference in the commit message, the check would pass
14:30:07 <dims> y too late
14:30:20 <ttx> although watching stable/mitaka now that we are in pre-reelase freeze for "accidental" merges would be good too
14:30:40 <dhellmann> yeah, we should -2 everything in the branch I guess
14:30:50 <ttx> https://review.openstack.org/#/q/branch:stable/mitaka+is:merged
14:31:16 <ttx> looking good so far, only a few translations merged in cinder
14:31:21 <dhellmann> ttx, if I -2 the pending patches I won't be around to lift the ban
14:31:29 <dhellmann> do you want to do it?
14:31:49 <ttx> or we can revert spurious things
14:31:50 <dhellmann> or do you want to leave it open, and revert anything if we end up needing a release?
14:31:51 <dhellmann> yeah
14:31:56 <dhellmann> let's do that, less work up front
14:32:01 <ttx> -2 is a bit task-intensive and brittle, since that relies in regular reviews
14:32:02 <dhellmann> more for the team that doesn't follow the rules
14:32:10 <dhellmann> right
14:32:23 <dhellmann> ok, moving on...
14:32:28 <dhellmann> #topic other fires
14:32:41 <dhellmann> do we know of anything else, or was this just in case something came up? :-)
14:32:55 <ttx> just in case something came up
14:32:58 <dhellmann> ok
14:33:02 <ttx> or I forgot something important
14:33:06 <dhellmann> #topic step-by-step release week actions
14:33:11 <ttx> that were just the fires I could see
14:33:25 <dhellmann> how about if we work these steps out in the etherpad so I don't have to try to copy them over in the right order?
14:33:27 <ttx> ok, so for here I'd like to know what we'll have to do next week
14:33:33 <ttx> ack
14:33:45 <dhellmann> there's already a "release tasks" section under R-0
14:34:17 <dims> dhellmann : "unfreeze requirements in master"
14:34:52 <dims> LOL i wish
14:35:05 <dims> (password typing repeatedly)
14:35:13 * dhellmann might temporarily turn off the passphrase on his gpg key for that step
14:35:53 <dhellmann> ttx, there shouldn't be any races because it will be one patch to the releases repo
14:36:08 <ttx> ah.
14:38:05 <dhellmann> I may need to send that announcement a bit earlier than usual
14:38:29 <ttx> what time would you send it ?
14:39:02 <ttx> dhellmann: the old process took about 7 hours to run with all the Launchpad stuff
14:39:04 <dhellmann> well you said "shortly before 10" and I might want to do it closer to 9?
14:39:18 <ttx> which is why we'd wait around 10am CT anyway to do it
14:39:28 <ttx> but we can certainly have a more precise hour
14:39:39 <ttx> ok, let's target 9am CT
14:39:49 <dhellmann> yeah, if I'm up early CT to do the first couple of steps, I'd like to just announce right away so I can go back to my holiday :-)
14:40:03 <dhellmann> 9 seems like a safe upper bound, sure
14:40:07 <dims> :)
14:40:31 <dhellmann> we can prep the patch to switch to released today and then approve it next week
14:40:41 <dhellmann> the series status, that is
14:41:06 <ttx> dhellmann: "update acls for stable/mitaka service projects to allow changes from the team stable maintainers (revert previous change)"
14:41:17 <ttx> that's https://review.openstack.org/#/c/298866/ right
14:41:37 <dims> do we have to do anything on launchpad?
14:42:11 <dhellmann> ttx: I thought it was the +2 rights?
14:42:48 <dhellmann> ttx: https://review.openstack.org/#/c/292781/
14:42:54 <ttx> oh, the tagging rights
14:43:13 <ttx> right so that's a different thing
14:43:14 <dhellmann> we want to give them +2 but keep tagging
14:43:29 <dhellmann> yeah, it may not be a straight revert, we might want to prepare those patches today, too
14:44:42 <ttx> dhellmann: I fear those will need rebasing by next week
14:44:56 <dhellmann> probably
14:45:07 <dhellmann> rebasing will be faster than figuring it out from scratch
14:46:43 <ttx> Ack ,added prep to the "before Thursday" section
14:47:01 * ttx checks out old release cheat sheets for things we are forgetting
14:47:02 <dhellmann> yeah, I'll do that today and prepare them as a patch series so the rebasing will go more smoothly next week
14:47:25 <dhellmann> ttx: we should open the g-r repo, I'll remove my -2s there today
14:47:47 <ttx> oh haven't done that yet ?
14:48:09 <dhellmann> no, I've been letting it slide because of late releases and folks weren't pushing for it
14:49:45 <ttx> adding everything I can think of
14:49:58 <dhellmann> yeah
14:52:18 * dhellmann makes a note to pack a candle
14:52:39 <dhellmann> this feels like a complete list, ttx
14:52:42 <ttx> dhellmann: could you be more explicit as to when you will be fully unavailable next week ?
14:52:51 <dhellmann> let me look at the calendar, just a sec
14:53:07 <ttx> so taht I know when to wait for you and when to just make a call
14:53:13 <dhellmann> we travel monday night, so I'll have some email Monday
14:53:25 <ttx> dims: what is your availability looking like next week ?
14:53:47 <dhellmann> tuesday I'll have email on my phone and a laptop that night (european time)
14:53:52 <ttx> if we get broken by library updates it will more likely be over the weekend
14:53:53 <dims> ttx : i'll be around all week
14:54:18 <dhellmann> I'll have access again at some point wednesday evening
14:54:31 <dhellmann> I'm planning to work thursday morning until 9-10
14:54:40 <dhellmann> I'll be up early to get an early start
14:54:53 <ttx> could you add that to the etherpad ?
14:54:56 <dhellmann> sure
14:55:47 <ttx> oh, and.. no library release on our side
14:56:00 <ttx> will have plenty enough risk with the things beyond our control
14:56:22 <dims> y
14:56:46 <ttx> dhellmann: it doesn't look too bad, definitely doable if there is no unexpecetd failure somewhere
14:56:51 <dims> i have znc setup, so now i can check for my nick when i get back online too
14:57:06 <dhellmann> ttx: direct email to me will always buzz my phone, irc is going to be trickier
14:57:27 <ttx> dims: thx a lot for your availability btw, 3 people is not too much :)
14:57:33 <dhellmann> my travel access to irc right now is not great because of the new laptop
14:57:56 <dhellmann> yeah, dims, thank you for helping so much!
14:57:58 <ttx> dhellmann: you can pm me you phone number and I can text you in case of horrible urgency
14:58:05 <dhellmann> ttx: absolutely
14:58:17 <dims> my pleasure
14:59:08 <dhellmann> I have a call starting in a minute, so I should close us out
14:59:18 <dhellmann> see you in #openstack-release
14:59:19 <dhellmann> #endmeeting