14:00:26 <dhellmann> #startmeeting releaseteam
14:00:27 <openstack> Meeting started Fri Dec  4 14:00:26 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:31 <openstack> The meeting name has been set to 'releaseteam'
14:00:35 <dhellmann> courtesy ping: ttx, jokke_, dims, lifeless
14:00:43 <ttx> o/
14:00:59 <dims> o/
14:01:10 <dhellmann> our meeting agenda is in the R-18 section of https://etherpad.openstack.org/p/mitaka-relmgt-plan
14:01:43 <dhellmann> #topic actions from last week
14:01:51 <dhellmann> 1. dhellmann work on announce script
14:02:10 <dhellmann> that work has merged, but there's still a remaining step to add reno notes to the output for projects using reno
14:02:19 <dhellmann> I'll be looking at that next week
14:02:34 <dhellmann> that's the only thing I had as actions from last week, did I miss anything?
14:02:51 <dhellmann> ok, moving on
14:02:52 <dhellmann> #topic Finalize m-1
14:03:12 <dhellmann> we have zaqar's request and it looks like their gate is fixed now?
14:03:26 <ttx> the gate was in bad shape this morning
14:03:26 <dhellmann> the mistral team forgot to request a tag for mistral-dashboard, and they've asked what they should do
14:03:34 <ttx> well, bad shape.. it allowed everything in
14:03:43 <ttx> so maybe the zaqar tests were lucky
14:03:52 <dhellmann> oh, wow, ouch
14:04:26 <dhellmann> so the question then is, do we go ahead and tag these projects?
14:04:31 <ttx> mistral-dashboard ? is it part of the mistral deliverable ?
14:04:43 <dhellmann> that's not clear
14:04:50 <ttx> dhellmann: there is still time, haven't sent anyu annoucement
14:05:00 * ttx checks
14:05:18 <ttx> how far is zaqar ?
14:05:48 <ttx> yeah, so mistral-dashboard is a separate deliverable
14:05:54 <ttx> but also release:cycle-with-milestones
14:06:06 <ttx> it should probably be in the same deliverable actually
14:06:07 <dhellmann> they added the unreleased page for reno and have their release request submitted on time
14:06:16 <ttx> unless they really can't do, say, RCs at the same time
14:06:56 <ttx> ok, so zaqar is all set ? I think we should include it
14:07:09 <dhellmann> I'm tempted to hold firm on the deadline and  not tag either, but I don't know if that's too punitive
14:07:29 <ttx> they submitted in time, and we could fix them before the announcement
14:08:09 <dims> stern warning? :)
14:08:19 <dhellmann> ok, I guess that's fair. They did have a long time to add reno, but left it until the last minute.
14:08:36 <dhellmann> dims : yeah, I'll talk to flwang
14:08:46 <ttx> "almost missed"
14:08:52 <dhellmann> ok, so zaqar is in, what about mistral-dashboard?
14:09:10 <ttx> when did the tag come in ?
14:09:22 <dhellmann> they haven't submitted it yet, I have a private email asking me what they should do
14:09:28 <ttx> oh then well
14:09:31 <ttx> I'd say no
14:10:23 <ttx> if only because I want to announce in the next 20 min
14:10:45 <dhellmann> yeah, I'll reply back that we should sort out whether that is the same deliverable or a separate one before M2 and that it won't be included in M1
14:10:52 <jokke_> o/ ... bit late
14:10:56 <dhellmann> ttx: ok, do you want to go ahead and handle zaqar?
14:11:07 <dhellmann> that way you can announce as soon as it's done
14:11:14 <ttx> also they are not release:managed so I don't feel as much responsibility to them
14:11:23 <ttx> yep will start the process in parallel
14:11:45 <ttx> dhellmann: waiting for your +2
14:12:04 <dhellmann> done
14:12:16 <dhellmann> I see that murano has gone ahead and tagged their m1 and have submitted a patch after the fact to record it
14:12:46 <ttx> and they don't have the setup.cfg version cleanup
14:12:47 <kzaitsev_mb> dhellmann: yes, well, since we're not release:managed I figured that'd be the correct way to do it
14:12:49 <dhellmann> we did that at the end of liberty, so I suppose it's ok to do that for milestones, once they complete the remaining steps
14:13:22 <dhellmann> kzaitsev_mb : yes, no problem, we're just talking things through
14:13:52 <dhellmann> kzaitsev_mb : see ttx's comments on the patch for some other things we need you to do
14:14:21 <kzaitsev_mb> I see, that we need to remove versions from setup.cfg. would do that as soon as the gate gets back in order, currently working on that )
14:14:26 <kzaitsev_mb> ok, thanks, will do.
14:14:31 <dhellmann> kzaitsev_mb : great, thanks!
14:14:44 <dhellmann> #topic retrospective on M1
14:14:46 <ttx> not sure if I should include that in the announcement
14:14:56 <dhellmann> #undo
14:14:57 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x9562450>
14:15:10 <ttx> #link https://etherpad.openstack.org/p/m1-announcement
14:15:23 <ttx> I was wondering if I should add the links to release notes
14:15:38 <ttx> but I decided against it since the release notes are not mitaka-1 specific
14:15:52 <ttx> and may already include more than what is in mitaka-1
14:16:03 <dhellmann> yeah, that's the same reason I didn't include links in the releases repo for mitaka, either
14:16:21 <ttx> comments on that ? should we merge the murano request and include it here ?
14:16:29 <dhellmann> as far as the announcement, maybe it makes sense to focus on managed projects this time?
14:16:46 <ttx> I thought we could encourage others following the process
14:16:50 <dhellmann> I guess I'm +0 on including it
14:16:57 <dhellmann> ah, sure, that's a good point
14:17:01 <dhellmann> ok, +1
14:17:29 <dhellmann> so do we want to go ahead and merge the patch now, or wait until the other work is prepared?
14:17:40 <ttx> ah, hm.
14:17:57 <ttx> I guess we should skip murano since it's not ready at announcement time.
14:18:18 <ttx> I want them all to appear in http://docs.openstack.org/releases/releases/mitaka.html and would rather not merge the release request until they are clean
14:18:26 <dhellmann> yeah, we have to draw the line somewhere
14:18:36 <dhellmann> I agree, I want everything recorded, even if we're not doing the tagging for them
14:18:48 <ttx> again, give encouragement to those who followed the guidelines you sent
14:18:50 <dhellmann> maybe we should announce that formally
14:19:34 <ttx> I expect some other projects to have pushed a random 0b1 tag while we were looking the other way
14:19:35 <jokke_> ++
14:20:01 <dhellmann> #action dhellmann send email encouraging unmanaged projects to record their m1 releases in the releases repository
14:20:27 <ttx> ok, so do we have anything else to add to the announcement email ?
14:20:31 * ttx adds zaqar
14:21:15 <dhellmann> I assume you've already made the complete list of projects based on the tracking etherpad
14:22:04 <dhellmann> what you have looks good, so I don't have anything to add
14:22:05 <ttx> I actually extracted it from http://docs.openstack.org/releases/releases/mitaka.html this morning
14:22:20 <ttx> with way too much manual juice
14:22:31 <dhellmann> I had intended to write a script to read the yaml files, but didn't get to it yesterday
14:22:36 <ttx> once we agree on format I can automate it
14:22:50 <dhellmann> what you have looks pretty good to me
14:23:04 <ttx> ok, I'll let the post-merge publish job run first and send the announcement asap
14:23:11 <dhellmann> ++
14:23:15 <dhellmann> is there anything else on this topic before we move on?
14:23:18 <ttx> nope
14:23:30 <dhellmann> #topic retrospective on M1
14:23:43 <dhellmann> I was pleased with the way most of the milestone worked out
14:23:56 <dhellmann> we only had a couple of liaisons show up asking "what is reno?" this week
14:24:12 <dhellmann> most projects had it integrated with time to spare before tagging their milestone
14:24:18 <ttx> and one also showing up not being subscribed to [release] emails
14:24:25 <ttx> maybe the same
14:24:41 <dhellmann> yes, that person fell into my "couple" aggregation
14:25:03 <dhellmann> I also had someone say they were behind on reading the messages, but that they did have them going to a special folder
14:25:11 <ttx> I was actually surprised everyone had their reno ducks mostly in line
14:25:22 <dhellmann> yes, me, too
14:25:37 <ttx> and also that the rather complex instructions were mostly followed. So good point
14:25:40 <dhellmann> there's still some confusion about how it works, and I think part of that is due to the bug that mtreinish and bknudson found related to merge commits
14:25:57 <ttx> oh well, that's what a m-1 is for
14:25:59 <dhellmann> because sometimes merged notes are being missed entirely
14:26:26 <ttx> I'm actually very happy we could get most of the thing in place before the m-1 week
14:26:37 <dhellmann> yeah, I tried to keep things simple but at some point it was just necessary to start educating folks
14:26:41 <ttx> we'll review what we missed and still need to do in a few
14:26:52 <dhellmann> right
14:26:54 <ttx> but it doesn't feel like that much
14:27:19 <dhellmann> do you think the countdown emails are helping?
14:27:22 <ttx> we should watch those setup.cfg removal merges as well
14:27:46 <ttx> I think they more clearly put the blame for not following onto the liaison
14:27:57 <dhellmann> #link retrospective on M1
14:27:59 <dhellmann> oops
14:28:01 <dhellmann> #undo
14:28:02 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x98d72d0>
14:28:02 <ttx> so yeah, I think the countdown emails are helping
14:28:09 <dhellmann> #link https://review.openstack.org/#/q/topic:remove-version-from-setup,n,z
14:28:34 * dhellmann may need to restart his browser
14:29:38 <dhellmann> ok, moving on
14:29:40 <dhellmann> #topic status review of all projects listed at the top of this etherpad
14:29:56 <dhellmann> I went through these items this morning to try to spot the ones that were completed
14:30:20 <dhellmann> the lists are growing long enough that I think we need a better way to highlight TODO vs notes, so I'm going to go back through and add TODO to lines that are actions we need to take
14:30:36 <ttx> ok, let's start with "    enabling new model for milestones"
14:30:39 <dhellmann> now that we're past m1, I'll also unbold those things
14:35:43 <ttx> ok, I think the first one looks good
14:35:56 <dhellmann> yep, let's look at stable branches
14:37:26 <dhellmann> when does that election close? early next week?
14:37:32 <ttx> so on the stable part we may ned to start encouraging releases there before the end of month
14:37:45 <ttx> yeah, election closes Tuesday
14:37:49 <dhellmann> we have a bunch of stable releases queued up for review, actually
14:37:56 <ttx> then I push the governance patch
14:37:56 <dhellmann> #link https://review.openstack.org/#/dashboard/?foreach=is%3Aopen&title=Releases+Inbox&mitaka=project%3Aopenstack%2Freleases+file%3A%5Edeliverables%2Fmitaka%2F.%2A&liberty=project%3Aopenstack%2Freleases+file%3A%5Edeliverables%2Fliberty%2F.%2A&kilo=project%3Aopenstack%2Freleases+file%3A%5Edeliverables%2Fkilo%2F.%2A&juno=project%3Aopenstack%2Freleases+file%3A%5Edeliverables%2Fjuno%2F.%2A&independent=project%3Aopenstack%2Freleases+file%3A%5Ed
14:37:57 <dhellmann> eliverables%2F_independent%2F.%2A&all+releases=is%3Aopen+project%3Aopenstack%2Freleases&tools=project%3Aopenstack%2Dinfra%2Frelease%2Dtools
14:38:00 <dhellmann> oh, ugh, too long
14:38:14 <dhellmann> #link http://bit.ly/1jDpuk8
14:38:34 <ttx> yeah, I'm more concerned about those not queued for review yet. But agree we may need to process those first :)
14:38:41 <dhellmann> yeah :-)
14:39:04 <dhellmann> I've been including reminders in the countdown emails, but maybe a separate email would make sense
14:39:09 <ttx> with m1 behind us we'll have more time to finalize the hand-off there
14:39:16 <dhellmann> right
14:39:28 <ttx> comms overhaul ?
14:40:06 <ttx> looking good
14:40:13 <dhellmann> post versioning
14:40:28 <dhellmann> that's going pretty well, too
14:40:31 <ttx> yep
14:40:41 <ttx> we might want to add a task to track stragglers
14:40:44 <dhellmann> we should encourage unmanaged teams to remove the version line
14:41:12 <ttx> also what did we decide for end of cycle / start of new one ? Should just work ?
14:41:31 <ttx> i.E. no need to put a version line back for handling the first commits ?
14:41:56 <dhellmann> yeah, lifeless convinced me that folks should only be tracking a single branch in a given environment, so the fact that we have 2 commits in different branches with the same version is not a problem
14:42:30 <ttx> ok, automation ?
14:42:36 <dhellmann> yep
14:43:30 <dhellmann> I have some comments on that spec I need to reply to. I'll try to do that today
14:43:58 <dhellmann> fungi and I talked about it earlier this week, and it's on the agenda for the infra team to review next tuesday, so I have that as a deadline
14:44:39 <dhellmann> next up, dropping launchpad
14:46:46 <ttx> release status page, nobody complained about it. I should probably phase it out
14:47:40 <dhellmann> do you think folks will look at that after the milestone announcement?
14:47:55 <ttx> well let's see
14:48:01 <ttx> I won't remove it tomorrow anyway
14:49:07 <dhellmann> yeah
14:49:28 <ttx> dhellmann: I propose we update the rest of them another week, I think we cover all the critical/urgent ones
14:49:35 <dhellmann> sounds good
14:49:38 <ttx> oh, maybe the reno stuff
14:50:00 <dhellmann> what happened
14:50:09 <ttx> I just move reno up
14:50:23 <dhellmann> oh, some of the formatting below it looks off now
14:50:26 <dhellmann> there we go
14:51:14 <dhellmann> ok, let's move on to the next agenda item then
14:51:21 <dhellmann> #topic Update on current library release process
14:51:26 <dhellmann> ttx, you added this?
14:51:29 <ttx> yeah, that's one of mine
14:51:45 <ttx> Wanted an update on how we do lib releases with the changes in tooling
14:51:58 <ttx> (if the doc is still up to date, it's fine to tell me to rtfm
14:52:00 <ttx> )
14:52:03 <dhellmann> the only thing I did differently was run announce.sh after running release.sh
14:52:17 <ttx> still haven't really done one yet and you'll be away the coming weeks, so better be up to date
14:52:26 <dhellmann> to run announce.sh I had to update my local sandbox to get the new tag
14:53:04 <dhellmann> I thought about creating a wrapper for announce.sh like announce_by_hand.sh and letting that do a clone, like release.sh does
14:53:36 <dhellmann> but it's just 3 or 4 commands, so it wasn't a big deal to do it by hand
14:53:40 <ttx> dhellmann: should we update the top paragraph on release-tools README to also cover libs ?
14:54:02 <dhellmann> yeah, that's a good idea, esp. now that release_postversion.sh isn't the right tool
14:54:10 <dhellmann> I'll take a look at that
14:54:19 <dhellmann> #action dhellmann update library release instructions in readme
14:54:21 <ttx> some of it is on the releases repo too
14:54:38 <ttx> but it's actually simpler to update the release-tools README as we push new tooling
14:54:52 <dhellmann> ok, I'll look at the releases repo instructions, too
14:54:53 <dhellmann> #undo
14:54:54 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x944e750>
14:55:04 <dhellmann> #action dhellmann update library release instructions in release-tools and releases repositories
14:55:15 <ttx> ok, ping me when done and I can be the guinea pig for testing the instructions at least once
14:55:27 <dhellmann> sounds good, I think we have a library release request up as a matter of fact
14:55:38 <dhellmann> #topic open discussion
14:55:47 <dhellmann> is there anything else we need to talk about in the last 5 minutes?
14:55:51 <ttx> dhellmann: just one ?
14:55:53 <ttx> :)
14:56:06 <ttx> nothing comes to mind
14:56:10 <dhellmann> oh, I was thinking of mistralclient but we haev some stable releases, too
14:56:22 <ttx> docs.o.o/releases still not updated
14:56:32 <dhellmann> :-(
14:56:39 <ttx> so that is a good topic of discussion
14:57:02 <ttx> the release process is still dependent on post-jobs with lower priorities
14:57:03 <dhellmann> ttx: it would be good to get your input on https://review.openstack.org/250038
14:57:20 <dhellmann> are all post jobs low priority, or just the ones for releases?
14:57:32 <ttx> well, it's a bit complex
14:57:42 <ttx> tarball jobs generally run as a generic post-job (low prio)
14:57:44 * dhellmann thinks that's the best description of openstack development ever
14:57:47 <ttx> except when triggered by a tag
14:58:08 <ttx> in which case they end up in specific queues (pre-release and release)
14:58:27 <ttx> However openstack/releases postjobs are run in the general pipeline
14:58:34 <ttx> so those are run with lowest prio
14:58:43 <jokke_> any chance that it's caused by the issues with jenkins masters infra is battling?
14:58:45 <dhellmann> it sounds like that's adjustable, though?
14:58:50 <ttx> executed when nothing else requires resources"
14:59:00 <ttx> which can easily take a few hours
14:59:19 <dhellmann> yeah, if we can increase the priority we should bump it up some -- ttx, can you handle that?
14:59:34 <ttx> dhellmann: one does not simply.. bump a postjob priority
14:59:45 <dhellmann> oh, it's not just a configuration setting?
15:00:00 <ttx> nope, you may have to define a completely separate pipeline
15:00:05 <dhellmann> guh
15:00:14 <ttx> anyway, something we should probably look into
15:00:18 <dhellmann> yeah
15:00:22 <ttx> since we have grown that dependency which wasn't there before
15:00:34 <ttx> I'll add it somewhere on the etherpad
15:00:37 <dhellmann> ok, thanks
15:00:51 <dhellmann> we're out of time, and I have a real-space interruption about to happen so I'm going to call the meeting
15:01:17 <dhellmann> good teamwork this milestone!
15:01:26 <dhellmann> #endmeeting