== Meeting information == * #ubuntu-meeting-2: Ubuntu Technical Board Meeting, 04 Jun at 19:04 — 19:47 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2019/ubuntu-meeting-2.2019-06-04-19.04.log.html]] == Meeting summary == === Action Review === The discussion about "Action Review" started at 19:05. === discuss how to ensure flavors are continuing to meet certification requirements === The discussion about "discuss how to ensure flavors are continuing to meet certification requirements" started at 19:13. * ''ACTION:'' vorlon to ask DMB to require flavor developer teams in LP to have a 6-month expiry policy, thus requiring developers to reaffirm their committment each release cycle * ''LINK:'' https://wiki.ubuntu.com/RecognizedFlavors * ''ACTION:'' Test action 1 * ''ACTION:'' Test action 2 * ''LINK:'' http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/68/manifest - "contact" field - ack * ''LINK:'' https://wiki.ubuntu.com/NewReleaseCycleProcess === mailing list archives === The discussion about "mailing list archives" started at 19:44. === checkin' the bugs === The discussion about "checkin' the bugs" started at 19:46. === musical chairs === The discussion about "musical chairs" started at 19:46. === AOB === The discussion about "AOB" started at 19:47. == Vote results == == Action items, by person == * vorlon * vorlon to ask DMB to require flavor developer teams in LP to have a 6-month expiry policy, thus requiring developers to reaffirm their committment each release cycle * **UNASSIGNED** * Test action 1 * Test action 2 == Done items == * (none) == People present (lines said) == * infinity (104) * vorlon (49) * mdeslaur (13) * Wimpress (7) * meetingology (6) * cyphermox (2) * Eickmeyer (1) == Full Log == 19:04 #startmeeting Ubuntu Technical Board Meeting 19:04 Meeting started Tue Jun 4 19:04:14 2019 UTC. The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 19:04 19:04 Available commands: action commands idea info link nick 19:04 if kees ever shows up again, he'll have to chair 17 times in a row 19:04 yeah but then at least mdeslaur can be backup :) 19:04 d'oh 19:04 So, iz just the three of us? 19:05 #topic Action Review 19:05 * infinity Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. 19:05 Did that ever happen? 19:05 I feel like that's becoming beyond ancient. 19:05 it has not 19:05 * Wimpress hangs head in shame. 19:06 We still mindful of this. 19:06 Wimpress: Can you take a secondary action to flog yourself for not completing the primary action? 19:06 I suspect there will be many floggings to go around, looking at this list. 19:06 Wimpress: how do we move it forward? 19:06 Will definitely sort this before 19.10 19:07 vorlon: we have new devs on the team actively working on this. 19:07 I think what we want is a mailing list post detailing HOW it will be sorted. 19:07 So we can +/- the proposed solutions. 19:07 OK. 19:07 So we don't have to yell at you again at release time. 19:07 yes please 19:08 Because release week is too late to rearchitect the whole thing. 19:08 Been working on it since April when the new devs joined. 19:08 I'll send an email 19:08 Wimpress: So, yeah, if you can read that action as "send a mail to the TB pretty soonish detailing the plans to address previous concerns", we can iterate on that. 19:08 thank you :) 19:08 Ta. 19:09 * infinity infinity to ask maas team to prepare SRU exception policy à la CurtinUpdates (see https://wiki.ubuntu.com/MAASUpdates) (awaiting response from rbasak) 19:09 I need to talk to Robie. Obviously. We should maybe move half of this action item to the SRU team meeting, so we don't forget when we're all in the same place. 19:09 vorlon: If you happen to have the SRU Agenda doc in a browser history, could you poke this in there? 19:10 infinity: ack 19:10 * infinity formal ratification of third party seeded snap security policy, depends on: 19:10 * infinity vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. 19:10 Any movement there? 19:10 no, sorry 19:11 carry forward 19:11 * infinity vorlon to reply to seeded snap upload permissions question on list 19:11 ... the original message is from... November? 19:11 I'm not seeing a follow-up, but maybe I missed it. 19:12 failed on that one too 19:12 see what happens when we don't have quorum at TB meetings, there's no one to remind me to flog myself 19:12 Alrighty, so 100% action carrying. We're doing well. 19:12 We also have a new agenda item from vorlon: 19:13 #topic discuss how to ensure flavors are continuing to meet certification requirements 19:13 I imagine this came about due to the recent Studio crisis? 19:13 "new" 19:13 yes 19:13 Well, new in that it's on the agenda and no one deleted it. 19:13 So... 19:13 If the discussion already happened, fix the wiki. :) 19:13 well I think we haven't had a quorate meeting since I added it so yes, new :) 19:14 I think it does warrant discussion 19:14 I don't disagree. Want to kick us off with your thoughts on the matter? 19:14 because as things stand, we had an official flavor that was out of compliance for more than 2 release cycles and we didn't know 19:15 and that was harmful to the flavor community, because they had no one who could make changes to the packages in the image 19:15 (to restate what everyone already knows) 19:15 hrm 19:15 So, for flavours with packagesets, we could likely have the DMB automate this in their suite of checking scripts. 19:15 there was an initial proposal from cyphermox in that regard 19:16 If we have a requirement of "2 uploaders" or some such, it's trivial to check if they meet the letter of that law. A bit harder to then verify that they're active. 19:16 But not super hard. LP keeps stats of when one has done uploads. 19:16 fwiw I'm not done with the scripts. 19:17 can't we make them expire from groups in launchpad? 19:17 Do we need a deeper level of re-certification? Are there other things we want to consider on a regular schedule? 19:17 this was my problem statement of what we need from the scripts: https://lists.ubuntu.com/archives/technical-board/2019-March/002431.html 19:17 We could do 6mo expiry, thus forcing them to re-up for every release cycle. 19:18 that seems reasonable to me 19:19 mdeslaur: thoughts? 19:19 I think that's reasonable 19:19 So, I suspect that one needs some DMB policy/procedure on it, since they manage those sorts of things by delegation. 19:20 [AGREED] ask DMB to require flavor developer teams in LP to have a 6-month expiry policy, thus requiring developers to reaffirm their committment each release cycle 19:20 infinity: ^^ probably not officially agreed unless you do it :) 19:20 We also maybe need a distinction between "team that defines flavour uploaders" and "team that gives packageset rights", since you note that they might have core-devs and motu on their team, which they wouldn't pointlessly put in their packaget permissions team. 19:21 If that's already a thing, excellent. 19:21 [AGREED] ask DMB to require flavor developer teams in LP to have a 6-month expiry policy, thus requiring developers to reaffirm their committment each release cycle 19:21 Erm. 19:21 #agreed ask DMB to require flavor developer teams in LP to have a 6-month expiry policy, thus requiring developers to reaffirm their committment each release cycle 19:21 Okay, I give up, meetbot. 19:21 :) 19:21 #confused 19:22 Any other thoughts/ideas/random on that topic? 19:22 maybe make it an action instead anyway (for me?) since somebody should formally do the asking 19:22 cyphermox: Since you're here, any input with a DMB hat on? 19:22 should we double-check quickly what the other requirements are for official flavors? 19:23 #action vorlon to ask DMB to require flavor developer teams in LP to have a 6-month expiry policy, thus requiring developers to reaffirm their committment each release cycle 19:23 * meetingology vorlon to ask DMB to require flavor developer teams in LP to have a 6-month expiry policy, thus requiring developers to reaffirm their committment each release cycle 19:23 HEY THE BOT SPOKE. 19:23 [LINK] https://wiki.ubuntu.com/RecognizedFlavors 19:23 well, sounds good; 6-mopnth cycle 19:23 vorlon: ITYM #link 19:24 one o' them bots allows both syntaces 19:24 [ACTION] Test action 1 19:24 * meetingology Test action 1 19:24 #action Test action 2 19:24 * meetingology Test action 2 19:24 Huh. 19:24 Go figure. 19:24 Anyhow, reading wiki. 19:24 Flavor lead identified and responsive though 6 month cycle. 19:24 where do we record who the flavor lead is? 19:25 The manifest on the tracker is the only place I know of. 19:25 And if there are other places, the tracker is probably canonical. 19:26 * vorlon double-checks that we are identifying individuals there consistently and not teams 19:26 http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/68/manifest - "contact" field - ack 19:27 "One or more with upload rights." 19:27 infinity: should we make it a task for the release team at the beginning of each cycle to explicitly reconfirm each of these contacts? 19:27 So, we'll accept flavours with literally only a lead and no minions? 19:27 vorlon: Probably better as a betaish task, but yeah. 19:28 vorlon: Since beta inclusion is required for final, and I don't usually expect a flavour to experience a coup in the 3 weeks before release. 19:28 heh 19:28 It might be on the beta checklist as something like "confirm manifest isn't poop" or similar high level. 19:29 But spelling it out isn't a bad idea, if it's not. 19:29 infinity: if the lead has gone awol, beta seems the wrong time to try to fix that however 19:29 which is why I thought start-of-cycle would be the point to confirm that a) everything went well last cycle, b) the contact wants to carry on for the next cycle 19:30 unless it's actually a 3-weeks-before-beta task 19:30 vorlon: Well, week before beta, or similar? I mean, making sure they still have a lead right after a release when they clearly had a lead also doesn't mean anything useful. 19:30 if they drop out half way though the development cycle, it shouldn't be too late to lose status 19:30 Some $time before beta to give them a chance to get their house in order before we say "no beta, no release, sucks to be you". 19:31 If we can determine a good time for that, the 6mo expiry cadence should probably be around then too. 19:31 Cause your devs re-upping 5 mins after a release means nothing 5.9 months later. 19:32 I still prefer regarding this as a beginning-of-cycle item, to ask flavor leads to reaffirm their committment or start explicitly thinking about their succession plan 19:32 but if you disagree, I'm ok to go with the "a bit before beta" instead 19:32 either is better than status quo 19:32 I'm not strongly disagreeing. :) 19:33 The other advantage of release opening, is we already have a checklist of doom there with a long-tail of "in the following weeks" that we babysit until done, and this would slot well in there. 19:33 It's certainly not "opening critical", but "get it sorted shortly after" means it's not lost. 19:33 I think doing both would be ideal, but let's start somewhere 19:33 * infinity nods. 19:34 infinity: will you update the checklist? 19:34 https://wiki.ubuntu.com/NewReleaseCycleProcess 19:34 Yeah, putting something in Group 4. 19:35 If the wiki will log me in. 19:35 So, this RecognizedFlavors document is ancient and from a simpler time. 19:35 I wonder if, with the size of distros and flavours today, "one active uploader" is actually enough. 19:36 And would it harm any currently approved flavours if we bumped that up. 19:36 (ie: does anyone only have one right now?) 19:36 in practice it would certainly hurt UbuntuStudio right now ;) 19:36 as we just got them back up to 1 19:36 * infinity nods. 19:36 and Erick is still training up 19:36 (Erich) 19:37 My intent would not be to screw anyone over, but food for thought for a later date, if people all get to 2+, maybe bumping that very modest requirement would be a plus. 19:37 * Eickmeyer interjects: Slowly but surely, I'm getting there. 19:37 A tiny bit of redundancy makes it harder to suddenly go to 0. 19:37 yeah, it reduces the risk of crisis 19:37 but I wouldn't like us to artifically raise our definition of crisis 19:38 I don't have any other nits about the current policy. It's lightweight and seems to generally cover what matters. 19:39 Maybe the one thing it lacks is a demotion schedule. 19:39 It says what you need to be "recognized". And then that the TB can unrecognize you if you stop doing releases. 19:39 agreed in principle 19:39 I'd suggest that if you dip below the recognition bar, the first step is "no releases". 19:40 And then a followup of "if you keep sucking, no more flavour". 19:40 Which is maybe what was meant here, but it's not spelled out. 19:40 I'm not sure where the lines are 19:40 I guess what I'm getting at is that the Studio crisis, in my mind, would not have led to "let's delete Studio" for a couple of cycles at least. 19:41 While leading to "no releases for you" makes sense until their team's in a good spot. 19:41 seems sensible 19:41 * mdeslaur nods 19:41 Some of that is to be kind to them, some of that is to be kind to those of us who actually have to do things to unsupport a flavour. :) 19:42 There's always, of course, been the fuzzy question of what we do about people who comitted to a stable support term and then effed off, but I honestly don't think we *can* answer that, so I guess we just let that one sit on the wind. 19:43 Alright, I think we've been on this topic long enough. I'm taking an immediate action to update NewReleaseCycleProcess, vorlon's got an action to follow up with the DMB on membership terms, anything else before I move on? 19:44 nothing from me 19:44 nope 19:44 #topic mailing list archives 19:44 Which, I guess, starts with "when was the last meeting?" 19:44 * infinity goes back to February. 19:46 Okay, I just see Studio crisis, and bug management. 19:46 And a couple of ruffians getting langpacky. 19:46 #topic checkin' the bugs 19:46 I see none open. 19:46 #topic musical chairs 19:47 Looketh to me like kees/mdeslaur 19:47 ack 19:47 #topic AOB 19:47 Anyone have any OB? 19:47 Going once. 19:47 Twice. 19:47 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)