15:00:29 <smcginnis> #startmeeting releaseteam
15:00:30 <openstack> Meeting started Fri Jun 15 15:00:29 2018 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:33 <openstack> The meeting name has been set to 'releaseteam'
15:00:36 <smcginnis> Ping list: dhellmann, dims, fungi, tonyb, lbragstad, ttx, armstrong, annabelleB
15:00:50 <smcginnis> #link https://etherpad.openstack.org/p/rocky-relmgt-tracking Agenda
15:00:58 <fungi> wow, already
15:01:05 <smcginnis> Time flies.
15:01:09 <fungi> this morning is just zipping by
15:01:13 <armstrong> Hello
15:01:18 <smcginnis> It's still 2017, right?
15:01:32 <ttx> o/
15:02:46 <smcginnis> I'll just give dhellmann a minute, then get going.
15:02:52 <dhellmann> o/
15:02:56 <smcginnis> Yay
15:03:07 <smcginnis> #topic Stein release schedule options
15:03:13 <smcginnis> #link https://www.dropbox.com/s/u93fheyvhu6bjeu/Stein.pdf?dl=0
15:03:28 <ttx> alright...
15:03:34 <smcginnis> ttx: Is it safe to say the Stein schedule definitely will change, or is this still exploratory?
15:04:11 <ttx> still exploratory, I want it in our backpocket when we conmfirm that PTG and Summit will be co-located in April
15:04:41 <smcginnis> The main goal being to realign the development cycle with the events?
15:04:54 <ttx> main goal being to keep the PTG around the start of the cycle
15:05:07 <smcginnis> In other words, if we change Stein, T would end up back at six months.
15:05:12 <ttx> yes
15:05:21 <smcginnis> OK, thanks. Just wanted to clarify that background.
15:05:31 <ttx> ± 1 month like it always has
15:06:03 <ttx> So last week you asked me to map R+4 options
15:06:19 <ttx> The main difficulty there is to place milaestone 2
15:06:26 <ttx> due to end-of-year holidays
15:06:32 <ttx> te other things line up nicely
15:06:43 <ttx> like s1 just before berlin
15:06:54 <ttx> and Chinese new year away from any milestones
15:07:09 <ttx> so, looking at the number at the rightmost column
15:07:12 <ttx> Option 1
15:07:15 <dhellmann> I was wondering if we really want milestones to fall right before an event.
15:07:21 <dhellmann> maybe the first milestone isn't bad
15:07:44 <dhellmann> people tend to take pto the week before or after the conferences
15:07:51 <ttx> It's not too bad. makes for a long t3 period
15:08:23 <ttx> Option 2 is nmore balanced but places t-2 on christmas week
15:08:45 <ttx> Option 3 is also nalanced but just after holiday break for t3 might be suboptimal
15:09:08 <smcginnis> I'd prefer m-2 to be after the new year, so 4 or below.
15:09:13 <ttx> Option 4 is unbalanced, option 5 is better
15:09:22 <ttx> Option 5 is well-balanced, although it places PTG at R+3 instead of R+4, so long cycle
15:09:35 <ttx> Option 6 and 7 are less good than option 5
15:09:39 <smcginnis> Also thinking ahead to when we contract and the U release.
15:09:45 <dhellmann> I was thinking 8, 11, 8 as a variation of option 5
15:10:09 <dhellmann> but that first milestone isn't such a big deal so, meh
15:10:29 <smcginnis> Yeah, m1 really ends up being kind of checkpoint.
15:10:33 <ttx> yeah that's doable too
15:10:42 <dhellmann> do we still have teams doing spec review deadlines then?
15:10:49 <ttx> dhellmann: to avoid the week before summit ?
15:10:54 <dhellmann> yeah
15:11:24 <ttx> makes for a long m2 period, but then it has a lot going on
15:11:27 <dhellmann> we have lots of spec deadlines for the first milestone, so maybe that extra week is better than worrying about travel before the summit
15:11:34 <ttx> Thanksgiving, Christmas, and Berlin Summit
15:11:59 <ttx> Let me update
15:12:30 * elbragstad walks in late
15:13:10 <smcginnis> elbragstad: Keystone is one of the projects that does spec freeze at milestone 1. Would a shorter m1 period for Stein be a big concern for you?
15:13:28 <ttx> reload for 5b
15:13:30 <dhellmann> I wonder if project teams would just move the review deadline, since m2 is longer
15:13:45 <ttx> That would make a 7.5-month cycle
15:13:47 <elbragstad> we do specification proposal freeze at m1
15:13:48 <fungi> keystone has a litany of different kinds of freezes on the schedule
15:13:54 <elbragstad> fungi: ++
15:14:01 <ttx> So longer, but not really longer than some winter cycles we did in the past
15:14:18 <elbragstad> the main purpose is just to encourage people to get their specs proposed sooner rather than later
15:14:30 <elbragstad> but our specification freeze is actually m2
15:14:31 <dhellmann> so it's a proposal deadline, not an approval deadline?
15:14:33 <ttx> I'm good with 5b
15:14:39 <elbragstad> dhellmann: correct
15:14:41 <dhellmann> ok
15:14:44 <smcginnis> I kind of like 5b.
15:14:53 <elbragstad> i don't think a change in m1 would effect it all that much
15:14:57 <smcginnis> The longer m1 to m2 period might actually be kind of nice.
15:14:59 <ttx> R+3 gives a bit of time to prepare, while not eating too much
15:15:27 <dhellmann> when would elections fall on this schedule?
15:15:30 <smcginnis> elbragstad: Yeah, it would still be 8 weeks, so I would think plenty of time to propose a spec.
15:15:31 <ttx> We did R+3 before too, so it's not revolutionary
15:15:33 <dhellmann> TC elections, that is
15:15:53 <ttx> hmm, I think they are still tied to summits
15:15:56 <smcginnis> Right around release time, right?
15:16:07 <ttx> We'd be back to running them at the same time as PTL
15:16:13 <ttx> like just after
15:16:29 <smcginnis> Maybe that would be good too. More awareness of election activities?
15:16:31 <ttx> but we can adjust atht
15:16:49 <dhellmann> where do we have that schedule written down? it's not in the charter
15:16:58 <ttx> We traditionally ran TC election after PTL elections so that people know if they are elected to one before they apply to the other
15:17:06 <ttx> It's in the charter
15:17:13 <dhellmann> oh, it is
15:17:15 <dhellmann> S-6
15:17:32 <dhellmann> week of march 21?
15:18:32 <dhellmann> which is also the R-3 deadline for PTL elections
15:19:32 <dhellmann> maybe that means we just run those at the same time again like we used to
15:20:03 <fungi> the election officials have gotten accustomed to more of a break between them, but can adapt again
15:20:23 <smcginnis> fungi: Things have gotten a little "easier" running those elections now too, right?
15:20:23 <ttx> Did we used to run them at the same time ?
15:20:34 <ttx> I think we used to run them in sequence
15:20:47 <dhellmann> oh, yeah, one after the other is what I meant
15:20:55 <fungi> we did just finish merging changes to the election tooling to properly separate the ptl and tc election processes, but moving them back to the same timedframe doesn't imply that we should recombine our processes for them i don't think
15:20:59 <smcginnis> Together.. but separate. :)
15:21:16 <ttx> anyway, that's not really a release schedule question, more of a consequence to place release and summit closer togther
15:21:48 <ttx> smcginnis: OK, let's keep 5b in our backpocket
15:21:49 <dhellmann> yeah, I'm just looking at other sorts of fallout
15:22:06 <dhellmann> I'm ok with either 5 or 5b with a slight preference for 5b
15:22:19 <smcginnis> Same here really.
15:22:42 <fungi> additional automation has made elections easier, but the upshot is that we end up spending the additional time engaging with the community more to track down missing candidates, drive debate, send reminders and so on
15:22:44 <ttx> Who is up to propose a release schedule for review ? We can Workflow-1 it
15:22:57 <smcginnis> I can do that.
15:23:18 <ttx> that way we have something ready for when the confirmation of co-location comes
15:23:28 <ttx> and can roll fast
15:24:14 <smcginnis> ttx: Any progress that can be shared on that co-location front?
15:24:19 <ttx> IYou prefer 5/5b to 1 ?
15:24:49 <smcginnis> I would rather see the milestone after the end of year holidays are over.
15:24:53 <smcginnis> Personally
15:25:00 <ttx> smcginnis: still discussing with venue for a one-day extension so that we can avoid the overlap
15:25:03 * elbragstad likes that m2 in 5b is long
15:25:03 <ttx> smcginnis: ++
15:25:36 <smcginnis> OK, great. I will be happy if we can not have overlap there.
15:25:40 <smcginnis> elbragstad: Me too.
15:26:14 <smcginnis> Anything more on the Stein schedule topic?
15:26:53 <smcginnis> #topic Release-tools status
15:27:15 <smcginnis> #link https://review.openstack.org/#/c/574495/ Issue with py3 and one of the tools
15:27:16 <patchbot> patch 574495 - openstack-infra/release-tools - fix tox python3 overrides
15:27:25 <ttx> right so there was this review that showed that release-tools is not passing pep8 anynore
15:27:35 <ttx> I mean, under python 3
15:27:43 <smcginnis> Looks like it would be an easy fix if we want to do that. I don't see anything actually comparing that object on first glance.
15:27:57 <ttx> It's an easy fix, but is it a needed fix
15:28:07 <ttx> Like, do we need release-tools at this point
15:28:08 <dhellmann> I don't know who uses those tool scripts any more
15:28:17 <dhellmann> nothing in the release automation uses them
15:28:19 <smcginnis> I don't think we use that particular script anywhere anymore.
15:28:27 <smcginnis> And with moving things to sb...
15:28:31 <dhellmann> but some other folks seem to use the bug management scripts
15:28:49 <ttx> Feels like we should move them to some attic
15:28:57 <ttx> rather than cargocult their maintenance
15:29:01 <smcginnis> I've borrowed snippets from some of these in the past, but that would be fine to do grabbing from the attic.
15:29:09 <dhellmann> we could attic the whole repo
15:29:10 <ttx> sure, it;s good example code
15:29:41 <smcginnis> I'm all for reducing legacy burdens.
15:30:04 <dhellmann> we probably want to announce that in case we have ptls using the scripts
15:30:49 <smcginnis> Is anything in there used by release automation anymore? Or is that all duplicated? Or at least the necessary things duplicated.
15:30:59 <dhellmann> none of the automation uses that repo any more
15:31:02 <ttx> well, we are about to find out
15:31:09 <dhellmann> the scripts we use are all in project-config
15:31:25 <dhellmann> or in openstack/releases itself
15:31:36 <ttx> should all be
15:32:03 <ttx> basically if we keep on using one of them, we should move it
15:32:11 <ttx> the rest can be atticced
15:32:14 <fungi> where did the lp integration move to? i was starting on the task to add equivalent sb notification and was looking in the release-tools repo but i guess i should have been starting with job configuration?
15:32:17 <dhellmann> right, I did that a few cycles back
15:32:24 <smcginnis> That's what I thought. Would be good to attic it then to at least avoid confusion.
15:32:34 <fungi> ahh, project-config. thanks
15:32:42 <ttx> smcginnis: hence me raising that topic for the meeting
15:32:44 <dhellmann> fungi : yeah, that's in a role in project-config
15:32:46 <fungi> s/attic/retire/
15:32:46 <dhellmann> fungi : roles/copy-release-tools-scripts/files/
15:32:58 <ttx> any volunteer in atticcing ? I don't have experience doing that
15:33:05 <smcginnis> Me neither.
15:33:06 <fungi> thanks dhellmann!
15:33:32 <dhellmann> there are instructions for retiring a repo somewhere
15:33:43 <smcginnis> fungi: Maybe an infra question then. How does one get to the attic? :)
15:33:48 <fungi> #link https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project Retiring a Project
15:34:03 <fungi> i can do the retirement steps if required
15:34:13 <smcginnis> But we don't want to retire it, just move it, right?
15:34:14 <dhellmann> https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
15:34:17 <dhellmann> oh, thanks fungi
15:34:19 <fungi> er
15:34:28 <fungi> we _don't_ want to retire it?
15:34:28 <smcginnis> I suppose either way works.
15:34:33 <fungi> what good is renaming it?
15:34:43 <dhellmann> yeah, I thought retiring took the place of the attic
15:34:54 <smcginnis> OK, that's good then.
15:35:07 <fungi> the retirement process replaced the older less-obvious process we had been sort of pressured into with regards to renaming defunct projects
15:35:16 <smcginnis> Easy enough to still get to it by looking at HEAD~1 of needed anyway.
15:35:24 <fungi> right, that was the thought
15:35:40 <fungi> the typical retirement readme will mention that option
15:35:46 <smcginnis> OK, then you were volunteering for that fungi?
15:35:52 <fungi> yup, action me
15:35:59 <smcginnis> fungi: OK, thanks!
15:36:07 <fungi> i figure since it tripped me up too, i might as well save others that pain
15:36:24 <ttx> reordering so that we end with the open-ended topic
15:36:42 <smcginnis> fungi: Do you mind sending something to the ML to let PTLs know too?
15:36:52 <fungi> i can do that, sure
15:37:01 <fungi> it's technically a step outlined in that process anyway
15:37:24 <fungi> well, it calls itself a "prerequirement" ;)
15:37:33 <smcginnis> ++
15:37:40 <fungi> which i don't think is a word
15:37:49 <smcginnis> :)
15:37:55 <fungi> probably should more correctly be "prerequisite"
15:38:04 <smcginnis> rerequirement
15:38:21 <smcginnis> Next topic?
15:38:28 <ttx> yes
15:38:29 <smcginnis> #link Adding a "release highlights" chapter
15:38:33 <ttx> Right, so I was reading the release management chapter in the project team guide, and updated it to correspond to current policy. One thing that was missing from it though is a chapter on release highlights. We cover release notes but not highlights.
15:38:37 <smcginnis> #link https://docs.openstack.org/project-team-guide/release-management.html
15:39:08 <smcginnis> I can add that since I did the other part. Unless someone else wants to volunteer?
15:39:36 <smcginnis> I guess not. :)
15:39:38 <ttx> I defer to you as you know it better, Unless annabelleB wants it
15:39:47 <ttx> but she is DockerConing
15:39:48 <smcginnis> Oh, delegation! :)
15:39:50 <dhellmann> yeah, I wonder if we want to ask Anne to do it
15:40:05 <smcginnis> That might actually be better written from her perspective on it too.
15:40:07 <ttx> smcginnis: maybe check with her first
15:40:14 <dhellmann> collaboration!
15:40:18 <fungi> she seems to have a vested interest in promoting the highlights process anyway, yeah
15:40:28 <smcginnis> Yeah, maybe the two of us can tackle it together. I will follow up with her.
15:41:10 * ttx is better at dodging assignments this week. Lesson hard learnt
15:41:14 <smcginnis> ;)
15:41:19 <smcginnis> #topic Stable library discussion continuation
15:41:27 <ttx> OK so I started that thread
15:41:34 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131341.html ML thread
15:42:15 <ttx> There was one plea for model 1
15:42:28 <ttx> Otherwise support toward option 2
15:42:57 <ttx> One question was raised by zaneb though
15:43:04 <dhellmann> I don't remember the request for option 1. What was the justification there?
15:43:07 <ttx> Good questions like always
15:43:30 <ttx> dhellmann: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131422.html
15:43:39 <smcginnis> I was glad to see Thomas's input as far as downstream distro needs.
15:43:42 <dhellmann> oh, right
15:43:53 <ttx> Zane's question was "does the release tooling check that the gate still passes at the time of release, even if it has been months since the last patch merged?"
15:43:56 <dhellmann> yeah, I think Michael was only thinking of services there
15:44:34 <smcginnis> No, it doesn't recheck.
15:44:39 <ttx> would the bitrot jobs help ?
15:45:04 <smcginnis> But would it be any different than releasing just after something did pass gate checks and then something unrelated breaks post-release?
15:45:12 <dhellmann> do we want to do that? or just look at the date of the last commit being tagged?
15:45:16 <zaneb> yeah, maybe the release should look at the last periodic job or something
15:45:30 <dhellmann> we could easily warn if it has been more than a week or two since the commit being tagged was merged
15:45:41 <zaneb> I think that only applies to services though. and it isn't a new problem
15:46:22 <ttx> So the issue here would be the case where a patch lands a couple of days after the branch is created, then nothing until release at the end of the cycle
15:46:29 <fungi> for that matter, how does having jobs no longer pass between the last commit and the date it's tagged differ from having jobs break on the tagged code a day or a week after the tag is pushed?
15:46:31 <ttx> could still happen with current policy
15:46:33 <zaneb> so no reason to hold up any work over that, but it might be something to think about
15:46:52 <ttx> I don't think that's against model2 really
15:47:11 <ttx> More of a "talking about low activity, what if"
15:47:27 <dhellmann> at least with model 2 we have an early indicator, because every time we create a branch we get a patch to update the .gitreview
15:47:44 <ttx> dhellmann: that is a good point
15:48:01 <smcginnis> Oh, very good point.
15:48:01 <ttx> I grew up a strong preference for 2 over 2bis
15:48:07 <dhellmann> and we don't tag those as releases, so if we do have something to release on the branch ideally it would be newer than that
15:48:10 <smcginnis> I'm in the 2 camp now as well.
15:48:25 <ttx> like just the fact that the branch is around for people to work on, without having to ask us... is a great thing
15:48:42 <ttx> If done in one go, not much added churn
15:48:43 <dhellmann> yeah, I'm in the "2 or switch to independent" camp
15:49:00 <dhellmann> so we need to update our process to add those branches, and update the tool that opens a new release cycle to not skip over deliverables that were not released
15:49:36 <dhellmann> and we probably want some sort of indicator on the deliverable that we don't expect much activity, so maybe that's a new release model
15:49:58 <dhellmann> that way we don't pester teams about libraries that are stable
15:49:59 <ttx> OK I propose we try out 2. We'll likely see it coming
15:50:34 <ttx> dhellmann: do we really need to change the process ? We already craete branches
15:50:51 <fungi> and as noted before, need some solution to keep us from painting ourselves into a corner with no suitable versions available for a branch
15:51:02 <dhellmann> we need to do something explicitly with these because there's no existing release in the deliverable file to branch from
15:51:16 <ttx> oh I see
15:51:21 <dhellmann> fungi : yeah, we should update the release validation to count stable branches backwards until it finds a release
15:51:54 <fungi> at a minimum there should be an available minor release number available unique to each branch
15:51:54 <dhellmann> we already go 1 back in new-release and in the validation code, but we need to make that more general
15:51:58 <fungi> even if not used
15:52:02 <dhellmann> exactly
15:53:25 <smcginnis> dhellmann: Not to sign you up, but this sounds like something you are best suited to tackle?
15:53:43 <dhellmann> I can at least describe the problem
15:53:58 <dhellmann> I would really like to get to the point where I'm not the only one familiar with this code, though :-)
15:55:03 <smcginnis> Yeah, definitely. I've dipped my toes, but can do more.
15:56:09 <dhellmann> I think I captured all of that
15:56:31 <smcginnis> With minutes to spare.
15:56:37 <smcginnis> Anything else for today?
15:57:14 <ttx> who is taking up the actions on the stable stuff
15:57:36 <dhellmann> I'll sign up to help but not drive it
15:58:13 <smcginnis> I've already signed up for two things today, but will probably get to it when I can. Unless some other volunteer steps forward before I do.
15:58:17 <ttx> ok I can take it
15:58:24 <smcginnis> \o/
15:58:25 <ttx> I think
15:58:33 * dhellmann plans a trip to france to pair program with ttx
15:58:43 <smcginnis> Oooh, can we do a release team offsite?
15:58:57 <ttx> might take some time for me to get to it, but it's not super-urgent
15:59:07 <dhellmann> there's no rush on this, maybe we could spend some time on it together at the ptg
15:59:18 <smcginnis> ++
15:59:20 <dhellmann> although denver is not as nice as france
15:59:44 <smcginnis> If it's a 6 day event, we can probably find some time to all get together and crank out some stuff.
15:59:57 <smcginnis> OK, that's time for today. Thanks everyone.
16:00:00 <dhellmann> oh, the next one is only 5 days, right?
16:00:13 <smcginnis> Oh right, I keep forgetting we get one mroe.
16:00:15 <smcginnis> *more
16:00:23 <smcginnis> #endmeeting