=== genii is now known as genii-core [08:51] o/ [15:56] o/ [15:59] o/ [16:00] hi o/ [16:01] teward around? [16:02] let's give teward a minute or two, then get started [16:02] sure [16:04] ok let's go ahead then [16:04] #startmeeting Ubuntu Backporters [16:04] Meeting started at 16:04:09 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology [16:04] Available commands: action, commands, idea, info, link, nick [16:04] ok! let's go over previous action items...i think some did get done :) [16:04] #topic Previous Action Items [16:04] #subtopic ddstreet email ubuntu-devel list to announce re-opening of backports (carried over) [16:04] sadly not yet :( i definitely will before next mtg :) [16:05] #action ddstreet email ubuntu-devel list to announce re-opening of backports (carried over) [16:05] ACTION: ddstreet email ubuntu-devel list to announce re-opening of backports (carried over) [16:05] #subtopic ddstreet open bug on u-d-t to update backportpackage script [16:05] #link https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1959115 [16:05] done! [16:05] Launchpad bug 1959115 in ubuntu-dev-tools (Ubuntu) "update backportpackage script to behave according to new backport process" [High, New] [16:05] oh, reading [16:06] well it's only a bug opened to track it [16:06] so, the actual *work* isn't done [16:06] sorry, reading what you wrote here heh [16:06] I was distracted [16:06] yeah, I've seen that bug in my mailbox, cool, ta [16:06] #subtopic ddstreet update wiki page clarifying requestors should subscribe ~ubuntu-backporters to BPO bugs [16:06] mapreri did this one - thanks! :) [16:06] #subtopic ddstreet update internal KB page with details about uploads going to 'New' instead of 'Unapproved' queue (carried over) [16:06] I actually forgot it was part of the meeting todo when I did lol [16:07] yeah me too :) [16:07] #action ddstreet update internal KB page with details about uploads going to 'New' instead of 'Unapproved' queue (carried over) [16:07] ACTION: ddstreet update internal KB page with details about uploads going to 'New' instead of 'Unapproved' queue (carried over) [16:07] i'm late sorry [16:07] got busy with a call to GoDaddy [16:07] #subtopic ddstreet update tooling, requestbackport, backportpackage (carried over) [16:07] need to carry that as well - and as before, if either of you want to do the tool updates please feel free [16:08] wait, the one about backportpackage, was that checked recetly? [16:08] #action ddstreet update tooling, requestbackport, backportpackage (carried over) [16:08] ACTION: ddstreet update tooling, requestbackport, backportpackage (carried over) [16:08] i figured unit193's patch was enough, or..? [16:08] i have not actually checked... [16:08] does it match our new process? [16:08] well, in backportpackage it was mostly about adapting the changelog version, and that was done, so I *think* so [16:09] but should probably be extra-verified… [16:09] ok yeah, let's leave the action in there at least until we double-check it works as we expect [16:10] also, perhaps the bug above should be changed to include also requestbackports, perhaps [16:10] if you ack I'll tweak the title and text [16:10] yep ack [16:10] thanks! [16:10] #subtopic ddstreet fix-released bugs for accepted uploads [16:11] that's done, for all bugs our team is subscribed to [16:11] #subtopic ddstreet raise topic of rescheduling meeting on ML [16:11] i did not send this email yet...should we just discuss now? or will it be easier to work it out on ML? [16:12] here would be quicker most likely. [16:12] this day/time works ok for me for the first 30 min...i have an overlap at the bottom of the hour though [16:12] mapreri teward is there a better day and/or time for you? [16:13] i don't mind adjusting the schedule times [16:13] my schedule is relatively flexible until chaos erupts at FT job [16:13] I'd have a preference if we could move this back 1 hour. In practice, follow DST, so in winter it would be at 17 UTC instead of 16 UTC (but not in summer) [16:14] that would probably work for me, though i would have a mtg right before it so i may be late sometimes [16:14] → https://time.is/compare/1700_26_Jan_2022_in_UTC [16:14] actually, my meeting usually ends on time, so 17:00 utc should work for me [16:14] that works for me [16:15] perhaps 17.15 or .30 so it's not a risk of overlaps? it's not our meeting takes up much [16:15] and what does your other meeting do wrt DST? [16:15] mapreri if we track DST though, i believe USA and Europe have different DST start/end dates? [16:15] my other meeting does track USA DST [16:15] yeah well, in that time normally either one side or the other just suck it for one round :3 [16:16] (leaving the choice to whoever organizes) [16:16] ok so are we all ok with 17:30 UTC, following USA DST? [16:17] meaning, 12:30PM Eastern time [16:17] so next round would be https://time.is/compare/1730_09_Feb_2022_in_UTC ? === genii-core is now known as genii [16:17] yep [16:17] yup [16:17] works here [16:17] cool [16:17] awesome! i'll action item that change [16:18] that said, the 9th of Feb I might be travelling during the whole afternoon so I might miss it (i'll confirm it later on though) [16:18] :/ [16:18] #action ddstreet schedule next meeting at 12:30pm Eastern time, following USA DST schedule [16:18] ACTION: ddstreet schedule next meeting at 12:30pm Eastern time, following USA DST schedule [16:18] now, to just drop DST what do we do [16:18] re-aligning the world [16:18] i really want everywhere to drop DST [16:18] it's just too annoying [16:19] annoying enough locally - but then having to work out the differences with contacts in other countries/TZs [16:19] it hurts my head [16:19] ok anyway, let's move on [16:19] #subtopic mapreri propose text for membership process to add to KB page (carried over) [16:19] yeah, carried over [16:20] #action mapreri propose text for membership process to add to KB page (carried over) [16:20] ACTION: mapreri propose text for membership process to add to KB page (carried over) [16:20] #subtopic mapreri upload (more of) all the tools (carried over, in progress) [16:20] #action mapreri upload (more of) all the tools (carried over, in progress) [16:20] ACTION: mapreri upload (more of) all the tools (carried over, in progress) [16:20] i assume carry over for that and the next one [16:20] #subtopic mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) [16:20] Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open] [16:20] lintian isn't done yet is it? [16:20] mh is taht miissing still? [16:20] the one about uploading the tools [16:21] probably mh [16:21] there are a couple to update at the very least, so just leave it there sure [16:21] I'll get to it rsn [16:21] ack [16:21] yeah no hurry, we can leave it or drop it whenver [16:21] I think lechner pretty much ignored that bug, I'll poke him on irc later [16:21] i suspect it'll be a never-ending process of keeping the tools updated [16:22] that's the point :) [16:22] :) [16:22] ok i'll action the lintian one too for now [16:22] #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) [16:22] ACTION: mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) [16:22] Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open] [16:23] ah, I see now that lechner did raise some points about it mh [16:23] I'll follow up [16:23] we have unassigned actions too, i'll go thru them, if anyone wants to take any of them (or has completed any) please speak up, otherwise i'll just re-action them [16:23] #subtopic (unassigned) define details on handling members/leads who are no longer participating (carried over) [16:24] that should likely come after the membership process above [16:24] #action (unassigned) define details on handling members/leads who are no longer participating (carried over) [16:24] ACTION: (unassigned) define details on handling members/leads who are no longer participating (carried over) [16:24] #subtopic (unassigned) define process/procedure for adding new members (carried over) [16:24] mh [16:24] how is that any different than "propose text for membership process to add to KB page" ? [16:25] probably not really different [16:25] drop it? [16:25] yeah, i think it came up from concerns about non-participating DMB members...but it definitely should just be part of the whole 'membership process' [16:25] ack to dropping it [16:26] non-partecipating members is the one before, which is fine to leave separate so we make sure it's included [16:26] ah right ok [16:26] this current one looks just a duplicate, however :) [16:26] yeah definitely :) [16:26] pls nobody disappear until we have the text in place :3 [16:27] lol [16:27] maybe we should remove this unassigned item and update the action you have to specify 'including non-participating' [16:27] does seem like just a subset of the process action [16:27] as you'd like [16:28] ack, yeah just administriva details - i'll update next mtg's agenda with them folded togehter [16:28] #subtopic (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:28] don't think this is done? [16:28] nope [16:28] #action (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:28] ACTION: (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [16:28] and nobody likes dechange's code, so it'll likely stay there for a while :3 [16:28] #subtopic (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs [16:29] i think this is an important one we should get assigned either now, or next mtg [16:29] looking at my own todo list, I'd rather not take this one myself, sorry [16:29] ok [16:30] teward you have time? if not we can carry it to next mtg [16:30] assign it then [16:30] ok let's just carry it [16:30] #action (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs [16:30] ACTION: (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs [16:31] #subtopic make sure wiki page includes requirement to add LP:# tag in backport changelog [16:31] i haven't actually checked this [16:31] it's not there [16:31] ok i'll take it, should be a quick change [16:31] ack [16:31] #action ddstreet make sure wiki page includes requirement to add LP:# tag in backport changelog [16:31] ACTION: ddstreet make sure wiki page includes requirement to add LP:# tag in backport changelog [16:31] ok that's all the action items! [16:31] alright [16:31] let's move to AOB? [16:32] yes pls [16:32] #topic AOB [16:32] Q: [16:32] do we want to enforce bugs also for trivial updates of already backported things? [16:33] Case that happened: a guy already had their bpo approved and already there. they uploaded an updated that I accidentally noticed the other day, and after looking at it, it just felt fine to approve it… but there wasn't a bug. tbh this felt mostly "fine" to me, but perhaps we want more tracking for some reason? [16:33] i think we dont need them if it's trivial...but if the reviewer rejects, the rejection comment should probably ask for a bug opened to discuss it [16:33] s/an updated/an update/ [16:33] the rejection case sounds fair, yep [16:34] i got called to fix something sorry [16:34] yeah basically i think we agree, ok to upload without a bug for simple backports, we can request a bug if we have any concerns, yeah? [16:34] ddstreet: for super simple i agree, for anything that requires any deviation from 'simple' then it needs a bug [16:34] my 2 cents [16:34] k. do we want to make this written, or just keep it as a tribal knowledge, so people don't get over-excited of skipping bugs? [16:34] i'd keep it as tribal knowledge [16:35] because we don't want to *encourage* skipping the processes [16:35] or make people think that 'what's simple to them is actually a simple case that doesn't need a bpo bug" [16:35] well, that leaves it ambigous for reviewers as well [16:35] i'd say we work out specific wording for an 'acceptable' no-bug backport? [16:35] agreed [16:36] and potentially detail some examples [16:36] like 'if there are no code changes and the package is already in the target backport pocket' or something like that? [16:36] > if there are no code changes [16:36] that's where i start saying "Define code changes" [16:36] that sounds like a job for another #action to propose a fine wording. The term "trivial" is clearly too ambiguous too [16:36] should we work out the specific wording on ML? I can start a thread...I just started my other mtg, so my attention is divided now :( [16:36] yes lets start on specific wording on the ML [16:36] yeah [16:36] yep definitely 'trivial' can mean different things :) [16:37] i'm diverted to my FT job because somehting's on 'fire' [16:37] #action ddstreet start thread on ML to clarify wording for no-bug-required backports [16:37] ACTION: ddstreet start thread on ML to clarify wording for no-bug-required backports [16:37] teward's job is clearly too hot, being on fire so often /o\ [16:37] lol [16:37] lol [16:37] yeah [16:37] i hope you have a fireproof suit teward [16:37] mapreri: not my fault that the one team that has yielded their stuff to IT at my FT job are all using legacy/EOL crap [16:37] literally EOL crap that i'm having to use bits of my UA-I seats for temporarily >.> [16:37] (8.04 anyone?) [16:38] (that's the oldest i'm currently porting stuff to a 20.04 system for) [16:38] I knoe the fealing, having inherited a bunch of 14.04 myself... or so I though but at least it doesn't get to single-digit releases [16:38] ddstreet: i'm literally fireproof now heh [16:38] mapreri: two 12.04s, six 14.04s, one 8.04 [16:38] but i digress [16:38] yep [16:39] alright, ddstreet: let's close up? :) [16:39] the old stuff is breaking so i keep having to move things into emergency migration mode [16:39] yep yep [16:39] sounds good, last call for anything else? [16:39] 5... [16:39] 4... [16:39] 3... [16:39] 2... [16:39] give coffee? [16:39] :P [16:39] 1... [16:39] #endmeeting [16:39] Meeting ended at 16:39:48 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-01-26-16.04.moin.txt [16:39] (no other buisness from me) [16:39] ty both, o/ [16:39] thanks all! [16:40] thank you! [21:49] * genii sweeps up and washes the coffeepot [22:40] o/ [22:55] genii: Don’t drink too many cups of coffee, which are not good [22:56] :P [23:04] Wasn’t there supposed to be a meeting right now?