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 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 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 <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 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 <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 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 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 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 <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 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 (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 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 (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 (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 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 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 <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 <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: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 mapreri follow up in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2012676
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 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 ddstreet schedule mtg may 17 same time
16:02 <ddstreet> ok we're done! thanks mapreri teward o/
16:02 <ddstreet> #endmeeting