[15:59] <teward> ddstreet: you know you had a video call added to the meeting right?
[15:59] <ddstreet> o/
[15:59] <ddstreet> ha, i didn't mean to add that
[15:59] <ddstreet> let's stick to irc
[15:59] <teward> yup
[16:00] <teward> for the record though i'm playing catchup after an injury due to the landlords' negligence so i haven't been paying as much attention to emails - anything new other than the previous items to discuss that needs my review?
[16:00] <teward> (injury == bad)
[16:01] <ddstreet> ouch, sorry to hear that! hope you're ok
[16:01] <teward> dislocated shoulder and the resulting discussions with lawyers have taken a ton of my time.
[16:01] <ddstreet> wow, ouch
[16:01] <teward> yup
[16:02] <ddstreet> i don't think there's anything that would require immediate attention, i did want to go over some details during the mtg but it's all stuff that i can summarize after the meeting, or you can review later, if you want to rest
[16:03] <mapreri> hi!
[16:03] <teward> nah i'm good
[16:03] <mapreri> teward: sorry to hear you had some RL troubles :(
[16:03] <teward> my arm is in a sling, so as long as you summarize anything I have missed briefly that'll work
[16:03] <teward> mapreri: yeah tell me about it
[16:03] <teward> the upcoming legal complaint is likely to be **expensive**
[16:04] <mapreri> I don't think there is anything requiring immediate action, though it seems nobody of us 3 actually did anything bpo-related in the 2 weeks.  with both me and ddstreet recalling our actions just this afternoon :D
[16:04] <ddstreet> yep exactly :)
[16:04] <ddstreet> i think it should be a fairly short mtg, with most of the stuff just carried over :)
[16:04] <ddstreet> are we ready to go ahead and start?
[16:05] <ddstreet> #startmeeting Ubuntu Backporters Team
[16:05] <meetingology> Meeting started at 16:05:20 UTC.  The chair is ddstreet.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[16:05] <mapreri> sure
[16:05] <meetingology> Available commands: action, commands, idea, info, link, nick
[16:05] <ddstreet> let's first go over the previous action items, i think some are done and others we'll continue to carry over
[16:05] <ddstreet> #topic Action Items
[16:06] <ddstreet> ddstreet reply to previous ML requests and open backport request bugs indicating change in process
[16:06] <ddstreet> i didn't, but i think you did this one mapreri ?
[16:06] <ddstreet> well, the ML at least
[16:07] <mapreri> no, I replied to one that came by last week
[16:07] <mapreri> not to the old ones
[16:07] <ddstreet> ok let's carry this over
[16:07] <ddstreet> #action ddstreet reply to previous ML requests and open backport request bugs indicating change in process (carried over)
[16:07] <meetingology> ACTION: ddstreet reply to previous ML requests and open backport request bugs indicating change in process (carried over)
[16:07] <ddstreet> ddstreet update wiki docs with new process
[16:07] <ddstreet> i *did* do this, at least with a draft
[16:07] <mapreri> (though imho that really should be done after we get this ↑ one first)
[16:07] <ddstreet> #link https://wiki.ubuntu.com/UbuntuBackports
[16:08] <mapreri> that page is still unchanged since 2012 herE?
[16:08] <ddstreet> yes i agree, we should have a template to respond to the old ML and bugs after we're done with the new process
[16:08] <ddstreet> really?
[16:08] <mapreri> yes
[16:08] <mapreri> did you forget to save or something? :O
[16:08] <ddstreet> i guess try reloading? it shows newer for me
[16:09] <ddstreet> oh werid...
[16:09] <mapreri> yup, also in incognito it's unchanged
[16:09] <ddstreet> none of my changes show up in the 'info' list...
[16:09] <mapreri> (I'm also subscribed to the pages, so it's hard to miss…)
[16:10] <ddstreet> do you see this at the top: NOTE: This process is undergoing change, the content below may be updated
[16:10] <mapreri> yes
[16:10] <mapreri> oh
[16:10] <mapreri> wait
[16:10] <mapreri> u.u
[16:10] <ddstreet> so i think it does have my changes...they just aren't showing in the 'info' tab for whatever reason
[16:11] <ddstreet> very weird, maybe there is some bug going on with wiki.u.c
[16:12] <mapreri> trying to save a noop change to that page just has the browser hanging
[16:12] <ddstreet> anyway let's not review all of it now, i just edited it this morning based on our previous discussions...let's leave it for later review and ML or IRC discussion, or next mtg
[16:12] <ddstreet> assuming, of course, we can figure out how to get the page working ;-)
[16:13] <ddstreet> ok i'm going to carry over the action, i think there's still editing to be done
[16:13] <ddstreet> #action ddstreet update wiki docs with new process (carrired over)
[16:13] <meetingology> ACTION: ddstreet update wiki docs with new process (carrired over)
[16:13] <teward> (is the wiki broken?)
[16:14] <ddstreet> possibly :(
[16:14] <ddstreet> certainly something weird is happening there
[16:14] <teward> *lets it spin, will bug IS later*
[16:14] <ddstreet> mapreri start ML discussion for list of dev tools to proactively put into -backports
[16:14] <ddstreet> carry this over?
[16:14] <mapreri> I'll try to have a read of your wiki changes later tonight and yell at you if I read something weird :)
[16:14] <mapreri> ddstreet: nope, I did it earlier :P
[16:14] <teward> i know there was an action assigned to me, but my brain forgot because injury, so a reminder wouldn't hurt
[16:14] <ddstreet> great!
[16:15] <ddstreet> teward update tooling, requestbackport
[16:15] <mapreri> so I suppose you could +1 it there, and if it's +1'd copy it over to the wiki
[16:15] <ddstreet> yep agreed
[16:15] <teward> ddstreet: ack, i'll need a reminder of what we decided to make it do, but that's because my brain is totally whack
[16:15] <teward> most of the stuff will be carried over I think
[16:16] <teward> (we're entering a release cycle so we're all busy)
[16:16] <teward> s/cycle/period/
[16:16] <ddstreet> for requestbackport, i think we agreed to deprecate that and basically just have it print a message saying 'go look at our wiki page and dont use this tool anymore'
[16:16] <ddstreet> lets carry that over
[16:16] <ddstreet> #action teward update tooling, requestbackport (carried over)
[16:16] <meetingology> ACTION: teward update tooling, requestbackport (carried over)
[16:16] <teward> check that's easy
[16:16] <ddstreet> teward review backportpackage tool
[16:16] <ddstreet> this might be more work, i don't know what this tool does
[16:16] <ddstreet> carry over as well i assume
[16:17] <teward> yep
[16:17] <mapreri> that one needs to change the changelog version, specifically
[16:17] <ddstreet> #action teward review backportpackage tool (carried over)
[16:17] <meetingology> ACTION: teward review backportpackage tool (carried over)
[16:17] <teward> oh cool it's a python3 script
[16:17] <ddstreet> (unassigned) update wiki/docs to reflect users can't just request a backport, and deprecate 'requestbackport' tool to print message and url indicating same
[16:17] <mapreri> teward: yes, ubuntu-dev-tools is all python3 :)
[16:18] <ddstreet> i think this is done, based on my wiki changes, an in any case i think it's basically part of other action items
[16:18] <teward> (brb just spiled coffee)
[16:18] <ddstreet> (unassigned) define details on handling members/leads who are no longer participating (carried over)
[16:18] <mapreri> ddstreet: that requires contacting the doc team.  at least I think it was referring to help.u.c, wasn't it?
[16:19] <ddstreet> ah right, ok let's do an action specifically for that page...i actually might be able to edit the help.u.c page directly
[16:19] <ddstreet> #action ddstreet try to edit help.u.c page https://help.ubuntu.com/community/UbuntuBackports
[16:19] <meetingology> ACTION: ddstreet try to edit help.u.c page https://help.ubuntu.com/community/UbuntuBackports
[16:20] <ddstreet> #action (unassigned) define details on handling members/leads who are no longer participating (carried over)
[16:20] <meetingology> ACTION: (unassigned) define details on handling members/leads who are no longer participating (carried over)
[16:20]  * mapreri tries to auth to help.u.c....  it seems that "ubuntumembers" allow editing of allof that
[16:20] <ddstreet> define process/procedure for adding new members (carried over)
[16:20] <ddstreet> #action (unassigned) define process/procedure for adding new members (carried over)
[16:20] <meetingology> ACTION: (unassigned) define process/procedure for adding new members (carried over)
[16:20] <mapreri> .oO( it even loaded buttons in Italian for some reason, even if my browser preference is english)
[16:20] <ddstreet> yeah we may all be able to edit the page, though i had trouble with long delays trying to log into help.u.c
[16:21] <mapreri> it did take a while of browser loading yes
[16:21] <ddstreet> ok that's all the previous actions
[16:21] <ddstreet> #topic discussion
[16:21] <mapreri> should I start a ML thread about memberships, or let's keep it to the next irc meeting?
[16:22] <ddstreet> ML is fine with me for sure
[16:22] <teward> same
[16:22] <ddstreet> I created a page, similar to the DMB KB page that has info/references intended for use by team members https://wiki.ubuntu.com/UbuntuBackports/KnowledgeBase
[16:23] <ddstreet> #link https://wiki.ubuntu.com/UbuntuBackports/KnowledgeBase
[16:23] <mapreri> in that case, I'll get a text that is good enough to go into https://wiki.ubuntu.com/UbuntuBackports/KnowledgeBase and propose it
[16:23] <ddstreet> perfect
[16:23] <ddstreet> #action mapreri propose text for membership process to add to KB page
[16:23] <meetingology> ACTION: mapreri propose text for membership process to add to KB page
[16:24] <ddstreet> ok i had one detail i wanted to clarify about the process
[16:24] <teward> which is?
[16:25] <ddstreet> before, the process was for people to open bugs against a specific backports project, like 'focal-backports': https://launchpad.net/focal-backports
[16:25] <teward> yeah that's been an annoyance in the past
[16:25] <teward> do we need to do anything though from a tech perspective to just use standard bugs?
[16:25] <ddstreet> i'd like to change over to doing something similar to the UCA team, for example in this bug: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1940456
[16:26] <mapreri> ddstreet: so you'd still like tracking bugs?
[16:26] <mapreri> can't people just happily upload without bugs?
[16:26] <ddstreet> i think so
[16:26] <teward> request: define UCA
[16:26] <teward> (brainbleh)
[16:26] <ddstreet> sorry
[16:26] <ddstreet> UCA is Ubuntu Cloud Archive
[16:26] <teward> ah
[16:26] <teward> mapreri: i think it's going to be a case
[16:26] <teward> where those who can't upload will need a bug
[16:26] <ddstreet> essentially, it backports select 'cloudy' packages from later releases to earlier releases
[16:27] <teward> but those who CAN upload can upload without (but a tracking bug WOULD be nice for historic TIL purposes)
[16:27] <ddstreet> i think it would still be good to have a bug, just to track the upload, no?
[16:27] <teward> I'd prefer having the tracking bug yes, but as part of standard bugs not as part of its own package.
[16:27] <mapreri> those who can't upload likely need to find a sponsor, so that would follow the normal sponsorship procedure
[16:28] <mapreri> mh
[16:28] <ddstreet> i think if we can keep close to the SRU process, it might make it easier for existing people who are used to that
[16:28] <mapreri> I suppose we can
[16:28] <ddstreet> like, create a bug, add filled out template, prepare upload, then upload
[16:28] <mapreri> and the upload should close the bug as well?
[16:28] <ddstreet> yeah
[16:28] <mapreri> do uploads to -backports close bugs in LP?
[16:28] <teward> i think that will need some tech work though
[16:28] <teward> because i don't think -backports is tracked for that
[16:29] <teward> only the main repos
[16:29] <teward> s/main/standard/
[16:29] <ddstreet> i think the ~ubuntu-sru team's tooling closes the bugs, but we could re-use their tooling
[16:29] <mapreri> Isn't `queue` the one handling that?
[16:29] <mapreri> though I guess we need to double check
[16:30] <ddstreet> possibly? yeah we need to go thru their tooling to see how it applies to backports
[16:30]  * mapreri looks at its ubuntu-archive-tool checkout from oct 5th 2020
[16:30] <mapreri> happy birthday checkout
[16:30] <teward> heh
[16:30] <ddstreet> the issue without having any bug to track uploads is if we have feedback or any questions, there's really no way to do that without a corresponding bug
[16:31] <ddstreet> well, no easy way that leaves a record
[16:31] <teward> agreed, a bug for tracking should be needed
[16:31] <mapreri> I suppose we can go and do the same as for SRUs  (I never had anything to do with UCA, no idea of the workflow there)
[16:32] <mapreri> I mean, I'm not thrilled about adding paperwork, but I can be convinced about using tracking bugs for uploads
[16:32] <mapreri> also 1 bug for package/base_version?  so backporting a given to multiple releases would have a single bug targeted?
[16:32] <ddstreet> we can revisit the need for a bug if it becomes clear there are cases where it's not needed
[16:33]  * mapreri looks at his `bzr pull` that lead to a THIS_REPOSITORY_HAS_BEEN_MOVED_TO_GIT
[16:33] <ddstreet> yeah, a single bug would cover backporting into multiple releases, with each release as a 'target'
[16:34] <ddstreet> so similar to this UCA bug: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1940456
[16:34] <ddstreet> i envision instead of having 'affects' of 'Ubuntu Cloud Archive', it would have 'affects' of 'Ubuntu Backports'
[16:34] <mapreri> why is it UCA but has [SRU] ?
[16:34] <ddstreet> and then it would have sub-tabs of each release to backport to
[16:35] <ddstreet> that particular bug is *also* a SRU
[16:35] <mapreri> mh, how does this work
[16:35] <ddstreet> for us, it wouldn't have the 'affects' of 'ceph (Ubuntu)'
[16:35] <mapreri> oh, so you mean bugs against the "ubuntu backports" project, instead of packages?
[16:35] <ddstreet> right, for SRUs, the bugs are against e.g. 'ceph (Ubuntu)'
[16:36] <ddstreet> for us, it would be against 'Ubuntu Backports', similar to how it's against 'Ubuntu Cloud Archive'
[16:36] <teward> i'm a little confused, wouldn't that complexify the process?
[16:36] <mapreri> Is there any benefit in having bugs filed against another project?
[16:36] <teward> i don't really think so
[16:36] <teward> UCA is a unique thing
[16:36] <mapreri> yeah
[16:36] <teward> backports is just the same basically as a standard SRU bug except targeting -backports
[16:36] <ddstreet> i think what we are going to do it very similar to UCA
[16:36] <mapreri> also, for us views like https://bugs.launchpad.net/~ubuntu-backporters/+subscribedbugs ought to be enough
[16:36] <mapreri> It really shouldn't be
[16:36] <teward> if we're going to redo the process I'd rather do a special Backports item but NOT a special project
[16:37] <teward> i agree with mapreri here
[16:37] <mapreri> packages uploaded to backports are expected to be the same of what is already in the archive
[16:37] <teward> ddstreet: so, file the bug tag [Backports] and sub backporters to it.
[16:37] <teward> we don't need the extra "assign it to UCA project" extra complexity
[16:37] <teward> provided we require ubuntu-backporters to be subscribed to all backport bugs
[16:37] <mapreri> like, I see this much more similar to SRUs than UCAs
[16:37] <ddstreet> hmm, i think we're misunderstanding each other
[16:37] <teward> ddstreet: so you're combining "SRU" and "UCA" and confusing us
[16:38] <teward> so let's start with the basic definition of any bog-standard SRU bug
[16:38] <ddstreet> let's start at step 1 - what specific URL do you see people going to when they want to open a backport bug?
[16:38] <teward> ddstreet: the standard bug filing page for a given package?
[16:38] <teward> i.e. bugs.launchpad.net/ubuntu/+source/SRCPKGNAME
[16:38] <teward> and file a bug
[16:38] <ddstreet> the problem with that is, that will send an email to *everyone* subscribed to that package in ubuntu
[16:39] <teward> ddstreet: and that's a problem how?  They get SRU bugs the same way
[16:39] <teward> except we'd have [Backports]
[16:39] <teward> instead of [SRU]
[16:39] <teward> and then that's for those subscribers awareness (like for SRUs) but not necessarily needing action
[16:39] <mapreri> (let's call it [BPO] for pickyness and shortness pls)
[16:39] <teward> (i'm talking theory not actual execution mapreri)
[16:39] <ddstreet> well that's certainly one way, but then people would just mark it as 'invalid'
[16:39] <teward> ddstreet: unless everyone receives other guidance that it's not invalid
[16:40] <teward> it's a process bug
[16:40] <ddstreet> since 'ceph (Ubuntu)' (for example) is only valid for SRUs
[16:40] <teward> ddstreet: then we can't use the tooling to track backports and close bugs
[16:40] <mapreri> we are creating a process here, that is used in the official ubuntu project.  I don't see anything wrong with adding a process bugs to pacakges.
[16:40] <teward> ^^ agreed
[16:40] <mapreri> ubuntu contributors ought to learn a new teeny bit that bugs titled [BPO] or whatever are something
[16:41] <teward> ignore current systems, we're creating new processes *based* on existing processes, but are a new process
[16:41] <ddstreet> ok, but we all agree that at the end once the bug is done, the '(Ubuntu)' targets will all be marked as 'wontfix' or 'invalid' right?
[16:41] <mapreri> I also half-expect random ubuntu contributors to be interested in backports-specific bugs tbh
[16:41] <teward> ddstreet: i'm not sure about that
[16:41] <teward> because a "Fix Released" means a backport will have landed in -backports
[16:41] <mapreri> that would "fix released" wouldn't it?
[16:41] <ddstreet> ouch
[16:41] <ddstreet> no, that means the bug/feature is fixed in -updates
[16:41] <teward> ddstreet: for SRUs
[16:41] <mapreri> that's for [SRU]
[16:41] <teward> but we're creating a separate development process bug
[16:41] <teward> for Backports
[16:42] <teward> which means it would have independent definitions (bugsquad can update their documentation)
[16:42] <ddstreet> is ee
[16:42] <teward> so you're thinking SPECIFICALLY for SRUs
[16:42] <teward> this is a brand new process that is for backports
[16:42] <teward> so 'Fix Committed' means uploaded to -backports, 'Fix Released' means it's built and published
[16:42] <teward> but in -backports, not -updates
[16:43] <ddstreet> the problem is that *lots* of people subscribe to these packages and this process is kind of hijacking that
[16:43] <teward> remember, there's a LOT of special bugs out there too like MIR bugs as well
[16:43] <teward> which don't follow the standard processes either
[16:43] <ddstreet> i would expect a lot of complaints about emails
[16:43] <mapreri> honestly, if I have to see tracking bugs, I would totally copy-paste from SRU, and just replace the "SRU" string into "BPO" (and a shorter and simpler template…)
[16:43] <teward> ddstreet: would you prefer we defer to the TB for a suggestion on best approach here?
[16:43] <teward> or at least query them for their opinion
[16:43] <mapreri> you have some high expectations of people reading bug mails in ubuntu IMHO
[16:43] <ddstreet> well, i do see the benefit of just re-using the existing packages
[16:44] <teward> (my opinion as a backporters team member carries the additional stigma of anything I say being read with the grain of salt of my other hats)
[16:44] <mapreri> I spent the past 10 years groumbling about how nobody answers bugs in ubuntu…
[16:44] <mapreri> grumbling
[16:44] <ddstreet> he lol
[16:44] <ddstreet> well that's true, emails are largely ignored from bug reports :)
[16:44] <teward> my opinion is, it's just another dev process bug and MOST people ignore the bugs
[16:44] <ddstreet> ok i'm convinced then
[16:44] <teward> hell I have at least 50 emails overnight for -sponsors that I'm ignoring
[16:45] <teward> (and sponsors gets subbed to pretty much every bug with a patch / debdiff automatically)
[16:45] <mapreri> I was in that list when I was an active sponsor, but then I figured it was better to unsub than add a filter...
[16:45] <ddstreet> so our process will be to open a bug against the specific package in ubuntu, and the subject should have [BPO]
[16:45] <ddstreet> right?
[16:45] <teward> following a process and template we will define and document
[16:45] <teward> correct
[16:45] <mapreri> and upload at the same time (if there are no blocking reasons for)
[16:45] <teward> correct
[16:45] <ddstreet> right yeah
[16:46] <ddstreet> #agreed BPO bugs will be opened against package in Ubuntu with subject prefix of [BPO]
[16:46] <meetingology> AGREED: BPO bugs will be opened against package in Ubuntu with subject prefix of [BPO]
[16:46] <ddstreet> ok cool! i'll update the wiki page to reflect that, so ignore what i previously added to the wiki
[16:47] <ddstreet> that was the only clarification i wanted to talk about here
[16:47] <mapreri> happy to sort this out
[16:47] <ddstreet> i'm actually pretty happy you guys convinced me to do that, it's better than what i was thinking :)
[16:47] <teward> (and simpler)
[16:47] <ddstreet> yes
[16:47]  * mapreri will also be happier once we figure bugs are useless! \o/
[16:47] <teward> lol
[16:47] <ddstreet> lol
[16:48] <ddstreet> ok i guess one more clarification
[16:48] <teward> mapreri: and where someone has no upload rights, then it needs -sponsors subbed
[16:48] <teward> (which will then mean a coredev sponsor will need upload rights)
[16:48] <ddstreet> in the wiki, i'd stated that people should put a 'template' into the bug, explaining *why* the backport is needed
[16:48] <ddstreet> along with the test details, etc
[16:48] <teward> s/upload rights/to upload/
[16:48] <mapreri> teward: or just get his core-dev friend to sign directly..?
[16:48] <ddstreet> do we think we need that info?
[16:48] <teward> mapreri: dput wil explode
[16:49] <teward> ddstreet: basic justification would be fine, as well as confirming that it builds as is in a backport
[16:49] <mapreri> I'm not going to bother ~ubuntu-sponsors with all the core-devs I'm in contact with…
[16:49] <teward> and any extra changes.
[16:49] <teward> mapreri: well TBH there's overlap with me :P
[16:49] <mapreri> ? what about dput?
[16:49] <teward> so i can always prod the first dozen or so backport bugs :P
[16:49] <teward> mapreri: well I think if you don't have access it doesn't have your keys in accepted dput
[16:49] <teward> but i'll double check later
[16:49] <teward> either case, there's a few ways to get it in
[16:49] <teward> (irrelevant to the discussion)
[16:50] <teward> ddstreet: If you request a backport without a basic justification then we run itno the problem of "Will we approve every backport request"
[16:50] <mapreri> ddstreet: I agree to what teward said about the template btw.  but keep it very simple, no need to be like the SRU one
[16:50] <teward> if there's a basic reason for the backport even "I want a new version in the older version of Ubuntu" that'd be sufficient
[16:50] <teward> provided a basic "This builds" confirmation or such
[16:50] <mapreri> teward: that said, do you like the justification: "I'd like to run newer X on my own machine"?
[16:50] <teward> we *really* don't need a complex template here.
[16:51] <mapreri> I regularly do such backports in debian for my own benefits u.u
[16:51] <ddstreet> ack, ok - i kept it similar, but we can change it; i put it into the wiki page, so we cna discuss the details of the template later in ML
[16:51] <teward> mapreri: well i'm using a very basic example :P
[16:51] <teward> but yes
[16:51] <teward> mapreri: but i'd also read that with a grain of salt and point at a PPA if they just want newer but have no intention to keep an eye on it
[16:52] <mapreri> ok, let's just hope we 3 have some common sense when it comes to it i suppose
[16:52] <teward> (so we should probably have a KB entry there that says "While backports gets newer versions into older Ubuntu releases, they do still need to be maintained.  If you are just wanting the newer version but have no intention to maintain it from an updates / security perspective, consider building the package in a PPA just for yourself instead."
[16:52] <teward> or similar)
[16:52] <ddstreet> lol, someone wanted the latest glibc, nothing wrong with backporting that right? xD
[16:52] <teward> lol
[16:52] <teward> ddstreet: that's on the list of "Not happening" that we already mentioned last meeting
[16:52] <teward> toolchain packages are not allowed for backports
[16:53] <mapreri> right, where is the action item about "blacklisted packages"?
[16:53] <mapreri> bundled with you rewriting the wiki?
[16:53] <teward> mapreri: i don't think we came up with the list, or rather, documented it
[16:53] <teward> ^^ that
[16:53] <ddstreet> let's action item that specifically
[16:53] <teward> we spent like 20 minutes on it last time *over* meeting time on that topic alone 'cause i'm a persistent SOB
[16:54] <ddstreet> #action (unassigned) create list of packages excluded from backporting (carried over)
[16:54] <meetingology> ACTION: (unassigned) create list of packages excluded from backporting (carried over)
[16:54] <teward> ^^ alternatively "list of certain types of packages"
[16:54] <ddstreet> we should probably do that in the ML, along with the pre-approved list
[16:54] <teward> because otherwise that's an insane list :P
[16:54] <mapreri> I'll see if I can do that, but don't assign to me directly
[16:54] <teward> we can discuss via ML
[16:54] <mapreri> (i mean, starting it)
[16:55] <mapreri> changing topic, I reckon none of you tried `queue` from ubuntu-archive-tools right?
[16:55] <ddstreet> yeah i think we're quite close to getting the process nailed down enough to do most of the discussion over ML
[16:55] <ddstreet> i have not yet
[16:55] <ddstreet> either of you tried it yet?
[16:55] <teward> mapreri: E:NOTIME
[16:56] <teward> esp given injury last wednesday in the middle of the week
[16:56] <mapreri> I seem unable to find a flag to tell me about pockets != release
[16:56] <teward> which totally fubar'd my weel
[16:56] <teward> week*
[16:56] <ddstreet> yeah, i suspect we might need to update or fork some of their tooling for use with backports
[16:56] <teward> yep
[16:56] <teward> (I'm gonna go nip out and pick up lunch, anything else to discuss?)
[16:56] <mapreri> considering that I'm unable to get the "proposed" pocked either, I suppose it's PEBKAC
[16:57] <ddstreet> nothing else from me, should we wrap up?
[16:57] <mapreri> yeah, let's
[16:57] <teward> yup
[16:57] <ddstreet> i assume i should schedule another mtg in 2 weeks?
[16:57] <mapreri> please
[16:57] <teward> yep
[16:57] <ddstreet> will do
[16:57] <ddstreet> thanks!
[16:57] <ddstreet> #endmeeting
[16:57] <meetingology> Meeting ended at 16:57:39 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-10-06-16.05.moin.txt
[16:57] <mapreri> o/
[16:57] <ddstreet> thanks mapreri teward o/
[16:57] <teward> yep
[16:57] <teward> ddstreet: see PMs btw
[16:57] <teward> (I'm going to get lunch)
[16:58]  * genii mops up teward's spilt coffee
[16:58] <teward> genii: don't forget to get me another coffee :P
[16:58] <genii> Hah, certainly
[17:03] <mapreri> why is google calendar unable to properly link my google account with my @ubuntu.com address that _is_ connected to my google account -.-
[17:28] <Kilos> wooooo hi genii
[17:29] <Kilos> long time no see
[17:31]  * genii slides Kilos a nice fresh coffee also
[17:32] <Kilos> ty ty ty
[17:32] <genii> Anytime of course sir