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