== Meeting information == * #ubuntu-meeting: Ubuntu Technical Board meeting, started by amurray, 24 Jan at 20:00 — 20:59 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-01-24-20.00.log.html == Meeting summary == === Apologies === Discussion started by amurray at 20:01. === Action review === Discussion started by amurray at 20:02. * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2022-March/002620.html (rbasak, 20:08) * ''ACTION:'' amurray to propose amended Ubuntu Backporters Team Charter (amurray, 20:27) * ''ACTION:'' seb128 to help draft an exception to the "must build on all architectures" requirement for snaps (seb128, 20:29) * ''ACTION:'' seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage (seb128, 20:34) * ''ACTION:'' rbasak to raise any on-going blockers with third-party seeded snap security policy (amurray, 20:37) * ''ACTION:'' sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step (amurray, 20:37) * ''ACTION:'' rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification (amurray, 20:38) * ''ACTION:'' rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies (amurray, 20:51) * ''ACTION:'' vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed. (amurray, 20:52) * ''ACTION:'' sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon. (amurray, 20:53) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by amurray at 20:54. === Check up on community bugs (standing item) === Discussion started by amurray at 20:57. === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by amurray at 20:57. === AOB === Discussion started by amurray at 20:57. == Action items, by person == * amurray * amurray to propose amended Ubuntu Backporters Team Charter * seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage * rbasak * rbasak to raise any on-going blockers with third-party seeded snap security policy * rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification * rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies * seb128 * seb128 to help draft an exception to the "must build on all architectures" requirement for snaps * seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage * vorlon * vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed. * **UNASSIGNED** * sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step * sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon. == People present (lines said) == * rbasak (78) * amurray (64) * seb128 (27) * meetingology (13) * vorlon (12) * Eickmeyer (1) == Full log == 20:00 #startmeeting Ubuntu Technical Board 20:00 Meeting started at 20:00:57 UTC. The chair is amurray. Information about MeetBot at https://wiki.ubuntu.com/meetingology 20:00 Available commands: action, commands, idea, info, link, nick 20:01 hey 20:01 #topic Apologies 20:02 sil2100 emailed earlier to say he couldn't make it, but everyone else is here :) 20:02 #topic Action review 20:02 * amurray (everyone) review the Ubuntu Backports Team Charter for ratification 20:03 I sent an email about that on the list since I'm a bit confused by what we need to review exactly? 20:03 Maybe I can try to explain my perspective now 20:03 please 20:04 It's been brought up in a few different places that it would be helpful to have better documentation about exactly what is delegated by TB to other teams. 20:04 The DMB, release and archive teams' "undocumented delegations" have been been brought up in the past couple of years for separate reasons. 20:05 When we resurrected the backporters team, I thought it'd be helpful to have a similar text, and I suggested that in the original resurrection thread on ubuntu-devel@ 20:05 Well, the text. Not specifically that it should be formalised at I thought that premature at the time. 20:05 In time, I suggested this to the backporters team, and it turned out that they were working on some similar text. 20:06 But their (specifically ddstreet's) idea of what that should be differed from mine. 20:07 They wanted to have text to define what I consider to be their "internal" operations. IMHO, the details of how they do things should be up to them, and the TB should leave teams to "get on with it" with minimal interference. Therefore, that stuff does not need to be and should not be ratified by the TB. 20:07 So the backporters team made that page empty, and moved their internal operations documentation elsewhere. 20:07 But, I still think it would be useful to have some text that defines the team's responsibilities to the rest of the project. I think my original text is still appropriate for that. 20:08 ddstreet disagreed in a TB thread. I'll find the link shortly. 20:08 So that's the current status. 20:08 so where is your original text? and is that we need to review or does someone (who?) need to turn that into a proper document first? 20:08 #link https://lists.ubuntu.com/archives/technical-board/2022-March/002620.html 20:08 Is it a requirement for the backporters team to have a charter at all for them to function? 20:09 Here's the original text: https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html 20:09 Here's where I proposed that text to the backporters team: https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html 20:10 amurray: I got the impression that they preferred to have one, but I think what they wanted was IMHO more an internal thing and not a TB matter. I believe they're proceeding with their own internal documentation instead. 20:11 fwiw I think that your proposed text looks quite reasonable - I recall there was some objection to things like "making sure that all requests receive an appropriate answer in a reasonable amount of time" - but I can't really understand why 20:11 The reason I want it is because I think it's a useful thing to have for all teams, and it's been an issue on a few different occasions that there isn't some text to refer to. 20:12 I'd like for us to make progress in that direction, and because the backporters team resurrection was quite recent, I had that in mind and wrote it at the time, and in the original thread everyone seemed to agree with the text as I'd written it. 20:13 rbasak: to allow this to try and make some headway, how would you feel if we proposed to them your text from above but without the few bits that they objected to ("reasonable amount of time" etc)? 20:15 Sure. I'm not sure how to do that without removing the text entirely. I'm disappointed that they seemed unable to make any kind of counterproposal or propose any edits to my text. But if we can make progress that way, then sure. I'm not precious about my precise text. But... 20:15 ...most of what I wrote there were specifically about what failed with the backporters team previously which led to the need for it to be resurrected. 20:15 Like reviews were piling up and not being done in a reasonable amount of time - hence that bit of my text. 20:16 one issue is that a such statement isn't really helping in resolving the issue if that's due to lack of manpower 20:17 And some people who happened to have suitable privilege were then bypassing the previous backports review process, which I think is really bad procedurally because I don't want to see any part of the archive becoming de-facto exclusive like that. 20:17 you can't really force a volunteers' based team to commit to be able to be responsive 20:18 seb128: sure. but if they don't have the manpower and that means they can't meet their responsibilties, then the matter *should* be escalated to the TB to decide what needs to be done about it, and so it's entirely appropriate to identify that they aren't meeting their responsiblities. So it's right to have that in the text. 20:19 But yes, as volunteers, we can't hold them to it, and I am definitely not seeking to blame individuals should such a case arise again. 20:20 To take another example, let's say that community-contributed SRUs stopped getting processed entirely. 20:20 In favour of Canonical-priority SRUs only, with the SRU team currently happening to be entirely Canonical-staffed. 20:20 That would be a matter for the TB to intervene in, IMHO. 20:21 So it would be right for the TB to say that the SRU team has that responsibility. 20:21 rbasak: sure but even if does get escalated to the TB, I am not sure there is a lot we can do about it - we are unlikely to be able to find more volunteers to get more resources for the team 20:21 Even though the SRU team is currently staffed entirely by Canonical-employee "volunteers" as far as the Ubuntu project is concerned. 20:21 right, explained like that it makes sense to me 20:22 amurray: sure. Then it'd go back to my original thread, where I proposed to acknowledge that and officially sunset the backports pocket. 20:22 but do we need that written down for the TB to be able to exercice that right anyway? 20:22 With hindsight, I think it would have helped. 20:22 I think that's a project level expectation that the TB take action to fix any of the non working teams 20:22 In the case of the backports pocket, there were multiple previous posts to ubuntu-devel@ and it dragged on for years. 20:23 well it would have been in the power of anyone to bring the topic to the TB 20:23 Had the text been there presently, I think there would have been far less friction in a TB escalation and intervention much earlier. 20:24 right, it could help to make people more entitled to raise up the issue to the TB 20:24 For example, we had people volunteering to do backports review, but the backporters team admins were absent. 20:24 not that the lack of such statement would personally stop me, but I see how it might be different for others 20:24 I think it would have been easier for those volunteers to say "look, based on this text the team weren't meeting their responsibilities, and I'm volunteering, so..." 20:25 right 20:25 I hope that explains my reasoning. 20:25 thanks for the explanation, and I think that seen from that angle it makes sense 20:25 Anyway, I'd appreciate any help in breaking the current impasse. 20:25 But I think it needs other TB members to get involved in that thread. 20:26 yep I agree with all your points rbasak but I think we need to find some way forward here - I'll see if I can draft something which is a little less "SLA"-like and send it to the backporters team 20:26 I think it would help if you posted the proposal again so we have a logical/recent base to reply to 20:26 amurray: please! I'd appreciate that. 20:26 amurray, +1 from me 20:27 #action amurray to propose amended Ubuntu Backporters Team Charter 20:27 * meetingology amurray to propose amended Ubuntu Backporters Team Charter 20:27 Thanks! 20:27 * amurray rbasak to finalize third-party seeded snap security policy 20:27 I continue to work on this. 20:27 A couple of requests. 20:28 seb128: could you please help draft an exception to the "must build on all architectures" requirement for snaps in the case of non- desktop support for specific architectures? I think you might best understand what that should look like. 20:28 rbasak, yes 20:29 Thanks! 20:29 #action seb128 to help draft an exception to the "must build on all architectures" requirement for snaps 20:29 * meetingology seb128 to help draft an exception to the "must build on all architectures" requirement for snaps 20:30 thanks 20:30 And second, I'd like some help with writing a description of how snaps work wrt. the store and the Ubuntu-specific tracks, which I'm not sure I fully understand. In this section: https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit#bookmark=id.tbw4pletjt3g 20:30 I could help with that as well, unless amurray wants to do it :) 20:31 Thanks. What I mean for example is that for example on 22.04 firefox tracks latest/stable/ubuntu-22.04, and I think that's the mechanism that implements some of the requirements, and we should document how that occurs. 20:31 Meanwhile I'll continue cleaning up the rest of the feedback. I just got stuck on those two so far. 20:31 I can try help but having not used branches much before I may not be as knowledgable - but I can certainly try and propose something if needed 20:33 sil2100 might also be able to help with this one, but he's not here right now. 20:34 #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 20:34 * meetingology seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 20:34 hehe thanks seb (I wasn't sure on who to assign that to) 20:34 :) 20:34 I will try to own it but will welcome input from you and Lukasz 20:34 thank you 20:35 rbasak: do we still need a general action in the minutes around the policy as a whole? 20:35 or do you want to wait until these two new actions make some headway? 20:36 amurray: I think maybe we should have a general topic for us to discuss any blockers, and just those specific actions for now? We can clean all the others up. 20:37 #action rbasak to raise any on-going blockers with third-party seeded snap security policy 20:37 * meetingology rbasak to raise any on-going blockers with third-party seeded snap security policy 20:37 +1 thanks 20:37 * amurray sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step 20:37 sil2100 is out so lets carry this over 20:37 #action sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step 20:37 * meetingology sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step 20:37 * amurray rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 20:38 Still pending - carry over please. 20:38 #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 20:38 * meetingology rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 20:38 (I expect to carry for a while, until the third party repo requirements block on me less) 20:38 * amurray amurray to figure out next steps to improve TB processes previously discussed - and to figure out what the previous discussion was about 20:39 ok so looking back over the history, this was raised by Fallen from the community team - wanting a way for the community to be able to follow long with the longer term work of the TB 20:39 it was suggested to use a separate LP project with bugs to track each of the work items 20:40 I notice there is already a techboard project on LP, and this has only ever had a single bug reported against it - so I wonder if we could just reuse that - and as far as a process for this... 20:40 Right. IIRC we were all happy with that, but it needed some effort from someone to set up all the details. 20:40 Yeah, and that was mentioned too. 20:40 My suggestion would be to have a bug for each longer term item in the agenda - how we decide what meets this "longer term" criteria is uncertain though - but this would give a way for anyone to see what is happening more easily and to subscribe to bugs for the project etc to get notified of new items 20:41 Oh I didn't know about the techboard project actually 20:41 We also have https://bugs.launchpad.net/ubuntu-community/+bugs with the idea that bugs could be assigned to ~techboard. But it turns out not everyone can do that. 20:42 in previous TB meeting I believe we agreed to move to a project to solve the problem of assigning bugs under ubuntu-community 20:42 but the execution was lacking 20:42 I guess we could re-use the techboard project then, rather than create a new one/ 20:43 ? 20:43 sure, one less hurdle 20:43 that would be nice 20:43 It looks like we own it, so no ACL issues 20:44 regarding the question of which items qualify for LP bug tracking, how about we said something like 'if an item is carried over more than twice then a LP bug should be created in the techboard LP project to track this work'? 20:44 +1 20:45 Sure 20:45 Sounds like third party repo requirements needs tracking 20:46 As well as my DMB inactivity expiration policy item 20:46 +1 20:47 +1 20:47 one final detail - should we stipulate that the meeting chair creates these bugs or the owner of the action item? 20:47 (perhaps it doesn't matter but I think making the process clear is useful) 20:48 I personally prefer saying the meeting chair should, since they will already be updating the agenda wiki page 20:48 I would prefer the item owner, that's probably the person understand best the details 20:48 sorry :p 20:48 +who 20:48 I have no strong opinion. 20:49 seb128's response makes sense to me 20:49 If you wanted, you could make it a separate action item - then the task could be assigned easily at the time. 20:49 hehe no worries - I don't feel strongly either way either really I just prefer to have something written down, otherwise its too easier to have things fall through the cracks 20:49 rbasak: do you mean a standing action item in the agenda? 20:50 No, I mean add an action like "amurray to create the bug" 20:50 But seb128's answer also works, if everyone's happy with that. 20:50 And would be less admin. 20:50 yeah lets go with that 20:50 (ie seb128's proposal) 20:51 #action rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies 20:51 * meetingology rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies 20:51 ack 20:51 thanks 20:52 * amurray vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed. 20:52 carry-over, sorry. I'll try to get that done this week 20:52 #action vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed. 20:52 * meetingology vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed. 20:52 * Eickmeyer is biting at the bit 20:52 * amurray sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon. 20:52 carry-over 20:53 #action sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon. 20:53 * meetingology sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon. 20:53 * amurray vorlon to request change of the meeting weeks for the TB meeting starting February 20:53 I recall we discussed this last time? 20:53 I think this was just pushed so that I wouldn't break the calendar confusingly before today's meeting 20:53 so I'll push the next meeting out a week on the calendar 20:53 +1 20:53 thanks 20:54 #action vorlon to push the next meeting out a week in the calendar 20:54 * meetingology vorlon to push the next meeting out a week in the calendar 20:54 (done) 20:54 oh thanks 20:54 #undo 20:54 Removing item from minutes: ACTION 20:54 #topic Scan the mailing list archive for anything we missed (standing item) 20:54 this is why we need to get fresh blood on the TB from time to time, I had no idea there was an #undo command :P 20:55 :) 20:55 What, you mean you don't read the instructions you get given every time you chair? :-P 20:55 the main thing here that I saw was the xubuntu minimal image announcement from vorlon - so other than now being aware of this, does the TB have to officially ack this? I thought it was more an informational thing 20:56 I think we agreed it's just an informational thing. 20:56 I believe the agreement was that this was informational 20:56 Unless an individual TB member has any objection. 20:56 nice - sounds like there is no objection :) 20:56 (or someone else escalates one I suppose) 20:56 :) 20:57 #topic Check up on community bugs (standing item) 20:57 nothing new here 20:57 This standing item might need to change with the new bug system 20:57 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 20:57 But that can wait I guess 20:57 rbasak: tag you're it :) 20:57 ack 20:57 #topic AOB 20:59 last call? 20:59 nothing here 20:59 nothing from me 20:59 no worries 20:59 Nothing from me. 20:59 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)