19:01:16 <tonyb[m]> #startmeeting releaseteam
19:01:17 <openstack> Meeting started Thu Apr 18 19:01:16 2019 UTC and is due to finish in 60 minutes.  The chair is tonyb[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:20 <openstack> The meeting name has been set to 'releaseteam'
19:01:26 <smcginnis> o/
19:01:32 <ttx> tonyb[m]: is it day yet?
19:01:43 <tonyb[m]> aww man 76seconds late :(
19:01:53 <smcginnis> Man, rough start. :P
19:02:03 <tonyb[m]> ttx: ummm no
19:02:09 <ttx> so no g'day
19:02:20 <tonyb[m]> the sun *should* be up when we're done ;P
19:03:05 <tonyb[m]> well it's early enough ... if I were out and someone siad g'day now it'd be fine
19:03:47 <tonyb[m]> so we don't have dhellmann or evrardjp but I think that's okay  we have logs and they could show up
19:04:13 <diablo_rojo_> IRC hates me today
19:04:15 <diablo_rojo_> I'll be here in one capacity or another
19:04:25 <tonyb[m]> So we have somewhat of an agenda
19:04:29 <tonyb[m]> #link https://etherpad.openstack.org/p/train-relmgt-tracking
19:05:03 <tonyb[m]> Does the release days map look okay?
19:05:14 <tonyb[m]> I just copied what we had for stein
19:05:35 <smcginnis> I'm good with what is there, but also open to switching if anyone else prefers a different day.
19:05:38 <ttx> ++
19:05:50 <diablo_rojo> Works for me
19:06:24 <tonyb[m]> okay
19:08:49 <smcginnis> We seem to have moved the meeting completely to the etherpad. :)
19:08:50 <tonyb[m]> We had some rough spots this week with the ocata tagging timing out and manila and puppet-tripleo not going smoothly
19:09:04 <openstackgerrit> Merged openstack/releases master: Fix announce email project names  https://review.openstack.org/653810
19:09:19 <ttx> The only one that is unclear is the ensure-twine issue
19:09:38 <tonyb[m]> ttx: true
19:09:39 <ttx> We should probably reenqueue this one
19:09:57 <ttx> since it seems random
19:10:17 <ttx> and keep an eye on future fails
19:10:17 <smcginnis> I do wonder if they have a job defined that somehow got us running within a venv.
19:10:21 <smcginnis> Really odd random failure.
19:10:40 <ttx> smcginnis: reenqueuing should show whether it's really random
19:11:07 <smcginnis> True. Then we can know if we need to start digging through the logs closely to see the sequence of events.
19:11:09 <ttx> can you work with fungi to get it reenqueued?
19:11:40 <smcginnis> Error: variable "you" undefined
19:11:42 <smcginnis> :)
19:11:56 <tonyb[m]> LOL
19:12:22 <ttx> well, it was defined on the previous line, you won't escape that easily
19:12:32 <ttx> sean-you
19:12:42 <smcginnis> Contextual assignment. Variable out of scope.
19:12:56 <smcginnis> I'll ping him in infra and see if anyone can pick that up.
19:13:06 <tonyb[m]> smcginnis: Thanks
19:13:13 <ttx> tonyb[m]: so... pike-em?
19:13:23 <tonyb[m]> Yeah
19:13:40 <tonyb[m]> I don't know how I feel about that one really
19:13:44 <ttx> I did mark a bunch with +2 that should be ready to go
19:14:09 <tonyb[m]> there's a lot of 'rot' in the repos a little more than I expected
19:14:14 <tonyb[m]> ttx: thanks
19:14:30 <ttx> but yeah I agree it's a lot of churn for releasing "last" versions that nobody actually wants
19:14:33 <smcginnis> Probably a sign that we should switch to EM as soon as possible before too much rot creeps in.
19:15:06 <tonyb[m]> smcginnis: Yeah I mostly have the patches live to do that
19:15:22 <ttx> tonyb[m]: are they blocked by rot ? I assumed it was more of a difficult time getting PTLs to +1
19:15:31 <tonyb[m]> I think this is informative for queens
19:15:55 <tonyb[m]> ttx: I have like 5? patches out there to fix things that need approval
19:16:13 <tonyb[m]> one of them has a -1 from zuul which I'll need to fix of course
19:16:44 <tonyb[m]> but like the python-aodhclient unit tests don't even work
19:16:55 <ttx> oh, some are hitting teh infamous README check
19:17:03 <tonyb[m]> so that'll be a long debug to fix
19:17:17 <tonyb[m]> yeah a lot have the new readme check thing
19:17:29 <tonyb[m]> some others have related things
19:17:58 <tonyb[m]> I did need to add a new release-model for monasca and add a git reset in validate
19:18:09 <tonyb[m]> let me find those those links
19:18:10 <smcginnis> The good thing with the README checks is they should have that fixed in later branches and just need a backport.
19:18:15 <ttx> yes, ends up being much more work than expected
19:18:23 <ttx> but now that we started...
19:18:29 <ttx> Maybe a good topic to discuss at PTG
19:18:42 <tonyb[m]> Yup.
19:18:44 <ttx> adding
19:18:59 <tonyb[m]> thanks
19:19:01 <smcginnis> Not really sure we need those ones that only update the tox upper-constraint checks. That really only impacts running local tests. It doesn't really change any code.
19:20:16 <tonyb[m]> smcginnis: True
19:20:33 <smcginnis> We could set a policy that EM transitions happen two weeks after a release so that it always lands at a decent point in the cycle.
19:20:48 <smcginnis> But we can talk more about that at the PTG.
19:20:55 <tonyb[m]> smcginnis: did you jump ahead on the agenda ;P
19:21:28 <ttx> Funny how at 9:30pm I just punt everything to PTG
19:22:07 <tonyb[m]> smcginnis: I shoudl probbaly know this we do we alter (reduce) the validation checks for pike-em vs 'a new release on pike' ?
19:22:14 <tonyb[m]> ttx: I think that's fair
19:22:29 <smcginnis> tonyb[m]: I did change some of the validation checks to not run against -em tagging.
19:22:46 <smcginnis> There were a lot that don't really matter for em and eol tags.
19:24:18 <tonyb[m]> okay, so maybe be being altering what I consider functional change will reduce the amount of things we're blocked on
19:24:47 <smcginnis> It did look like that would get rid of a bunch at least.
19:25:04 <smcginnis> A lot just had the typical gitignore and u-c update patches.
19:25:39 <tonyb[m]> We're going into a 4-day weekend so I'll look at that on (my) Tuesday
19:26:41 <smcginnis> I hope to get to looking through some more later.
19:26:49 <tonyb[m]> smcginnis: Thanks
19:27:25 <tonyb[m]> just mark them as -1 'no functional change in deliverable foo' and I'll fix'em up next week
19:27:39 <dhellmann> the -em tags won't produce new pypi releases, so I agree we could just turn off a bunch of that validation
19:27:45 <tonyb[m]> or maybe during the weekend
19:28:21 <tonyb[m]> dhellmann: okay.
19:29:18 <smcginnis> We did merge https://review.openstack.org/#/c/650466/
19:29:33 <smcginnis> If there's more we should skip, easy to add the decorator now.
19:29:42 <dhellmann> that readme validation seems like another candidate
19:30:10 <dhellmann> oh, that's in there
19:30:31 <smcginnis> IIRC, there's something outside of our validation job that might also check that.
19:30:32 <dhellmann> maybe we should just not bother to tag newer releases in cases where things aren't working
19:30:42 <smcginnis> ++
19:31:26 <tonyb[m]> dhellmann: possibly, I was thinking that we'd just hit the same issues with the pike-em tag but that seems incorrect based on this discussion
19:31:27 <dhellmann> yeah, there's a job on all python repos to test that separately to avoid it breaking, but if the branch is old and already broken and going to em then *shrug*
19:31:50 <dhellmann> yeah, smcginnis' patch turns a lot of the validation off for those tags
19:31:59 <dhellmann> which is fine, since they don't build releases
19:32:05 <tonyb[m]> Yup
19:33:00 <tonyb[m]> So I think where we're at is
19:33:35 <tonyb[m]> 1) (re) review each release for functional chnages and drop the ones that don't have any
19:34:17 <tonyb[m]> 2) drop any that are failing to validate?
19:34:31 <tonyb[m]> 3) tag pike-em
19:34:52 <tonyb[m]> with typical time for PTLs to chime in
19:35:35 <dhellmann> I think so
19:35:59 <smcginnis> I like that plan.
19:36:00 <tonyb[m]> okay
19:36:03 <dhellmann> I may want to reverse my position from last week, as well, and say that we could just tag whatever the existing release is as the em
19:36:05 <diablo_rojo> Sounds solid to me
19:36:24 <dhellmann> because I didn't anticipate so many of the projects needing releases, and being broken
19:36:44 <dhellmann> and if that's the case, then it's really a sign that they went into em a long time ago and it just wasn't formally declared as such
19:37:01 <tonyb[m]> yeah possibly
19:37:35 <smcginnis> Now that we initiate more of the releases, maybe the release team should just automatically propose stable releases periodically to make sure some of these really old commits actually make it out in a release before this point.
19:38:28 <smcginnis> If we can automate sufficiently, we could say Monday's are the days were stable releases are approved, then later in the day (or tonyb[m]'s Tuesday morning) we can propose the next set of stable releases.
19:39:25 <tonyb[m]> smcginnis: I'd have to think harder on that my initial reaction was 'I don't like that' which is likely based on emotion rather than anything technical
19:39:51 <ttx> how aboyut... we discuss that at the PTG
19:40:04 <tonyb[m]> smcginnis: weekly may be too often, and yeah we'd a really good way of only generating valuable releases
19:40:28 <smcginnis> I like where ttx's mind is today. :)
19:40:34 * tonyb[m] would rename ttx to ptg-bot but that's already taken ;P
19:40:56 <tonyb[m]> but yeah it's worth discussing in person
19:41:04 <ttx> Added to agenda
19:41:09 <diablo_rojo> Lol
19:41:11 <dhellmann> we're doing something similar for libraries, aren't we?
19:41:17 <smcginnis> Weekly checks. Only if a project has something at that point, which should be much less frequent. Anyway...
19:41:21 <diablo_rojo> We are going to need more than a half a day before long
19:41:42 <ttx> dhellmann: at milestones yes
19:41:58 <dhellmann> so maybe that's often enough for stable branches, too?
19:42:18 <tonyb[m]> diablo_rojo: probably :/
19:42:35 <smcginnis> And a good point for folks to expect to look for those kinds of things.
19:43:55 <tonyb[m]> I agree we want people looking at those things more often
19:44:59 <tonyb[m]> okay
19:45:01 <tonyb[m]> PTG
19:45:10 <ttx> woohoo
19:45:21 <smcginnis> ttx's favorite topic. :D
19:45:22 <tonyb[m]> We're getting a reasonable list of things to talk about
19:45:41 <ttx> Team photo at 10am
19:45:51 <ttx> Team dinner... Thursday or Friday?
19:45:58 <diablo_rojo_phon> Thursday
19:46:01 <diablo_rojo_phon> Before games
19:46:15 <diablo_rojo_phon> Or I guess Friday after the happy hour
19:46:30 <tonyb[m]> I like Friday after happy hour
19:46:36 <ttx> ok. I posted a selection of restaurants. If we get to SuperMegaBien early we can get a table and leave early enough
19:46:41 <smcginnis> Thursday works for me, but Friday can too.
19:46:42 <ttx> but I added backup plans
19:46:55 <ttx> Games are starting... 9pm?
19:47:11 <diablo_rojo_phon> 8 I think
19:47:35 <ttx> do we have to be back there at 8?
19:48:03 <ttx> 8 makes it a bit short for some values of $food
19:48:27 <dhellmann> do we have times for the thing on friday?
19:48:45 * ttx asks
19:49:18 <dhellmann> we should publicize that so folks hang around for it
19:49:51 <ttx> hmm we thought of including it in the one-week-out PTG email
19:49:57 <ttx> do you think it's too late?
19:50:04 <tonyb[m]> Yeah I only know it's a thing because of y'all discussing it in relation to dinner
19:50:59 <ttx> Friday food'n drinks starts at 6pm
19:51:12 <dhellmann> ttx: well, this team is already making dinner plans and we have people who know about it. other teams are doing the same, but don't have the insiders.
19:51:35 <smcginnis> Sounds like Thursday would be best for us if happy hour starts at 6 on Friday.
19:51:59 <dhellmann> yeah
19:52:23 <ttx> dhellmann: fair, let me see if we can push that info ASAP
19:52:40 <cmurphy> ++
19:52:47 <tonyb[m]> funny I was thinking to opposite ;p
19:54:10 <dhellmann> tonyb[m] : we're more likely to get in at supermegabien early on a thursday than late on a friday
19:54:27 <tonyb[m]> okay
19:54:37 <ttx> dhellmann: yes ithat is why I was sticking to Thursday
19:54:38 <dhellmann> actually, more likely to get in anywhere at all
19:54:53 <dhellmann> denver's dining-out-on-a-friday scene is thriving
19:54:59 <ttx> but if we have to be back at 8 to kick off the games
19:55:17 <tonyb[m]> who's organising games?
19:55:19 <smcginnis> You can be late. :]
19:55:26 <ttx> diablo_rojo
19:55:42 <ttx> but your call
19:55:44 <tonyb[m]> diablo_rojo_phon: suggested dinner thursday before games too
19:55:47 <ttx> err
19:56:02 <tonyb[m]> so petrhaps she doesn't need to be there rigth at 8?
19:56:40 <ttx> Let's plan to hit the restaurant early
19:56:44 <ttx> and it should just work
19:57:04 <tonyb[m]> okay
19:57:10 <tonyb[m]> I'll try to book
19:57:27 <dhellmann> super mega bien doesn't take reservations
19:57:28 <ttx> + no need to book since the target place is not taking any
19:57:38 <tonyb[m]> ok
19:57:45 <tonyb[m]> that makes thing easy
19:57:47 <ttx> dhellmann: yes, that's why I added backup plans
19:57:49 <dhellmann> hence the list of fallbacks within a block or so :-)
19:57:54 <dhellmann> jinx
19:57:55 <ttx> the other options are just the next block
19:58:15 <tonyb[m]> It's like you've done this before ;P
19:58:17 <ttx> i did all that while y'all were discussing -em
19:58:19 <ttx> priorities
19:58:33 <tonyb[m]> ttx: nice!
19:58:58 <tonyb[m]> okay last thing befoer I get a coffee
19:59:54 <tonyb[m]> please look over the email's I've 'written' to make sure they're basically right
20:00:07 <smcginnis> tonyb[m]: I skimmed through and everything looked good.
20:00:21 <smcginnis> Were you planning on directly contacting each PTL/liaison?
20:00:37 <tonyb[m]> I assume I Cc all the PTLs on the 'communication expectations' email to check contact details in governance etc
20:00:54 <dhellmann> yeah, that's what we've done in the past
20:00:57 <smcginnis> I did that my first time around but dropped it. Partly because gmail wouldn't let me send to so many recipients, but also wasn't sure if it really made a difference.
20:01:29 <dhellmann> I wanted to have 1 email I could point to to say "I told you I wasn't going to be contacting you directly for every little thing. Pay attention."
20:01:46 <smcginnis> That is useful.
20:02:02 <tonyb[m]> I'll do that
20:02:18 <dhellmann> you could also point out to them that they can subscribe to the calendar so they see deadlines
20:02:41 <dhellmann> https://releases.openstack.org/schedule.ics
20:02:50 <smcginnis> Oh yeah, that is a good one.
20:02:54 <dhellmann> I'm not sure we've publicized that in a while
20:03:30 <tonyb[m]> Yeah that's in the email I was going to copy
20:03:35 <dhellmann> cool
20:03:44 <tonyb[m]> but I could also add it to the weekly comms email
20:03:57 <smcginnis> Both might not hurt.
20:04:11 <dhellmann> over communication ftw
20:04:16 <tonyb[m]> okay cool
20:04:25 <tonyb[m]> We're over time
20:04:36 * tonyb[m] blames ttx for all the ptg discussion ;P
20:04:54 <tonyb[m]> Thanks ttx for working late
20:05:00 <ttx> np
20:05:14 <tonyb[m]> Thanks everyone else
20:05:20 <dhellmann> o/
20:05:22 <ttx> I can definitely participate, but generally don't have teh energy to help leading
20:05:28 <tonyb[m]> #endmeeting