14:02:21 #startmeeting airship 14:02:22 Meeting started Tue Mar 16 14:02:21 2021 UTC and is due to finish in 60 minutes. The chair is alexanderhughes. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:26 The meeting name has been set to 'airship' 14:02:30 #topic Rollcall 14:02:31 oh you beat me by a hair 14:02:44 o/ 14:02:47 haha 14:02:50 Hello everyone! Here's our agenda for today: https://etherpad.opendev.org/p/airship-team-meeting 14:02:51 o/ 14:02:55 o/ 14:03:07 Please add on any additional topics you'd like to discuss today, we have a couple so far 14:03:35 o/ 14:03:55 Hope some of you are having a less rainy day than we're having in Saint Louis :slightly_smiling_face: 14:04:51 Alright, let's get it started: 14:04:53 #topic Mark your calendars! The April 2021 Airship vPTG sessions are scheduled 14:05:07 Right on cue @alexander.hughes! 14:05:17 :) 14:05:25 Drew and Matt this one is yours! 14:05:40 The dates & times can be found in the agenda, a couple 4-hour blocks on Apr22/23 14:05:59 Hopefully those times work well for folks 14:06:16 (they're basically the same times we did last time I believe) 14:06:22 o/ 14:06:45 We have an etherpad to start adding agenda items in: https://etherpad.opendev.org/p/xena-ptg-airship 14:07:29 I encourage y'all to add in things to discuss. This will be a particularly good opportunity to dig into post-2.0/2.1 plans for Airship, and to take a step back 14:08:08 Is (free) registration open yet, does anyone know? 14:08:28 yes 14:08:30 #link https://april2021-ptg.eventbrite.com 14:08:56 perfect 14:09:01 as for the times, need to double check they're accurate in UTC since we just changed from CST to CDT 14:09:19 Great point 14:09:30 but these are the same central times that we used in October 14:10:04 I think we need to do it the other way -- dwalt can correct me if I"m wrong, but I think the UTC times are set in stone and the C?T ones need to be adjusted to match 14:10:57 Any other ideas/questions/thoughts around the PTG next month? 14:11:11 I did calculate it with CDT time in mind 14:11:18 It should be 8 AM CDT - noon 14:11:20 brilliant 14:11:21 excellent :) 14:11:36 If there's nothing else on this then, moving on to 14:11:39 #topic Periodic patchset abandoning 14:11:55 Mike and Matt, all yours 14:12:09 Next up: we talked about this, but I think it was quite some time ago 14:12:23 We have some number of old, old patchsets that haven't been updated in a long time 14:12:59 Gerrit supports the "abandon" function to archive a patchset in a way that can be easily un-archived if ever needed, but which takes the patchset "off the radar" of the team 14:13:32 normally we rely on folks to abandon their own patchsets when appropriate 14:13:36 The thought here was to implement a retention practice, or policy, to minimize tech debt, and hedge our position if we need to bring back an old(er) PS 14:13:46 +1 14:14:19 The proposal is to have some kind of periodic review, where any patchsets that haven't been updated in the last "time period X" are abandoned 14:14:34 There are other open source communities that do similar things 14:14:51 e.g. "stale issues expire after 90 days" etc 14:14:56 +1 are we thinking 90 days? 14:15:15 I think 90 days makes a good strawman? Seems reasonable at least 14:15:49 I'd propose this review process also encompass open issues, perhaps during flight plan. Run through the issues say quarterly to see what still makes sense, and then run a job to clean up any old patches. Before running the job we could add a comment/rebase any patches in question to get some attention back on them in cases where developers have been reassigned to other work or have left the project 14:15:54 if we do this - can one person produce a script that is run on a cron to do this (@mattmceuen) 14:15:54 Especially right now given the amount of change that has come through since the beginning of the year 14:16:29 +1 - yes re: 90 days.. several have leaned in to more closely monitor Github issues; in theory, if the Issues are managed via Flight Plan, PS mgmt will follow 14:16:31 other times we have done this in airship and osh in the past - without that automation its: a) fallen apart, b) been performed sporadically 14:16:34 I agree. Is there any mechanism to reach out to the submitters with information that the patchset will be abandoned in X days as a freindly reminder? 14:17:35 @pb269f @j_t_williams I think a bot-based approach would lend itself to friendly reminders and/or "FYI your PS is abandoned" emails 14:18:26 if we're scripting it I don't see why we couldn't obtain the author's email from patch on a similar schedule. we'd want to consider where we're sending these notifications from to avoid emails getting lost in outlook rules that filter gerrit activity 14:18:28 it has to be a bot if its gonna work 14:18:51 Sounds good then. 14:19:07 It has to be a bot if this is gonna work repeatably and reliably :slightly_smiling_face: in the meantime I think clicking the abandon button a couple dozen times right now will at least help folks in the short term 14:19:09 im less worried about the 'reminder email' esp if its not a human clciking abondon - its easy for people to unabandon. 14:19:18 I will create an issue where we can start collecting requirements for the bot 14:19:31 yeah, agree @pb269f 14:19:34 Action: pb269f looks forward to three pages of abandoned ps's ;) 14:19:48 hahah 14:19:57 are there any Nay's? 14:20:14 We have a number of Yea's 14:20:33 Action: mattmceuen bangs his gavel, tap tap 14:20:39 i support - if automated 14:20:48 no objection, but would like to segue into reviewing open issues periodically. some of these have been open over a year 14:21:21 yeah. we could potentially share the retention process/bot/schedule with issues while we're at it 14:21:51 our gerrit/github bot already has its fingers in github issues & gerrit PSs; we could consider enhancing that 14:22:23 right, maybe look for an abandoned by tag in gerrit - and then if no activity on issue in X days, move it to an archived status 14:22:32 Although auto-closing github issues already has other ways to do it, so probably better to use what already works 14:22:40 ++ 14:23:32 alright, moving on 14:23:36 #topic Daylight saving time 14:23:52 I move that we abolish it 14:24:03 it's that cursed time of year where we lost an hour of sleep to Daylight Saving Time. please send petitions to your elected leaders to abolish it 14:24:07 Does the OIF grant us that kind of authority? 14:24:14 lol 14:24:26 in the mean time, be advised that most of our meetings are scheduled in US central time, with the change if you do not observe DST the meetings have changed by 1 hour for you 14:24:37 I suppose folks that are here have figured this out 14:24:47 Anyone catching up on IRC logs: sorry :slightly_smiling_face: 14:25:28 That's all we have on the agenda, any other topics team? 14:25:32 I'll take an action item to review the wiki for meeting times and make sure they're all updated for UTC, and send out a note in the TC newsletter 14:25:41 ah ty alex 14:25:58 before we open it up for round table, checking if anyone has any patches that need reviews 14:26:02 #topic Call for reviews 14:27:16 none listed on the agenda, please let us know in Slack/IRC if you have any that need reviews throughout the day 14:27:19 #topic Roundtable 14:27:36 Alright - then I think we can call it a day. 14:27:43 #endmeeting