16:03 <ddstreet> #startmeeting Ubuntu Backporters 16:03 <meetingology> Meeting started at 16:03:44 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology 16:03 <meetingology> Available commands: action, commands, idea, info, link, nick 16:03 <mapreri> making 3 people agree can be harder than one can imagine :D 16:04 <ddstreet> lol that is indeed true :) 16:04 <ddstreet> i've been trying to reschedule the DMB meeting too, and that was WAY harder than i thought it would be...still not even done yet... 16:04 <ddstreet> anyway 16:04 <ddstreet> ok let's review the previous items 16:05 <ddstreet> #topic ddstreet email ubuntu-devel list to announce re-opening of backports (carried over) 16:05 <ddstreet> ugh, i dont think i did this yet, but let's carry over and i definitely will before EOY 16:05 <ddstreet> #action ddstreet email ubuntu-devel list to announce re-opening of backports (carried over) 16:05 * meetingology ddstreet email ubuntu-devel list to announce re-opening of backports (carried over) 16:05 <ddstreet> i'm going to carry over teward actions since he isn't here 16:05 <ddstreet> #action teward update tooling, requestbackport (carried over) 16:05 * meetingology teward update tooling, requestbackport (carried over) 16:05 <ddstreet> #action teward review backportpackage tool (carried over) 16:05 * meetingology teward review backportpackage tool (carried over) 16:06 <ddstreet> we might need to get that backportpackage tooling change sped up, i think there's been some confusion with people trying to use it still 16:06 <ddstreet> #topic mapreri propose text for membership process to add to KB page (carried over) 16:06 <ddstreet> carry over i assume? 16:06 <mapreri> that will happen by EOY as well, I'm sure! 16:06 <ddstreet> #action mapreri propose text for membership process to add to KB page (carried over) 16:06 * meetingology mapreri propose text for membership process to add to KB page (carried over) 16:07 <ddstreet> all the unassigned actions let's carry over 16:07 <ddstreet> #action (unassigned) define details on handling members/leads who are no longer participating (carried over) 16:07 * meetingology (unassigned) define details on handling members/leads who are no longer participating (carried over) 16:07 * mapreri doesn't fully understand why people would even need a tool such backportpacakge to do such trivial taskā¦ tbh 16:07 <ddstreet> #action (unassigned) define process/procedure for adding new members (carried over) 16:07 * meetingology (unassigned) define process/procedure for adding new members (carried over) 16:07 <ddstreet> #action (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls 16:07 * meetingology (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls 16:07 <ddstreet> #action (unassigned) fix lintian to not complain about ~bpo suffix 16:07 * meetingology (unassigned) fix lintian to not complain about ~bpo suffix 16:07 <mapreri> I can take this 16:07 <mapreri> in the form of opening a bug 16:07 <ddstreet> great! 16:07 <ddstreet> #action mapreri fix lintian to not complain about ~bpo suffix 16:07 * meetingology mapreri fix lintian to not complain about ~bpo suffix 16:08 <mapreri> don't you need #undo i guess? 16:08 <ddstreet> oh wow does that work? 16:08 <ddstreet> #undo (unassigned) fix lintian to not complain about ~bpo suffix 16:08 <meetingology> Removing item from minutes: ACTION 16:08 <ddstreet> ha nice! 16:08 <mapreri> mh 16:08 <mapreri> does THAT work 16:08 <mapreri> back "in my times" it used to remove the "last recorded item" 16:08 <ddstreet> mh 16:08 <ddstreet> doesnt' seem to 16:08 <mapreri> we'll discover in the produced minutes i guess 16:09 <ddstreet> i should probably read the docs for meetingology some day 16:09 <ddstreet> yep :) 16:09 <ddstreet> you want the DEB_VENDOR action too? 16:09 <mapreri> nope 16:09 <ddstreet> ack 16:09 <ddstreet> and for the rescheduling 16:10 <ddstreet> #action ddstreet raise topic of rescheduling meeting on ML 16:10 * meetingology ddstreet raise topic of rescheduling meeting on ML 16:10 <ddstreet> feel free to raise the topic if you'd like to also 16:10 <mapreri> don't we have an item for me to upload all of the tools ? 16:10 <ddstreet> no but we can create one :) 16:10 <mapreri> unfortunately I failed to get around to it 16:10 <mapreri> better to have it tracked 16:10 <ddstreet> #action mapreri upload all the tools 16:10 * meetingology mapreri upload all the tools 16:11 <mapreri> so, I didn't even get around to it yet, but I see you handling the LO bug and one another. how was the "feeling" from this side of the job of reviewing? 16:11 <mapreri> I think that was the real first contribution under the new rules? 16:11 <ddstreet> yep i believe so 16:11 <mapreri> "to it" = "to read it" 16:12 <ddstreet> it seemed pretty straightforward, though i think there's still some confusion over the need to simply 'open a bug' vs. actually finding a sponsor to upload 16:12 <ddstreet> but this was just from 2 bugs so small sample size, and new process 16:12 <mapreri> the LO process required a sponsor? 16:12 <ddstreet> no that one didn't 16:12 <mapreri> wasn't it done by the mail ubuntu LO maintainer? 16:12 <mapreri> ah the other one then 16:12 <ddstreet> it was yeah 16:12 <mapreri> sdbus-cpp ? 16:13 <ddstreet> yep 16:13 <mapreri> it has a "Please" at the start of the subjct :( 16:13 <ddstreet> to be fair, i am pretty sure it was opened long before the new process 16:13 <ddstreet> April, i think 16:13 <mapreri> 2021-02-18 16:13 <ddstreet> yeah so back when 'open a bug' was the process :) 16:13 <mapreri> fair, i guess 16:13 <mapreri> it's still early, and not even announced 16:14 <ddstreet> from our side of it, i do think we need to work out some better tooling, or at least figure out how to use the 'queue' script 16:14 <mapreri> ack 16:14 <mapreri> anyway, should we move to the main part of the meeting? 16:15 <ddstreet> yep 16:15 <ddstreet> #topic Discussion 16:15 <ddstreet> I added some items to the agenda, obviously you or anyone should feel free to add items anytime too, or just bring up stuff during this part of the mtg 16:15 <ddstreet> let's go thru the 2 listed items 16:16 <ddstreet> #subtopic Clarification on BPO bug assignee 16:16 * mapreri look at Mr. anyone :eyes: 16:16 <ddstreet> lol i'm sure we have just so many lurkers interesting in backports, don't we? xD 16:17 <ddstreet> anyway for this clairification, in the sdbus-cpp bug it was brought up that the wiki isn't clear about who should 'own' the BPO bug, or if that's even important to the process 16:17 <ddstreet> for SRUs, it's not really important, but for other stuff like the MIR process, it is important 16:18 <ddstreet> i don't think I care either way, but it might be helpful if ~ubuntu-backporters gets assigned the bug after it's uploaded, so we would get an email? 16:18 <ddstreet> or at least, the bug would be visible in a bug search 16:18 <ddstreet> what do you think? 16:19 <mapreri> I think it could help in case too many bugs gets subscribed to us AND ~ubuntu-sponsors, in which case, effectively, there is nothing for us to do. 16:19 <mapreri> i guess right now our "working queue" is https://bugs.launchpad.net/~ubuntu-backporters/+subscribedbugs 16:19 <mapreri> (which we should really clean up, #action ? I can take this) 16:20 <mapreri> i suppose the real question is: do we think it's worth the extra "procedure line" just so that we can split the above bug lists *also* into https://bugs.launchpad.net/~ubuntu-backporters/+assignedbugs ? 16:20 <ddstreet> personally i don't think it's worth it 16:21 <mapreri> fwiw, the sru page doesn't even have one match for /assign/. 16:21 <ddstreet> i think our mandate is to review uploads to the backports queues, right? we aren't taking responsibility for guiding BPO bug requests along 16:21 <mapreri> well, we want to be subscribed to the bugs so that we can review things, even before uploads, aren't we? 16:21 <mapreri> else why are bothering with bugs at all. 16:22 <mapreri> plus I suspect people subscribing the teams actually want something from us, in general? :O 16:22 <ddstreet> the bugs can be useful to have a discussion when rejecting uploads 16:22 <ddstreet> but yeah, i think *subscribing* us to bugs is ok; i don't think we should care about who is actually the bug *owner* though right? 16:23 <ddstreet> meaning the wiki should mention 'subscribe ~ubuntu-backporters to BPO bugs' but the wiki shouldn't say anything about the bug owner/assignee right? 16:23 <mapreri> i agree, yes 16:24 <ddstreet> ack, let's action item that then, you want to update the wiki or should i? i'm fine doing adminitrative stuff like this unless you're eager to :) 16:24 <mapreri> I think I'll give this to you 16:24 <mapreri> and I take cleaning up https://bugs.launchpad.net/~ubuntu-backporters/+subscribedbugs from old stuff 16:24 <ddstreet> #action ddstreet update wiki page clarifying requestors should subscribe ~ubuntu-backporters to BPO bugs 16:24 * meetingology ddstreet update wiki page clarifying requestors should subscribe ~ubuntu-backporters to BPO bugs 16:25 <ddstreet> awesome 16:25 <ddstreet> #action mapreri clean up https://bugs.launchpad.net/~ubuntu-backporters/+subscribedbugs 16:25 * meetingology mapreri clean up https://bugs.launchpad.net/~ubuntu-backporters/+subscribedbugs 16:25 <ddstreet> #subtopic Does wiki page need hint about checking the New upload queue? 16:25 <mapreri> "Backport xtables-addons 2.6-1 to trusty" - fwiw, are uploads to trusty still actually open? 16:25 <ddstreet> sorry, that's all for the last topic right? 16:25 <ddstreet> no 16:26 <ddstreet> trusty repo is closed 16:26 <mapreri> yes, let's go ahead 16:26 <ddstreet> for this clarification, the issue was that the sdbus-cpp package didn't exist at all in focal, so the upload went into the 'New' queue, instead of the 'Unapproved' queue 16:27 <ddstreet> essentially, normal SRU uploads always wind up here https://launchpad.net/ubuntu/focal/+queue?queue_state=1 16:27 <mapreri> that's not weird at all, isn't it? 16:27 <mapreri> it's the same for any kind of upload, also for SRU for non-existing packages 16:27 <ddstreet> but a backport of a *new* package goes here https://launchpad.net/ubuntu/focal/+queue?queue_state=0 16:28 <ddstreet> yeah, but non-existing packages are rarely (if ever?) SRUed 16:28 <mapreri> every so often *shrugs* 16:28 <ddstreet> yep 16:28 <mapreri> I also did upload one, and the sru team didn't notice but handled stuff besides that one 16:28 <mapreri> (like, an sru to multiple releases, some with that package, some without) 16:28 <mapreri> which is saying, even the sru gets "confused" about it :D 16:28 <ddstreet> the question from the sponsor was, shoudl the wiki have a statement (hint, really) for sponsors to check the 'New' queue if their upload doesn't appear in the 'Unapproved' queue 16:29 <ddstreet> yep 16:29 <mapreri> I don't think uploaders should care about this implementation detail, at all. 16:29 <mapreri> they get an email on upload, that should be it 16:29 <ddstreet> as a side note, when we approve an upload, the binaries get put into the 'New' queue and need our approval - so we actually have a 2-step approval process, first the source upload, then the binary packages 16:30 <mapreri> at most, add it as a line on the KB "internal" page, surely not for the people contributing. 16:30 <ddstreet> that's my feeling too, we shouldn't mention it in the wiki 16:30 <ddstreet> if the sponsor isn't aware of it, the email to them should clear it up 16:30 <ddstreet> ack the KB page does seem right for this detail 16:30 <ddstreet> i'll update that page with the info 16:31 <ddstreet> #action ddstreet update internal KB page with details about uploads going to 'New' instead of 'Unapproved' queue 16:31 * meetingology ddstreet update internal KB page with details about uploads going to 'New' instead of 'Unapproved' queue 16:31 <ddstreet> ok nothing else for discussion in the agenda 16:31 <ddstreet> #topic AOB 16:31 <ddstreet> anything else to bring up? 16:31 <ddstreet> should we have another mtg in 2 weeks? 16:32 <mapreri> yes pls 16:32 <ddstreet> #action ddstreet schedule next meeting 16:32 * meetingology ddstreet schedule next meeting 16:33 <ddstreet> ok anything else? 16:33 <ddstreet> let's wrap then! 16:33 <ddstreet> #endmeeting