15:00:12 <dhellmann> #startmeeting releaseteam
15:00:13 <openstack> Meeting started Fri Jan 13 15:00:12 2017 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:17 <openstack> The meeting name has been set to 'releaseteam'
15:00:36 <ttx> o/
15:00:45 <dhellmann> courtesy ping: ttx, dims, fungi, stevemar, sigmavirus, tonyb
15:00:54 <sigmavirus> Thank you dhellmann
15:00:55 <sigmavirus> o/
15:01:03 <dhellmann> #info this is week R-6
15:01:11 <dhellmann> #link agenda https://etherpad.openstack.org/p/ocata-relmgt-tracking
15:01:14 <dims> dhellmann : bit side-tracked, but am here
15:01:20 <dhellmann> dims : ack
15:01:34 <dhellmann> #topic Added HIGH TODO to Ocata plan for coming up with Pike schedule
15:01:52 <ttx> yeah, so I added that as a thing we need to complete this cycle
15:01:52 <dhellmann> ttx: did you want folks to review that list?
15:02:03 <ttx> Well, currently we are still missing info
15:02:15 <ttx> but I hope to know more about PTG2 date by next week
15:02:17 * stevemar lurks
15:02:23 <dhellmann> k
15:02:31 <ttx> so it's mostly a placeholder to remind myself that needs to be done
15:02:31 <dhellmann> oh, I misread that, I thought it was related to the next item
15:03:08 <ttx> not really related but as we prune the ocata plan we'll likely keep that one in (hence the HIGH)
15:03:15 <dhellmann> sounds good
15:03:30 <dhellmann> #topic Review Ocata plan
15:03:40 <dhellmann> #link https://etherpad.openstack.org/p/pike-relmgt-plan
15:03:44 <ttx> Right so I created ^
15:03:58 <ttx> I moved things that are obvious defers to it
15:03:59 <dhellmann> #link https://etherpad.openstack.org/p/ocata-relmgt-plan
15:04:13 <ttx> we should review ^ and see what we can move and what should stay
15:04:25 <ttx> basically what we still plan to accomplish over the coming month
15:04:34 <dhellmann> #action everyone review remaining ocata items and plan deferrals
15:04:41 <ttx> Personally I would keep it to the strict minimum
15:04:57 <ttx> Please add POSTPONE TO PIKE or such and I'll move them
15:05:08 <dhellmann> sounds good
15:05:19 <ttx> We don't necessarily need to do it in-meeting
15:05:37 <ttx> Maybe add "HIGH" to the TODOs that should be completed before end of cycle
15:05:38 <dhellmann> no, let's do that on our own time
15:05:55 <ttx> that should give us a base of things for Pike and then we can add to it
15:06:08 <dhellmann> yep
15:06:09 <ttx> which in turn gives us a list of things to discuss at pTG
15:06:40 <dhellmann> ++
15:06:41 <dhellmann> I expect most of the remaining reno work can be deferred easily
15:07:06 <dhellmann> ready to move on?
15:07:12 <ttx> yes
15:07:18 <dhellmann> #topic neutron-vpnaas release question
15:07:22 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-infra/2017-January/005041.html
15:07:37 <dhellmann> I gather this is an issue because the project is no longer part of an official team?
15:07:44 <ttx> just wanted to make sure it wouldn't fall through cracks. Since them realized it got cross-posted to dev so probably difficult to miss
15:07:53 <ttx> Since then*
15:08:21 <ttx> dhellmann: it's more than the timing is short for them to learn how dto do it
15:08:33 <dhellmann> right, I was going to offer to tag for them outside of the releases repo
15:08:51 <ttx> yeah, given it's a bit of corner case I think we could help
15:08:59 <dhellmann> and encourage them to work with the release team to learn how to do it for pike
15:09:06 <dhellmann> ok, I'll reply to the -dev ML thread
15:09:26 <dhellmann> #action dhellmann offer to help vpnaas team with their release work
15:09:37 <dhellmann> #topic open discussion
15:09:51 <ttx> Not much PTL candidates to take over
15:10:08 <dhellmann> yeah, I need to send that email announcement to make it formal
15:10:31 <dims> many many thanks for this term as PTL dhellmann !
15:10:34 <ttx> we've been alone in this meeting for the few last times, too
15:10:46 <fungi> alone how?
15:10:50 <ttx> tonyb has a full plate, dims has been locked in a container
15:10:58 <ttx> fungi has a full plate too
15:10:58 <dims> haha
15:10:59 <fungi> heh, locked in a container
15:11:11 <dims> python3 container? :)
15:11:29 <fungi> #link https://sks-keyservers.net/pks/lookup?op=vindex&search=0xc96bfb160752606daa0de2fa05eb5792c876df9a&fingerprint=on Pike Cycle artifact signing key
15:11:34 <dhellmann> yes, we should work on recruiting some more participants next cycle; I didn't prioritize that this time around.
15:11:48 <ttx> I'm fine running next cycle, but yes wouldn't mind finding new blood to take over
15:11:50 <dims> Big +1 dhellmann
15:11:50 <fungi> that's available now, i'll give the infra-root admins a heads up to start attesting next week
15:11:54 <dhellmann> fungi : nice
15:12:31 <fungi> i noticed one tricky issue with generating it this soon... since we haven't decided on a pike release date yet, i had to add a lot more fudge factor to the expiration, so set it for one year from today just to be safe
15:12:38 <ttx> dhellmann: arguably the work you've done over the last cycles make on-boarding a lot easier
15:13:12 <dhellmann> fungi : yeah, we're getting down to the wire here with schedule planning
15:13:18 <dhellmann> ttx: I hope so.
15:13:26 <ttx> fungi: "alone" = the same overworked usual suspects
15:13:34 <fungi> ahh, right. that ;)
15:13:36 <ttx> no new faces
15:13:38 <dhellmann> ttx: we should also consider whether it makes sense to "encourage" teams to move from -with-milestones to -with-intermediary
15:13:45 <fungi> we're all alone together in our busy
15:14:01 <dhellmann> fungi : I would wear that t-shirt.
15:14:24 <ttx> dhellmann: ideally the pipeline to release management would be through -stable-maint
15:14:42 <dhellmann> ttx: how active is that team this cycle? I haven't been keeping an eye on it.
15:14:46 <ttx> but that pipeline is not getting stronger
15:15:04 <ttx> all I know is Tony is the only one doing stable release reviews :)
15:15:08 <ttx> (lately)
15:15:36 <dhellmann> my thoughts on the cycle model is if we move more to intermediary, we have fewer periods where we have a lot of coordination to do, and the liaisons can do  more of the work throughout the cycle
15:15:48 <ttx> Not the best cycle/time for recruitment anyway
15:15:49 <fungi> there are a few teams with some overlap: stable-maint, requirements, vmt (not really an official team), infra... but i agree stable-maint is the closest process-wise
15:15:50 <dhellmann> oh, sheesh, that's untenable
15:16:14 <ttx> dhellmann: yes, I added it as a pike topic
15:16:19 <ttx> "Stable releases: Stable team review bottleneck / bus factor"
15:17:16 <fungi> granted, stable branch management was all but a ghost town after mriedem ended up busy with new stuff, and then he stepped up to stop the bleeding
15:17:28 <dims> definitely need actively recruit for stable and releases like we did for requirements
15:17:43 <fungi> and was a ghost town before mriedem offered to try to keep it from falling completely apart, for that matter
15:17:47 <mriedem> ghosts on friday the 13th?!
15:17:59 <ttx> appropriate
15:18:06 <dhellmann> we either need to recruit, or figure out how to distribute that work across the project teams
15:18:21 <dims> right dhellmann
15:18:29 <dhellmann> probably some of each
15:18:34 <mriedem> fwiw lyarwood has stepped up on the nova side, but i think that's because red hat got serious about putting a person on it
15:18:35 <ttx> We could also tap more azctively in the release liaison pipeline
15:18:45 <dhellmann> ttx: ++
15:18:48 <ttx> So I think the right path is:
15:18:57 <ttx> PTL delegates release liaison work
15:19:07 <fungi> the old tack of getting distro package maintainers to collaborate on stable branch maintenance was a definite bust. they're positioned as consumers of those branches (sometimes) but really most of the people relying on stable branches are not inclined to maintain them
15:19:08 <ttx> release liaison gets involved more in release mgt / stable maint
15:19:23 <ttx> then we close the trap and proposes they become PTL.
15:19:41 <dhellmann> ttx: now the secret plan is out of the bag!
15:19:44 <ttx> so step 0 would be to encourage PTLs to delegate release liaisoning more
15:19:52 <ttx> is this channel logged ? Oh wait
15:20:00 <ttx> We should have done a Hangout
15:20:02 <dhellmann> heh
15:20:27 <fungi> i thought glitter was teh new hangouts
15:20:49 * ttx looks up new hot
15:20:57 <dhellmann> ttx: maybe you can start a ML thread before the PTG to encourage liaisons to come hang out with us for a while on one of the meeting days?
15:21:04 <ttx> "Glitter describes an assortment of small, flat, reflective particles"
15:21:17 <ttx> dhellmann: +1
15:21:33 <sigmavirus> lol ttx
15:21:38 <sigmavirus> dhellmann: I would if I were going to the PTG
15:21:38 <ttx> release liaisons should definitely hang out with us. Especially as our room will also feature stable and requirements
15:21:39 <fungi> oh, i guess it's "gitter" not "glitter"?
15:21:48 <sigmavirus> fungi: oh no, not gitter.im
15:21:50 <sigmavirus> please no
15:21:54 <dhellmann> sigmavirus : aw, you won't be there? :-/
15:22:05 <ttx> fungi: not on first page of search, means not hot
15:22:06 <sigmavirus> Never have I ever had a good experience on Gitter
15:22:28 <sigmavirus> dhellmann: Rackspace is refusing to solidfy travel plans and I have too many other things going on to be able to drop stuff at the last minute for the PTG
15:22:29 <mriedem> so i came in late but is the issue lack of stable branch release request review?
15:22:30 <ttx> Oh, gitter, THAT thing
15:22:41 <sigmavirus> And I have to pay for a wedding this year, so paying to send myself won't exactly work
15:22:55 <ttx> mriedem: not really an ISSUE, but we scaled most of the rest of the process
15:22:58 <fungi> mriedem: or at least lack of review of those by more than just tonyb
15:23:00 <dhellmann> sigmavirus : there's the travel support program, but I totally understand
15:23:00 <sigmavirus> Also don't want to rely on FinAid given my social status
15:23:28 <sigmavirus> dhellmann: I'll be there in spirit :)
15:23:38 <dhellmann> mriedem : we're also considering the general case that ttx, dims, fungi, tonyb, and I don't necessarily want to keep doing this work indefinitely.
15:23:40 <mriedem> ttx: fungi: ok, i guess as nova ptl and stable guy i propose my own stable nova release requests
15:23:44 <fungi> travel support is still open for applications through the 17th, yes
15:23:48 <sigmavirus> Presuming I'm still allocated to OpenStack work come Pike, I suspect rosmaita will want me to continue as Glance CPL
15:24:16 <mriedem> i figured the stable teams in other projects were coordinating their own releases on stable and reviewing those requests
15:24:40 <sigmavirus> mriedem: Glance isn't mostly because I seem to be the last of the active stable maint cores
15:24:42 * ttx need to run to another  overlapping meeting
15:24:44 <sigmavirus> And also release CPL
15:25:00 <dhellmann> mriedem : ideally someone from the stable team approves stable releases, but right now that's only tonyb
15:25:02 <sigmavirus> (And our newton gate is a bit borked)
15:25:06 <dhellmann> ttx: thanks, have a good weekend
15:25:26 <ttx> I'll multiplex
15:25:50 <ttx> Gitter: "where communities of less than 25 people thrive"
15:26:28 <mriedem> dhellmann: yeah ideally i agree. i can review stable release requests from other teams too, but i don't actively hunt for them, i need a ping,
15:26:31 <mriedem> because of other priorities
15:26:34 <fungi> (and people who don't mind developing free software while relying on proprietary communication platforms to do so)
15:26:39 <ttx> ok that was unfair, the limitation is on private rooms only
15:27:01 <mriedem> but i don't want to make the release team ping me for this all the time either
15:27:49 <dhellmann> mriedem : I count you in the "already doing enough" group :-)
15:27:50 <mriedem> ironically, the stability of the stable branch CI due to upper-constraints has probably killed the stable maint team as a unit :)
15:27:51 <fungi> i think the idea is that the stable branch team needs at least a handful of people distributing the release request load
15:28:27 <dhellmann> fungi : maybe we can use the liaisons and have them review each other's requests, as mriedem suggested
15:28:42 <mriedem> fungi: maybe that's something the stable maint team could agree to rotate on a weekly basis or something
15:28:46 <fungi> yep, i agree that seems like a good way to crowdsource it
15:28:57 <fungi> or a rotation could work too, sure
15:29:06 <dhellmann> mriedem : that's a good idea, too, that's how the release team works (daily, but similar)
15:29:13 <mriedem> having said that,
15:29:19 <mriedem> i can't remember the last time i was in a stable team meeting
15:30:06 <mriedem> on a side note,
15:30:16 <mriedem> we were asked to ask a questoin for the user survey,
15:30:23 <mriedem> i assume tonyb was asked to ask one for stable,
15:30:42 <mriedem> but if i were asked, i'd ask the user survey how many people are actually getting patches from upstream stable branches anymore
15:30:59 <mriedem> i think red hat does their own thing, i don't know about suse
15:31:18 <fungi> mriedem: 2016-10-10 was the last time you show up in a stable meeting log ;)
15:31:21 <mriedem> anyway, it's a question that always comes up
15:31:24 <fungi> at least with your normal nick
15:31:31 <dhellmann> iiuc, red hat does rely on the upstream branches but we carry patches that haven't landed yet
15:31:36 <mriedem> fungi: well, i'd show up on days that we didn't have one too :)
15:31:42 <mriedem> sigmavirus can vouch for me
15:31:45 <fungi> indeed
15:32:04 <sigmavirus> mriedem: I do too :)
15:33:27 <dhellmann> it seems like we've covered everything, so I propose we close the meeting and let folks have the ~25 minutes back
15:33:42 <fungi> wfm
15:33:52 <dhellmann> thanks, everyone!
15:33:55 <dhellmann> #endmeeting