== Meeting information == * #ubuntu-meeting: Ubuntu backporters team meeting, started by ddstreet, 12 Apr at 15:15 — 16:02 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-04-12-15.15.log.html == Meeting summary == === previous action items === Discussion started by ddstreet at 15:15. * '''ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)''' (ddstreet, 15:16) * ''ACTION:'' ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) (ddstreet, 15:16) * '''ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over)''' (ddstreet, 15:16) * ''ACTION:'' ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) (ddstreet, 15:16) * '''ddstreet reply to no-bug-required backport exception ML thread to keep thread alive''' (ddstreet, 15:16) * '''ddstreet sponsor lp: #1998834''' (ddstreet, 15:17) * '''mapreri upload (more of) all the tools (carried over, in progress)''' (ddstreet, 15:17) * ''ACTION:'' mapreri upload (more of) all the tools (carried over, in progress) (ddstreet, 15:17) * '''mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)''' (ddstreet, 15:18) * ''ACTION:'' mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) (ddstreet, 15:18) * '''mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over)''' (ddstreet, 15:18) * ''ACTION:'' mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) (ddstreet, 15:18) * '''mapreri start thread on ML about how to use bug status to define meaing in process (carried over)''' (ddstreet, 15:18) * ''ACTION:'' mapreri start thread on ML about how to use bug status to define meaing in process (carried over) (ddstreet, 15:19) * '''mapreri to look into backporting dh-python (see unit193 and yt-dlp) (carried over)''' (ddstreet, 15:19) * '''teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar)''' (ddstreet, 15:20) * ''ACTION:'' teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) (carried over) (ddstreet, 15:21) * '''(unassigned) consider documenting an SLA for reviewing uploaded backport packages''' (ddstreet, 15:22) * ''ACTION:'' (unassigned) consider documenting an SLA for reviewing uploaded backport packages (ddstreet, 15:23) === open mailing list threads === Discussion started by ddstreet at 15:23. * '''clarification on specific wording for no-bug-required backport exceptions''' (ddstreet, 15:24) * ''LINK:'' https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022680.html (ddstreet, 15:26) * ''LINK:'' https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023048.html (ddstreet, 15:27) * ''ACTION:'' (unassigned) check if backports pocket uploads and/or approvals go to a ML (ddstreet, 15:34) * ''ACTION:'' (unassigned) if no ML for backports uploads/approvals, check on how to create one (ddstreet, 15:34) * ''ACTION:'' ddstreet send follow up email on no-bug-required ML thread mentioning cockpit (ddstreet, 15:42) * ''LINK:'' https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html (ddstreet, 15:43) * ''LINK:'' https://wiki.ubuntu.com/UbuntuBackports#Future_Maintenance_of_the_Backport mentions that "The backporter is responsible for […] additional updates that should be backported" - which indeed is not quite clear on what those "additioanl updates" are, but to me it means that any further update done on the base suite should also be backported? (mapreri, 15:47) * ''ACTION:'' ddstreet send short policy wording proposal to ML regarding https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html (ddstreet, 15:50) * '''open bugs''' (ddstreet, 15:52) === open bugs === Discussion started by ddstreet at 15:52. * '''https://bugs.launchpad.net/ubuntu/jammy/+source/memtest86+/+bug/1998834''' (ddstreet, 15:52) * '''https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676''' (ddstreet, 15:53) * ''ACTION:'' mapreri follow up in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676 (ddstreet, 15:59) === aob === Discussion started by ddstreet at 15:59. * '''next mtg date''' (ddstreet, 16:00) * ''ACTION:'' ddstreet schedule mtg may 17 same time (ddstreet, 16:02) == Action items, by person == * ddstreet * ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) * ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) * ddstreet send follow up email on no-bug-required ML thread mentioning cockpit * ddstreet send short policy wording proposal to ML regarding https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html * ddstreet schedule mtg may 17 same time * mapreri * mapreri upload (more of) all the tools (carried over, in progress) * mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) * mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) * mapreri start thread on ML about how to use bug status to define meaing in process (carried over) * mapreri follow up in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676 * teward * teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) (carried over) * **UNASSIGNED** * (unassigned) consider documenting an SLA for reviewing uploaded backport packages * (unassigned) check if backports pocket uploads and/or approvals go to a ML * (unassigned) if no ML for backports uploads/approvals, check on how to create one == People present (lines said) == * ddstreet (124) * mapreri (60) * teward (23) * meetingology (20) == Full log == 15:15 #startmeeting Ubuntu backporters team 15:15 Meeting started at 15:15:24 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology 15:15 Available commands: action, commands, idea, info, link, nick 15:15 ok shortened mtg today, let's run thru previous action items 15:15 #topic previous action items 15:16 #subtopic ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) 15:16 #action ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) 15:16 * meetingology ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) 15:16 #subtopic ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) 15:16 #action ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) 15:16 * meetingology ddstreet look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over) 15:16 #subtopic ddstreet reply to no-bug-required backport exception ML thread to keep thread alive 15:16 (ta) 15:16 i did this one! let's all try to continue the thread by the next mtg if possible 15:17 #subtopic ddstreet sponsor lp: #1998834 15:17 i sponsored this and approved, thanks for the review teward 15:17 #subtopic mapreri upload (more of) all the tools (carried over, in progress) 15:17 carry over 15:17 #action mapreri upload (more of) all the tools (carried over, in progress) 15:17 * meetingology mapreri upload (more of) all the tools (carried over, in progress) 15:18 #subtopic mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) 15:18 carry over 15:18 #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) 15:18 * meetingology mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) 15:18 #subtopci mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) 15:18 oops 15:18 #subtopic mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) 15:18 typo 15:18 carry over as well 15:18 #action mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) 15:18 * meetingology mapreri review wiki page to see how we can highlight that backport requestors need to do the backport work and find a sponsor (carried over) 15:18 #subtopic mapreri start thread on ML about how to use bug status to define meaing in process (carried over) 15:19 carry as well i assume? 15:19 well, that didn't happen either, yap 15:19 #action mapreri start thread on ML about how to use bug status to define meaing in process (carried over) 15:19 * meetingology mapreri start thread on ML about how to use bug status to define meaing in process (carried over) 15:19 #subtopic mapreri to look into backporting dh-python (see unit193 and yt-dlp) (carried over) 15:19 want to keep carrying this one too? 15:19 mhh, I could move it into my own private list, since it's not really team related 15:19 so that I don't abuse of the meeting agenda u.u 15:20 ack, works for me 15:20 #subtopic teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) 15:20 there's brokenness 15:20 i pinged about it before but i'll double check 15:20 requestbackport still includes all the interim releases in the checkmarks, etc. 15:20 which is a problem 15:20 backportpackage hangs but I haven't dug deeply into why yet 15:21 is it lp: #2013237 ? 15:21 potentially, but not confirmed, it literally just hung and never did anything so I have to run more tests 15:21 welcome to "never enough cycles" 15:21 :p 15:21 ack ok, lol, let's carry this one then 15:21 #action teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) (carried over) 15:21 * meetingology teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) (carried over) 15:22 #subtopic (unassigned) consider documenting an SLA for reviewing uploaded backport packages 15:22 should we assign this one? or maybe move it to ML thread? or just carry it unassigned? 15:22 i'd move it to ML 15:22 I'd carry i tover 15:22 lol 15:23 we already have too much unfinished ml threads 15:23 but either way works for me 15:23 let's finish some first. 15:23 ack sounds good, let's just carry then 15:23 #action (unassigned) consider documenting an SLA for reviewing uploaded backport packages 15:23 * meetingology (unassigned) consider documenting an SLA for reviewing uploaded backport packages 15:23 ok that's all previous items 15:23 #topic open mailing list threads 15:24 there is the one i just replied to, to keep alive 15:24 #subtopic clarification on specific wording for no-bug-required backport exceptions 15:24 ("moving to ml" would mean moving it from the "previous items" to the "open ml threads" section, so… :P) 15:24 yeah...on the agenda either way :) 15:24 indeed I don't think this one needs further words in irc right now 15:24 #action clarification on specific wording for no-bug-required backport exceptions 15:24 * meetingology clarification on specific wording for no-bug-required backport exceptions 15:25 (…*on* irc?) 15:25 #undo 15:25 Removing item from minutes: ACTION 15:25 maybe action in ML? 15:25 er, on ML? 15:25 don't? 15:25 if there is a link add that perhaps 15:26 it's linked in the agenda, yeah 15:26 #link https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022680.html 15:26 alright, then just move on, no #action needed imho ^^ 15:26 yeah 15:26 are there other threads? 15:27 I suppose i'll just mention this one 15:27 #link https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023048.html 15:27 i dont think any more action is needed, just fyi 15:27 ohh 15:27 i think it was just unawareness of the new process 15:27 I have been having some troubles keeping up with emails in the past few months, that one slipped past me 15:28 thank you for bringing it up 15:28 ddstreet: there was no answer to that mail? 15:28 no, not that i saw 15:28 also, how did you notice, ooi? 15:29 i highlight in irc on 'backports' so i saw in ubuntu-release the upload and approval (back-to-back) and wondered who was doing it 15:29 since a back-to-back upload and approval is rare for the backports queue 15:29 unless prediscussed by the backporters team like for memtest 15:29 right 15:29 anyway i'm sure it was just honest misunderstanding 15:30 I wonder if we could get something like the accept mails go to the ML 15:30 and if we could, should we.. 15:30 maybe. i know that cockpit was a special case in the previous backporters team before we were in charge and it had a special approval for always being backported because of whatever it was needed for being chaotic. 15:30 but we reserve the right as the backporters team to redo that analysis and require them to refile for exceptions, etc. 15:31 i think there is a ML for uploads/approvals for updates pocket, isn't there? not sure if that includes backports pocket too 15:31 indeed, and such exception if it's there should be documented in the "exceptions" section of our documentation 15:31 I wasn't aware src:cockpit was special in any way… 15:31 it's shown up on the radar in the past and i remember it from that 15:31 but i don't remember the reasoning nor do i have those emails anymore 15:32 should we add an action for someone to look into 1) do uploads and/or approvals go to ML? 2) if not, do we want a ML for it? 15:32 so it wouldn't hurt to have them explain why it needs such 15:33 ddstreet: I'd say those + 3) check with somebody if cockpit needs some special handling…? 15:33 i suspect the 'exceptions' where people can self-approve would be rarely useful, as the uploader would also need archive approval rights, which severely limits the number of uploaders who can self-approve 15:33 not that I'm volounteering for any of them, but I'd write them down so that in the future somebody will u.u 15:33 ddstreet: rather, it would be an exception where those packages/uploaders wouldn't need our review and skip the bug filing stage. 15:34 #action (unassigned) check if backports pocket uploads and/or approvals go to a ML 15:34 * meetingology (unassigned) check if backports pocket uploads and/or approvals go to a ML 15:34 #action (unassigned) if no ML for backports uploads/approvals, check on how to create one 15:34 * meetingology (unassigned) if no ML for backports uploads/approvals, check on how to create one 15:34 mapreri so would still need one of us to approve it, but basically a 'no-review' approval? 15:35 to be defined/discussed in the exception granting process :) 15:37 so should we action specifically for cockpit, and/or should we action on adding generic wiki doc in the 'special cases' section for 'preapproved packages' (or similar wording)? 15:37 the 'special case' generic i think probably should be discussed a bit more, maybe on ML though we don't seem to get thru much there recently :) 15:38 maybe let's put an action for the next mtg to discuss the 'special case' for no-review-needed packages 15:38 I was thinking for cockpit. the discussion would be about "should cockpit be added to the "special cases" section? If so, with what terms? 15:39 we could consider cockpit first, though i suspect other pkgs would fall into a very similar category, e.g. gallery-dl comes to mind 15:39 we do still have 20 min this mtg if we want to discuss now? 15:39 or we can action for next mtg 15:39 I'd say next week 15:39 but 15:40 hold on 15:40 (this seems very similar to the 'no-bug-needed' ML thread situation too) 15:40 would most/all of this fall in the already open case of no-bug-required backport exception ML thread 15:40 ... 15:40 :P 15:40 lol 15:40 i agree :) 15:41 I have no idea about he cockpit case, so no clue 15:41 let's roll it into that ML discussion if that sounds ok to you 15:41 possibly, yes. 15:41 i'll send a follow up email on that thread specifically mentioning cockpit 15:41 so we don't forget 15:42 ta 15:42 #action ddstreet send follow up email on no-bug-required ML thread mentioning cockpit 15:42 * meetingology ddstreet send follow up email on no-bug-required ML thread mentioning cockpit 15:42 ok any more for this ML thread, on cockpit? 15:42 nothing more from me 15:43 I think there is another thread that came from the memtest86+ upload 15:43 #link https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html 15:44 basically, it took long enough for me to sponsor that there was a new upload in lunar, which required asking the backporter to provide a new backport version 15:44 generally, i think it's best to ask them for the latest version, but my concern is if it gets into long delays because the sponsorship (or review/approval) takes so long that the backport and/or upload becomes out of date 15:45 I'd say that's fine, but still, part of the responsibilities of the backporters is to keep the bpo up2date, so a new one will come "soon enough" anyway. 15:46 you're saying it's fine to accept the older-version upload, or to ask the backporter to provide a newer backport? 15:47 i also think it will (hopefully) be rare, so maybe we should wait until/if it is a problem to make any decision 15:47 https://wiki.ubuntu.com/UbuntuBackports#Future_Maintenance_of_the_Backport mentions that "The backporter is responsible for […] additional updates that should be backported" - which indeed is not quite clear on what those "additioanl updates" are, but to me it means that any further update done on the base suite should also be backported? 15:48 so 15:48 if just the process takes too long, accepting an older version is ok for me, with the assumption that a newer one will be forthcoming. 15:49 i'm in agreement. maybe instead of a end-user policy for this, we should just add a team-internal policy roughly stating this? 15:49 i.e. something on https://wiki.ubuntu.com/UbuntuBackports/Policies instead of docs on https://wiki.ubuntu.com/UbuntuBackports 15:49 i can draft something short and send to the ML 15:50 #action ddstreet send short policy wording proposal to ML regarding https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html 15:50 * meetingology ddstreet send short policy wording proposal to ML regarding https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html 15:50 I don't think it needs writing down, but guess that if there is doubts always better to clarify, so drafts welcome! :) 15:51 i think that's all ML threads, unless i missed something 15:52 #subtopic open bugs 15:52 #topic open bugs 15:52 #subtopic https://bugs.launchpad.net/ubuntu/jammy/+source/memtest86+/+bug/1998834 15:52 that's gonna close as soon as it goes through 15:52 this is done, i sponsored and per teward's prereview approved 15:52 (sorry i have been quiet) 15:52 yep, thanks teward :) 15:53 #subtopic https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676 15:53 this is newish i think 15:53 but looks like it needs a sponsor 15:53 mhh 15:53 so i think nothing for us to do, yet, except maybe subscribe ubuntu-sponsors? 15:53 tbh, the submitted doesn't look like somebody who would provide the update. 15:54 so, possibly us asking what they want to do. 15:54 i suppose one of us should comment in the bug 15:55 also, I wonder if we should be careful with nfs-utils? 15:55 yeah that as well, jumping major versions seems fairly dangerous to me 15:56 is there a way for us to involve the server team or somebody…? 15:56 … should we? 15:56 and the b/f versions *are* really old... lp: #1878601 15:57 and also they mention a bug, that really should be SRUed, if anything 15:57 ahasenack handled the updating work, i suppose we should subscribe him to the backport bug for his evaluation 15:58 that probably is their best approach, to get that specific bug fixed 15:58 if it's possible with the older pkg version 15:58 we are almost at time - mapreri do you want to follow up in the bug? 15:58 or teward? 15:59 if not i can 15:59 (btw, I need to run soon) 15:59 ddstreet: you can follow up and say this should be SRU'd not backported 15:59 I can take the follow up 15:59 or mapreri can 15:59 thnx, will action 15:59 in either case if it needs SRU it needs SRU 15:59 not backports 15:59 #action mapreri follow up in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676 15:59 * meetingology mapreri follow up in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676 15:59 ok no more bugs 15:59 #topic aob 15:59 anything else? 15:59 none from me 16:00 #subtopic next mtg date 16:00 4 weeks would be may 10, that work for everyone? 16:00 i'll assume yes, since we're at time 16:01 #action ddstreet schedule next mtg may 10 same time 16:01 * meetingology ddstreet schedule next mtg may 10 same time 16:01 any final business before we wrap? 16:01 ok thanks mapreri teward o/ 16:01 mhh 16:01 the 10th is actually no good for me 16:01 ah? 16:01 sorry 16:02 week later? 16:02 that's ok, may 3 or may 17? 16:02 sure may 17 works for me, teward? 16:02 17 better for me :) 16:02 works for me 16:02 #undo 16:02 Removing item from minutes: ACTION 16:02 #action ddstreet schedule mtg may 17 same time 16:02 * meetingology ddstreet schedule mtg may 17 same time 16:02 ok we're done! thanks mapreri teward o/ 16:02 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)