19:00:00 #startmeeting releaseteam 19:00:01 Meeting started Thu Jun 6 19:00:00 2019 UTC and is due to finish in 60 minutes. The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:04 The meeting name has been set to 'releaseteam' 19:00:34 aloha fine release peoples 19:00:52 hey fungi 19:01:28 smcginnis, diablo_rojo, dhellmann, evrardjp: Are you around for the releaseteam meeting? 19:01:39 o/ 19:01:48 o/ 19:01:59 Kudos on the prompt start again. :D 19:02:43 o/ 19:02:57 smcginnis: thanks 19:03:31 my #startmeeting irc highlight is apparently working great ;) 19:03:37 smcginnis: gotta have goals 19:04:13 fungi: :) I might have to borrow that trick 19:04:33 it's belt-n-braces with my reminder utility 19:04:41 hey armstrong nice to you again 19:05:05 thanks 19:05:23 * tonyb winders if diablo_rojo is ever not jetlagged? 19:05:43 she doesn't actually sleep 19:05:59 fungi: ahhh that'd do it 19:06:18 #link https://etherpad.openstack.org/p/train-relmgt-tracking 19:06:28 somehwere near line 157 19:06:53 ttx: has done another great job on the agenda 19:07:37 Sleep is for the weak 19:07:49 #topic tasks 19:08:05 The only task is: Check tripleo repos have correct deliverable type. 19:08:35 I believe we've sorted that out and they should be correct for train. 19:08:45 smcginnis: Ahh cool 19:09:06 smcginquick topic then ;P 19:09:31 #topic Completion of train-1 changes 19:10:07 diablo_rojo: anything to say on the Track release liaisons in deliverable files item? 19:10:32 (noting we actually now mean release_liaisons.yaml 19:11:51 Is the current format good with everyone? 19:12:03 I feel like I've formatted things differently each patchset lol 19:12:57 Well seesin as you said that .... 19:13:21 can we have the project as the keyname the the main dict? 19:13:58 so: zun:\n- name:...\nirc: ...\n etc? 19:14:19 I think we need that to be able to have a list of liaisons per project. 19:14:34 Or else need to match them up in code, but that seems inefficient. 19:14:51 diablo_rojo: Have you worked on any code to actually consume this to get a better feel for its usage/ 19:14:57 smcginnis: Well we can have a key in each person 19:15:24 tonyb: Yeah, that's what I meant about then having to match them up in code. 19:15:30 Easier to just have the project with the list of liaisons. 19:15:58 smcginnis: +1 19:16:03 Should be really easy to script the creation of this file too. That might be a useful exercise, even if the script might be throw away. 19:16:22 I think I had the project as the top level construct in the last patchset.. 19:16:30 Although... we probably would want to keep that script if we every need to do periodic updates until we drop the wiki table. 19:16:36 But I can change it back 19:17:03 Patchset 2 did, but had other issues. 19:17:43 Okay. I'll go back to that then (sans the other issues) 19:18:29 If you script the creation, then you won't need to worry as much about the yaml syntax. 19:18:43 diablo_rojo: Thanks. I think we're close now 19:18:47 smcginnis: true 19:20:03 I'll look into it. 19:20:43 #topic Look up progress on must-do improvements 19:20:46 if you want any suggestions for yaml emitters, i've worked out how to coerce pyyaml into dumping in a format that yamllint will tolerate 19:21:21 We should have a few examples in the repo already with things like new-release. 19:21:37 (takes a bit of overriding its built-in list indentation methods) 19:21:40 fungi: thanks, we have yamlutils in repo that can do what we need ;P 19:22:01 oh, cool. it generates lintable yaml? 19:22:26 fungi: I think so? 19:22:29 though perhaps it's just as easy to tell yamllint to ignore generated files 19:23:03 * tonyb will have to look at that later #curiousnow 19:23:27 the cwi changes I did yesterday used the 2 tools I'm supposed to create 19:23:44 so I'll clean them up a little today and push them 19:24:10 Nice! 19:24:14 It's a lot more fiddly than I expected 19:24:44 I looked at interactive-release and it has a few issues that I thought made it harder to use than I'd like 19:25:05 so I just borrowed the core of it and add --interactive to new-release 19:25:16 which worked quite well 19:25:22 for a first pass 19:26:16 for ttx's task Add a tool script for producing the list of intermediary deliverables that have not released https://storyboard.openstack.org/#!/story/2005707 19:26:26 he say's no progress 19:27:07 which is ok 19:28:01 #topic Assign/drop should-do improvements 19:29:22 Anyone feel strongly about Engage with QA on communicating classification rates regularly 19:29:35 smcginnis: I think that was your idea after the last cycle? 19:29:55 I can't recall that. :) 19:30:08 as in recurrent test failure classification ni elastic-recheck? 19:30:19 IIRC it was trying to keep an eye on the 'unclassified' rate in e-r hoping to not have a bunch of gate/ci bugs late in the cycle 19:30:20 Maybe just the wording. I'm not sure what "classification rates" means. 19:30:41 Ah, not sure that was from me, but I think I recall that coming up. 19:31:19 smcginnis: okay sorry I thought it was you 19:31:32 anyone want to reach out the QA team? 19:31:42 I'm not really sure how we could go about that, at least easily. But if someone wants to write some sort of script to get some stats there that we could use as an indicator of potential problems, that might be good. 19:33:36 Yeah I feel like doing it well is a pretty big job 19:34:06 Might be something that while useful, we may not have the bandwidth to really tackle at this time. 19:34:10 we shoudl be able to get the stats out of e-r but then someone needs to try and classify the unclassified failures :/ 19:34:42 Yeah we were hoping to make it sound really usful to QA so they can run with it ;P 19:34:50 ;) 19:35:06 but it isn't like any team has surplus members these days :( 19:35:18 ok 19:35:34 Audit OUI traning material to make sure it matches the current process/tools https://storyboard.openstack.org/#!/story/2005709 19:35:36 Merged openstack/releases master: [nova] Create milestone-1 releases https://review.opendev.org/663642 19:35:37 Merged openstack/releases master: Releases for Octavia and python-octaviaclient https://review.opendev.org/663452 19:35:51 anyone? 19:36:09 It was my idea so I s'pose I'm default 19:37:29 Last I think I saw it was in Berlin. I think there was just a slide or two on our release process? 19:38:09 smcginnis: There's docs in the contributor guide which we need to check and then 3-4 questions about the release process 19:38:20 K 19:38:47 smcginnis: I wanted to make sure that the docs were right and the questions focused on the parts of the process that are a) current and b) interesting/important 19:39:02 Seems like a good thing to review then. 19:39:22 tonyb: Thanks for volunteering to do that. :P 19:39:48 okay I'll take it but it will probably happen like days before Shanghai 19:40:11 Nothing like a deadline to actually motivate. ;) 19:40:18 smcginnis: ;P 19:40:22 Update branch creation script to add new python job template on master as part of opening a new series (see https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests for details; 19:40:55 I think this was assuming we would have openstack-python-train-jobs templates defined? 19:41:07 s/train/$SERIES/g 19:41:34 I think making sure we have openstack-python-train-jobs as part of opening master for train so yeah as you say makign sure it is 19:41:51 when we do the same for U8 19:41:57 U* 19:42:23 That could save a lot of work. We would need to make sure that template is defined in time, then have a way to tell which $SERIES to drop in there. 19:42:39 I think we can assume that the template exists (or we can make sure it does as part of our process) 19:42:49 ++ 19:43:26 then IIUC what dhellmann is suggetsing is when we open master for $project we switch to the right job ... similar to the constraints or reno stuff 19:43:31 So we would have updating that job template, updating the upper-constraints URLs in tox.ini, and adding the stable reno landing page. 19:43:41 +1 19:44:13 I wonder how much variation per project we'll get 19:44:15 ? 19:44:17 Would make that boilerplate stuff a lot easier. Assuming there isn't a new python version in the template that breaks. 19:44:29 I would hope there isn't much variation. 19:44:42 [tony@thor nova]$ git grep openstack-python-train-jobs 19:44:42 [tony@thor nova]$ 19:44:43 Other than how quickly they would respond and actually merge it. 19:44:53 speaking of should-do things, i bet we're past due to for our artifact signing key transition. i'll put that on my to do list for the next week 19:44:55 D'oh 19:45:12 No wait that's right we shoudl have train jobs now 19:45:19 fungi: I thought we did that at the end of stein? Or are you saying we never actually switched over to the new one? 19:45:28 the key has existed and been attested to a fair amount, just need to swap it into production 19:45:46 fungi: Thanks 19:45:50 we have that as separate steps, one before release and the other shortly after 19:45:50 tonyb: I've seen patches out there, but since it wasn't automatic, it's been very hit or miss from folks going around and proposing it. 19:46:00 thought we had it on the release timeline but i may have imagined that 19:46:06 fungi: Ah, yep, I think it's time. 19:46:26 fungi: Should we add that to the process for between release and m1? 19:46:29 We should maybe add a reminder in our process doc between start and m-1. 19:46:58 yeah, that sounds like the right timeframe 19:47:11 smcginnis: I think I'll do some research on that to see how much work it'll be 19:47:27 we used to defer until after the cycle-trailing release deadline, but not that there's no deadline for those we agreed it could happen any time after the coordinated release date 19:47:44 That makes sense. 19:47:45 er, now that there's no deadline 19:47:46 I like the idea of automating it but getting things up to a level where we can may be a bigger effort 19:48:07 fungi: okay 19:48:24 tonyb: I suppose if we at least scope out the work effort, then we can figure out if we can make it happen by U. 19:48:34 switching it into production is as easy as making a couple changes (one to the job config, one to the release docs) 19:48:42 Speaking of... any progress on choosing a U name? 19:49:19 smcginnis: Not enough 19:49:51 :/ 19:49:53 i'm lobbying for an exception to call it "unpossible" (because apparently it nearly is) 19:49:58 smcginnis: ekcs is helping abd he's don his bit, diablo_rojo even built me a wiki page I just need to pull the 2 bits togther and then ask the TC if I can run it 19:50:03 That works for me! 19:50:19 fungi: You can suggest that once I have the wiki 19:50:27 sounds like it's been a herculean effort this time 19:50:46 thanks for coordinating that 19:50:58 fungi: not really, just more effort than T because of the location 19:51:36 harder than i because we don't have leftover names from a british colony to fall back on this go round 19:51:39 fungi: there are quite a few candidates, I don't know how good they are but ekcs found 10+ in his checking 19:51:56 Wow, that's better than I was expecting. 19:52:11 ... assuming we allow non pinyin romanisation 19:52:26 We probably need to. 19:52:33 i expect we have no alternative 19:53:02 Well this will sound terrible I don't know how easy they'll be to say/use but that's what the poll is for 19:53:38 we'll end up naming it "ulong" because of all the oolong tea we'll be drinking there 19:53:47 ++ 19:53:55 :) 19:54:02 Added bonus that it is an unsigned long. 19:54:16 yeah, geek humor ftw 19:54:21 but then everytime I see it I'll think of unsigned long int :( 19:54:50 what, you'd prefer something with less precision? 19:55:12 ushort just isn't big enough. 19:55:12 i'll be happy to float some ideas 19:55:18 Bunch of nerds ;) 19:55:21 ;P 19:55:27 fungi: That was bad. Love it. 19:55:52 my jokes are going over better today in here than in #zuul 19:56:00 i almost got hit with virtual rotten vegetables 19:56:02 fungi: more worlds colliding 19:56:30 you heard it here folks we're nicer than #zuul :D 19:56:40 :D 19:57:15 Anything else for the last 3mins? 19:57:49 Nah 19:58:06 okay 19:58:23 planning to remove the bindep fallback package list and the zuul-cloner shim from non-legacy jobs in the opendev zuul 19:58:24 going twice? 19:58:40 fungi: eeek 19:58:44 shouldn't wreak havoc for release jobs, but tentatively june 24-ish 19:59:11 fungi: cool, if you have a list of things we should check that'd be good 19:59:17 Does that mean repos that don't have bindep files may hit issues now? 19:59:19 we're doing a bit more exploratory testing before we set a firm date 19:59:52 I think tonyb is watching that clock. 19:59:55 repos that don't have bindep files but are running jobs which don't install stuff they require which were included in the fallback list may run into issues, yes 20:00:00 #endmeeting