=== lifeless_ is now known as lifeless
[15:14] <teward> *waves*
[15:15] <ddstreet> #startmeeting Ubuntu backporters team
[15:15] <meetingology> Meeting started at 15:15:24 UTC.  The chair is ddstreet.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:15] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:15] <ddstreet> ok shortened mtg today, let's run thru previous action items
[15:15] <ddstreet> #topic previous action items
[15:16] <ddstreet> #subtopic ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
[15:16] <ddstreet> #action ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
[15:16] <meetingology> ACTION: ddstreet get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
[15:16] <ddstreet> #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] <ddstreet> #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> 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] <ddstreet> #subtopic ddstreet reply to no-bug-required backport exception ML thread to keep thread alive
[15:16] <mapreri> (ta)
[15:16] <ddstreet> i did this one! let's all try to continue the thread by the next mtg if possible
[15:17] <ddstreet> #subtopic ddstreet sponsor lp: #1998834
[15:17] -ubottu:#ubuntu-meeting- Launchpad bug 1998834 in memtest86+ (Ubuntu Jammy) "[BPO] memtest86+/6.10-4 to Jammy" [Undecided, Fix Committed] https://launchpad.net/bugs/1998834
[15:17] <ddstreet> i sponsored this and approved, thanks for the review teward
[15:17] <ddstreet> #subtopic mapreri upload (more of) all the tools (carried over, in progress)
[15:17] <mapreri> carry over
[15:17] <ddstreet> #action mapreri upload (more of) all the tools (carried over, in progress)
[15:17] <meetingology> ACTION: mapreri upload (more of) all the tools (carried over, in progress)
[15:18] <ddstreet> #subtopic mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[15:18] -ubottu:#ubuntu-meeting- Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open]
[15:18] <mapreri> carry over
[15:18] <ddstreet> #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[15:18] <meetingology> ACTION: mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[15:18] <ddstreet> #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] <ddstreet> oops
[15:18] <ddstreet> #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] <ddstreet> typo
[15:18] <mapreri> carry over as well
[15:18] <ddstreet> #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> 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] <ddstreet> #subtopic mapreri start thread on ML about how to use bug status to define meaing in process (carried over)
[15:19] <ddstreet> carry as well i assume?
[15:19] <mapreri> well, that didn't happen either, yap
[15:19] <ddstreet> #action mapreri start thread on ML about how to use bug status to define meaing in process (carried over)
[15:19] <meetingology> ACTION: mapreri start thread on ML about how to use bug status to define meaing in process (carried over)
[15:19] <ddstreet> #subtopic mapreri to look into backporting dh-python (see unit193 and yt-dlp) (carried over)
[15:19] <ddstreet> want to keep carrying this one too?
[15:19] <mapreri> mhh, I could move it into my own private list, since it's not really team related
[15:19] <mapreri> so that I don't abuse of the meeting agenda u.u
[15:20] <ddstreet> ack, works for me
[15:20] <ddstreet> #subtopic teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar)
[15:20] <teward> there's brokenness
[15:20] <teward> i pinged about it before but i'll double check
[15:20] <teward> requestbackport still includes all the interim releases in the checkmarks, etc.
[15:20] <teward> which is a problem
[15:20] <teward> backportpackage hangs but I haven't dug deeply into why yet
[15:21] <ddstreet> is it lp: #2013237 ?
[15:21] -ubottu:#ubuntu-meeting- Launchpad bug 2013237 in ubuntu-dev-tools (Ubuntu) "backportpackage incorrectly errors with 'Unknown distribution Ubuntu, can't guess target release'" [Medium, Fix Committed] https://launchpad.net/bugs/2013237
[15:21] <teward> potentially, but not confirmed, it literally just hung and never did anything so I have to run more tests
[15:21] <teward> welcome to "never enough cycles"
[15:21] <teward> :p
[15:21] <ddstreet> ack ok, lol, let's carry this one then
[15:21] <ddstreet> #action teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) (carried over)
[15:21] <meetingology> ACTION: teward make sure there are no bugs in requestbackport and backportpackage tools (in lunar) (carried over)
[15:22] <ddstreet> #subtopic (unassigned) consider documenting an SLA for reviewing uploaded backport packages
[15:22] <ddstreet> should we assign this one? or maybe move it to ML thread? or just carry it unassigned?
[15:22] <teward> i'd move it to ML
[15:22] <mapreri> I'd carry i tover
[15:22] <ddstreet> lol
[15:23] <mapreri> we already have too much unfinished ml threads
[15:23] <teward> but either way works for me
[15:23] <mapreri> let's finish some first.
[15:23] <ddstreet> ack sounds good, let's just carry then
[15:23] <ddstreet> #action (unassigned) consider documenting an SLA for reviewing uploaded backport packages
[15:23] <meetingology> ACTION: (unassigned) consider documenting an SLA for reviewing uploaded backport packages
[15:23] <ddstreet> ok that's all previous items
[15:23] <ddstreet> #topic open mailing list threads
[15:24] <ddstreet> there is the one i just replied to, to keep alive
[15:24] <ddstreet> #subtopic clarification on specific wording for no-bug-required backport exceptions
[15:24] <mapreri> ("moving to ml" would mean moving it from the "previous items" to the "open ml threads" section, so… :P)
[15:24] <ddstreet> yeah...on the agenda either way :)
[15:24] <mapreri> indeed I don't think this one needs further words in irc right now
[15:24] <ddstreet> #action clarification on specific wording for no-bug-required backport exceptions
[15:24] <meetingology> ACTION: clarification on specific wording for no-bug-required backport exceptions
[15:25] <mapreri> (…*on* irc?)
[15:25] <ddstreet> #undo
[15:25] <meetingology> Removing item from minutes: ACTION
[15:25] <ddstreet> maybe action in ML?
[15:25] <ddstreet> er, on ML?
[15:25] <mapreri> don't?
[15:25] <mapreri> if there is a link add that perhaps
[15:26] <ddstreet> it's linked in the agenda, yeah
[15:26] <ddstreet> #link https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022680.html
[15:26] <mapreri> alright, then just move on, no #action needed imho ^^
[15:26] <ddstreet> yeah
[15:26] <ddstreet> are there other threads?
[15:27] <ddstreet> I suppose i'll just mention this one
[15:27] <ddstreet> #link https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023048.html
[15:27] <ddstreet> i dont think any more action is needed, just fyi
[15:27] <mapreri> ohh
[15:27] <ddstreet> i think it was just unawareness of the new process
[15:27] <mapreri> I have been having some troubles keeping up with emails in the past few months, that one slipped past me
[15:28] <mapreri> thank you for bringing it up
[15:28] <mapreri> ddstreet: there was no answer to that mail?
[15:28] <ddstreet> no, not that i saw
[15:28] <mapreri> also, how did you notice, ooi?
[15:29] <ddstreet> 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] <ddstreet> since a back-to-back upload and approval is rare for the backports queue
[15:29] <teward> unless prediscussed by the backporters team like for memtest
[15:29] <ddstreet> right
[15:29] <ddstreet> anyway i'm sure it was just honest misunderstanding
[15:30] <mapreri> I wonder if we could get something like the accept mails go to the ML
[15:30] <mapreri> and if we could, should we..
[15:30] <teward> 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] <teward> but we reserve the right as the backporters team to redo that analysis and require them to refile for exceptions, etc.
[15:31] <ddstreet> 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] <mapreri> indeed, and such exception if it's there should be documented in the "exceptions" section of our documentation
[15:31] <mapreri> I wasn't aware src:cockpit was special in any way…
[15:31] <teward> it's shown up on the radar in the past and i remember it from that
[15:31] <teward> but i don't remember the reasoning nor do i have those emails anymore
[15:32] <ddstreet> 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] <teward> so it wouldn't hurt to have them explain why it needs such
[15:33] <mapreri> ddstreet: I'd say those + 3) check with somebody if cockpit needs some special handling…?
[15:33] <ddstreet> 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] <mapreri> 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] <mapreri> ddstreet: rather, it would be an exception where those packages/uploaders wouldn't need our review and skip the bug filing stage.
[15:34] <ddstreet> #action (unassigned) check if backports pocket uploads and/or approvals go to a ML
[15:34] <meetingology> ACTION: (unassigned) check if backports pocket uploads and/or approvals go to a ML
[15:34] <ddstreet> #action (unassigned) if no ML for backports uploads/approvals, check on how to create one
[15:34] <meetingology> ACTION: (unassigned) if no ML for backports uploads/approvals, check on how to create one
[15:34] <ddstreet> mapreri so would still need one of us to approve it, but basically a 'no-review' approval?
[15:35] <mapreri> to be defined/discussed in the exception granting process :)
[15:37] <ddstreet> 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] <ddstreet> 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] <ddstreet> maybe let's put an action for the next mtg to discuss the 'special case' for no-review-needed packages
[15:38] <mapreri> 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] <ddstreet> 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] <ddstreet> we do still have 20 min this mtg if we want to discuss now?
[15:39] <ddstreet> or we can action for next mtg
[15:39] <mapreri> I'd say next week
[15:39] <mapreri> but
[15:40] <mapreri> hold on
[15:40] <ddstreet> (this seems very similar to the 'no-bug-needed' ML thread situation too)
[15:40] <mapreri> would most/all of this fall in the already open case of no-bug-required backport exception ML thread
[15:40] <mapreri> ...
[15:40] <mapreri> :P
[15:40] <ddstreet> lol
[15:40] <ddstreet> i agree :)
[15:41] <mapreri> I have no idea about he cockpit case, so no clue
[15:41] <ddstreet> let's roll it into that ML discussion if that sounds ok to you
[15:41] <mapreri> possibly, yes.
[15:41] <ddstreet> i'll send a follow up email on that thread specifically mentioning cockpit
[15:41] <ddstreet> so we don't forget
[15:42] <mapreri> ta
[15:42] <ddstreet> #action ddstreet send follow up email on no-bug-required ML thread mentioning cockpit
[15:42] <meetingology> ACTION: ddstreet send follow up email on no-bug-required ML thread mentioning cockpit
[15:42] <ddstreet> ok any more for this ML thread, on cockpit?
[15:42] <mapreri> nothing more from me
[15:43] <ddstreet> I think there is another thread that came from the memtest86+ upload
[15:43] <ddstreet> #link https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html
[15:44] <ddstreet> 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] <ddstreet> 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] <mapreri> 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] <ddstreet> you're saying it's fine to accept the older-version upload, or to ask the backporter to provide a newer backport?
[15:47] <ddstreet> 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] <mapreri> 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] <mapreri> so
[15:48] <mapreri> 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] <ddstreet> 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] <ddstreet> i.e. something on https://wiki.ubuntu.com/UbuntuBackports/Policies instead of docs on https://wiki.ubuntu.com/UbuntuBackports
[15:49] <ddstreet> i can draft something short and send to the ML
[15:50] <ddstreet> #action ddstreet send short policy wording proposal to ML regarding https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html
[15:50] <meetingology> ACTION: ddstreet send short policy wording proposal to ML regarding https://lists.ubuntu.com/archives/ubuntu-backports/2023-March/023030.html
[15:50] <mapreri> I don't think it needs writing down, but guess that if there is doubts always better to clarify, so drafts welcome! :)
[15:51] <ddstreet> i think that's all ML threads, unless i missed something
[15:52] <ddstreet> #subtopic open bugs
[15:52] <ddstreet> #topic open bugs
[15:52] <ddstreet> #subtopic https://bugs.launchpad.net/ubuntu/jammy/+source/memtest86+/+bug/1998834
[15:52] -ubottu:#ubuntu-meeting- Launchpad bug 1998834 in memtest86+ (Ubuntu Jammy) "[BPO] memtest86+/6.10-4 to Jammy" [Undecided, Fix Committed]
[15:52] <teward> that's gonna close as soon as it goes through
[15:52] <ddstreet> this is done, i sponsored and per teward's prereview approved
[15:52] <teward> (sorry i have been quiet)
[15:52] <ddstreet> yep, thanks teward :)
[15:53] <ddstreet> #subtopic https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676
[15:53] -ubottu:#ubuntu-meeting- Launchpad bug 2012676 in nfs-utils (Ubuntu) "[BPO] nfs-utils/1:2.6.1-2ubuntu4 from kinetic" [Undecided, New]
[15:53] <ddstreet> this is newish i think
[15:53] <ddstreet> but looks like it needs a sponsor
[15:53] <mapreri> mhh
[15:53] <ddstreet> so i think nothing for us to do, yet, except maybe subscribe ubuntu-sponsors?
[15:53] <mapreri> tbh, the submitted doesn't look like somebody who would provide the update.
[15:54] <mapreri> so, possibly us asking what they want to do.
[15:54] <ddstreet> i suppose one of us should comment in the bug
[15:55] <mapreri> also, I wonder if we should be careful with nfs-utils?
[15:55] <ddstreet> yeah that as well, jumping major versions seems fairly dangerous to me
[15:56] <mapreri> is there a way for us to involve the server team or somebody…?
[15:56] <mapreri> … should we?
[15:56] <ddstreet> and the b/f versions *are* really old... lp: #1878601
[15:56] -ubottu:#ubuntu-meeting- Launchpad bug 1878601 in nfs-utils (Ubuntu) "Merge nfs-utils from Debian experimental for 22.04 - version in Ubuntu is *very* old" [Critical, Fix Released] https://launchpad.net/bugs/1878601
[15:57] <mapreri> and also they mention a bug, that really should be SRUed, if anything
[15:57] <ddstreet> ahasenack handled the updating work, i suppose we should subscribe him to the backport bug for his evaluation
[15:58] <ddstreet> that probably is their best approach, to get that specific bug fixed
[15:58] <ddstreet> if it's possible with the older pkg version
[15:58] <ddstreet> we are almost at time - mapreri do you want to follow up in the bug?
[15:58] <ddstreet> or teward?
[15:59] <ddstreet> if not i can
[15:59] <mapreri> (btw, I need to run soon)
[15:59] <teward> ddstreet: you can follow up and say this should be SRU'd not backported
[15:59] <mapreri> I can take the follow up
[15:59] <teward> or mapreri can
[15:59] <ddstreet> thnx, will action
[15:59] <teward> in either case if it needs SRU it needs SRU
[15:59] <teward> not backports
[15:59] <ddstreet> #action mapreri follow up in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676
[15:59] <meetingology> ACTION: mapreri follow up in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676
[15:59] -ubottu:#ubuntu-meeting- Launchpad bug 2012676 in nfs-utils (Ubuntu) "[BPO] nfs-utils/1:2.6.1-2ubuntu4 from kinetic" [Undecided, New]
[15:59] <ddstreet> ok no more bugs
[15:59] <ddstreet> #topic aob
[15:59] <ddstreet> anything else?
[15:59] <mapreri> none from me
[16:00] <ddstreet> #subtopic next mtg date
[16:00] <ddstreet> 4 weeks would be may 10, that work for everyone?
[16:00] <ddstreet> i'll assume yes, since we're at time
[16:01] <ddstreet> #action ddstreet schedule next mtg may 10 same time
[16:01] <meetingology> ACTION: ddstreet schedule next mtg may 10 same time
[16:01] <ddstreet> any final business before we wrap?
[16:01] <ddstreet> ok thanks mapreri teward o/
[16:01] <mapreri> mhh
[16:01] <mapreri> the 10th is actually no good for me
[16:01] <ddstreet> ah?
[16:01] <mapreri> sorry
[16:02] <mapreri> week later?
[16:02] <ddstreet> that's ok, may 3 or may 17?
[16:02] <ddstreet> sure may 17 works for me, teward?
[16:02] <mapreri> 17 better for me :)
[16:02] <teward> works for me
[16:02] <ddstreet> #undo
[16:02] <meetingology> Removing item from minutes: ACTION
[16:02] <ddstreet> #action ddstreet schedule mtg may 17 same time
[16:02] <meetingology> ACTION: ddstreet schedule mtg may 17 same time
[16:02] <ddstreet> ok we're done! thanks mapreri teward o/
[16:02] <ddstreet> #endmeeting
[16:02] <meetingology> Meeting ended at 16:02:50 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-04-12-15.15.moin.txt
[16:02] <mapreri> o/
[16:02] <ddstreet> o/
=== bdrung_ is now known as bdrung