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