19:00:27 #startmeeting releaseteam 19:00:28 Meeting started Thu May 30 19:00:27 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:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:31 The meeting name has been set to 'releaseteam' 19:00:33 ...or maybe I've shortened it to 4min. 19:00:54 o/ 19:00:57 o/ 19:01:00 :) 19:01:03 i should look into having my reminders fire 5 minutes early 19:01:12 tonyb: You were 27 seconds late today. 19:01:21 smcginnis: true 19:01:22 being notified the second a meeting starts is probably suboptimal 19:01:32 smcginnis: I'll do better next time 19:01:37 :D 19:01:52 fungi: That's why I like ping lists. ;) 19:03:24 oh, i got pinged as soon as the #startmeeting was added 19:03:30 We're flying without an agenda today because I've been distracted 19:03:44 but my reminders fired at 19:00z on the dot too 19:04:16 Next week is m-1 week 19:05:15 We didn't have any tasks that needed to be done by m1 (well we pushed them back to m2) 19:05:36 The only open one we have is https://storyboard.openstack.org/#!/story/2005702 19:05:44 which diablo_rojo_phon started 19:06:09 Was waiting for feedback before going further 19:06:14 but between kubecon and my questions I figure we should discuss it here 19:06:31 We have release requests for cycle-with-intermediary to do for m-1. 19:07:17 #link https://review.opendev.org/#/c/660781/ 19:07:23 Process doc also says send reminder about completing responses to community-wide goals, but I don't think we have those yet? 19:07:51 smcginnis: Yeah I don't think they're decided on 19:09:21 So, lets look at diablo_rojo's 660781 quuckly, then come back to the cycle-with-intermediary realeases 19:09:45 smcginnis: Did you/can you look at the review? 19:09:57 fungi: Is there a better way to store that to be able to link to the accounts? ^ 19:10:06 I did look. It seems a little too... verbose. 19:10:31 I figured by adding the emails it would be easier to find/add them to reviews in gerrit 19:10:35 checking the change out 19:10:45 (I was pulling gerrit email addresses) 19:10:50 Not sure we need separate first and last name fields. And if we don't need a specific value to link to an account, then I'd rather see it all on one line and be able to have a list of them. 19:11:05 smcginnis: you want to be able to link to specific gerrit accounts? 19:11:13 Then maybe just name and email? 19:11:25 fungi: There was some talk about being able to automate adding folks to reviews. 19:11:42 e-mail should be all we need for that, and feed into a gerrit rest api query if you want 19:11:58 I figured the names would be nice for when we need to reach out to them directly 19:12:09 But I can make it just name and have first + last 19:12:14 instead of breaking it up 19:12:51 I just threw something together since I figured everyone would have an opinion about how it should look ;) 19:13:08 So I think something like: 19:13:11 liaisons: 19:13:18 - name: Elmer Fudd 19:13:18 Like I said on the review I like name, email and IRC as data (and have the structure match the ptl record) 19:13:25 email: elmer@fudd.com 19:13:27 i'd need to fiddle with the gerrit rest api for a moment 19:13:30 - name: Bug Bunny 19:13:36 I can add irc nics too 19:13:39 email: carrots@bb.com 19:13:56 that means we can do all the things nicely 19:14:11 https://review.opendev.org/accounts/fungi@yuggoth.org 19:14:19 that should work even anonymously 19:14:22 yeah that's what I do already 19:14:49 fungi: acctually ... https://review.opendev.org/accounts/?q=fungi@yuggoth.org 19:15:14 both work for me 19:15:25 SO the next question is do we want them all in a single liaisons file? 19:15:34 Or to be in the deliverable files like we originally said? 19:15:40 fungi's has the advantage that all we would actually need is an email address. The results of the query has everything else we need. 19:15:46 Well, I guess not IRC nick. 19:15:49 tonyb: yours just gets you the account id number, while mine gets you name and stuff 19:16:11 True 19:16:17 smcginnis: we have an osf rest api for that which can also be queried by e-mail address if that's preferred 19:16:23 diablo_rojo: Are we going to track per release cycle, or just current state? We've always done current state, which would mean separately. 19:16:30 append '&o=DEATAILS' to mine to get them 19:16:42 granted, it requires people to set up an openstack.org profile and include an irc nick in their profile 19:16:51 smcginnis, how much churn is there from cycle to cycle? 19:16:54 we use that in the openstack technical election tooling 19:16:59 If its a small to 0 number I would say current state 19:17:13 fungi: I was planning to borrow a small amount of that code ;P 19:17:23 heh 19:17:51 Small, but I would say especially if it was large we would want to do current state. 19:18:19 ...so single file? 19:18:24 Where do we want that to live? 19:18:26 I'm not sure we need to do the lookup in gerrit if it's user supplied data, we can just add that to the git-review command 19:18:40 so anyway, there are places folks could manage their names and irc nicks independently and all the release liaisons list would need is e-mail addresses 19:18:51 * tonyb likes next to series status 19:19:10 fungi: Yeah true 19:19:13 tonyb: That would seem like a logical place for it. 19:20:35 so chnage the task from 'add liasions to delivererable files' to 'add liasions to releases repo and deprecate wiki' 19:20:53 and add them all to deliverables/release_liasions.yaml ? 19:21:16 works for me 19:21:18 That sounds reasonable to me. 19:21:33 and we do or dont want nick with name and email? 19:21:46 Sounded like all we needed was email. 19:22:38 All we need yes, but do we want anything else? 19:22:55 All we need is email, can we see what it looks like with all 3? 19:23:06 in the wiki at the monment we have name and IRC 19:23:29 I can throw together a mock up for review 19:23:43 diablo_rojo: thanks 19:24:03 * tonyb dislikes data duplication but likes the consistency 19:24:29 Okay so I have my plan to move forward then :) 19:24:43 \o/ 19:26:05 So I'm on the hook to to do the c-w-i releases next week 19:26:52 process.rst is pretty clear on what's needed so I'll use that to re-test the new automation tools and then upload them again too 19:26:53 * smcginnis is afraid we are going to find a lot of broken repos due to requirements updates 19:29:15 smcginnis: You mean like sphinx or like the constraints URLs? 19:30:27 Sphinx and ones like that. 19:30:39 I've seen a lot of updates, but I'm sure there are still some lingering. 19:32:16 :( 19:33:12 I was kinda assuming that $projects would have landed those chnages if they were blocking merging any code but maybe I'm over stating/simplifying the problem 19:33:43 The active ones should all be good. There's a bunch of low volume repos that might not have noticed it yet. 19:35:25 Perhaps is they're low volume they wont need a release? 19:35:30 * tonyb hopes 19:35:46 True 19:36:11 so *if* we have a bunch that can't release ... and need one what do we do? 19:36:36 I don't want to sign us up for another pike-em style event that took too long 19:38:00 I guess not much we can do other than notify the teams that they have an issue. Worse case scenario, I think we skip them for m-1 and pick them up at m-2. 19:39:27 So get the reviews out there *early* so we can see how bad it is and inform the teams 19:39:47 Yeah, that might be a good idea. 19:40:15 if software is perpetually unreleasable, that's worth reporting to the tc 19:40:36 i don't feel like it ought to be the release team's job to fix projects so they're able to have releases 19:41:22 so i agree, let teams know their software has a problem and to submit a new release request when they resolve it 19:41:38 if they don't, pretty sure the tc members will appreciate a heads up 19:41:47 Good idea to share that info with the tc too. 19:42:06 fungi, smcginnis: we can do that 19:42:52 the release team already has plenty of responsibilities without also being babysitters 19:43:03 ++ 19:43:06 ++ 19:43:23 I would probably try to pick up some of those, but still shouldn't be expected from the release team. 19:43:49 Yeah 19:44:39 I probably will too but perhaps we shoudl add a footer to the commit message "We're doign this because we're nice ... y'all should've done this already" 19:44:43 #joking 19:46:08 Haha, yep. ;) 19:46:19 "because you couldn't be bothered to fix your stuff..." ;) 19:46:31 :) 19:47:05 okay so that's the stuff I think we have to talk about ... anything more open? 19:47:09 Do enough emoticons make it okay? 19:50:42 :) 19:50:44 Maybe? perhaps fake xml tags .... ;P 19:50:44 Nothing else from me. 19:51:12 mode='jokingnotjoking' 19:51:24 don't forget, gerrit maintenance for project renames commencing at 17:00z tomorrow 19:51:31 15:00z 19:51:35 fingers 19:51:37 Ah, right. Thanks 19:51:43 fungi: Is that just doing the renames? 19:52:12 yeah, and the gerrit restart will also (in theory) fix the "gitweb" links to go to the opendev gitea 19:52:47 fungi: It's thursday for you right? 19:53:00 * tonyb tries to translate "tomorrow" 19:53:07 tonyb: yes, but any time i say "tomorrow" i always mean "tomorrow utc" 19:53:32 so 2019-05-31 15:00 utc 19:53:53 okay I wont be near a computer then 19:54:02 tonyb, fungi operates in UTC. 19:54:10 you will hopefully be having a nice sleep in on a lazy saturday 19:54:13 That's Saturday and I have brekfast plans ;P 19:54:47 oh, or breakkie, sure 19:54:59 fungi: "sleep in" my daughter is an early riser ... so I'll be up at 6 ... maybe 7 if I'm lucky 19:55:16 okay I think we're done 19:55:17 oof, my sympathies 19:55:54 thanks tonyb! it always helps to know that it's friday somewhere even if that somewhere isn't here yet 19:56:02 tonyb, it will fade when she gets to be a teenager ;) 19:56:08 :) 19:56:10 tonyb: There were many years where we were lucky if our oldest daughter would sleep in until 6. I know how that goes. 19:56:12 #endmeeting