[17:29] <mapreri> ddstreet, teward: you here?
[17:29] <ddstreet> yep o/
[17:29] <teward> *flops in*
[17:30] <mapreri> whoa
[17:30] <mapreri> I love when people appear at meetings right on time ^^
[17:30] <teward> *yawns*
[17:30] <mapreri> can't be so early there, can it?
[17:31] <mapreri> FYI, I want to discuss with you 2 proposed bpos in the AOBs
[17:31] <ddstreet> teward aren't you in my TZ? it's after noon here! xD
[17:31] <ddstreet> we're all here, lets get started i suppose
[17:32] <ddstreet> #startmeeting Ubuntu Backports Team
[17:32] <meetingology> Meeting started at 17:32:11 UTC.  The chair is ddstreet.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[17:32] <meetingology> Available commands: action, commands, idea, info, link, nick
[17:32] <ddstreet> #topic previous action items
[17:32] <ddstreet> #subtopic ddstreet update tooling, requestbackport, backportpackage (carried over)
[17:33] <ddstreet> carrying this over
[17:33] <ddstreet> #action ddstreet update tooling, requestbackport, backportpackage (carried over)
[17:33] <meetingology> ACTION: ddstreet update tooling, requestbackport, backportpackage (carried over)
[17:33] <ddstreet> #action ddstreet draft a team charter for discussion
[17:33] <meetingology> ACTION: ddstreet draft a team charter for discussion
[17:33] <ddstreet> done, let's discuss this later tho, after the previous actions
[17:33] <mapreri> k
[17:33] <ddstreet> #action ddstreet raise issue of non-participating member policy
[17:33] <meetingology> ACTION: ddstreet raise issue of non-participating member policy
[17:34] <ddstreet> i think this is wrapped into the charter, so lets continue
[17:34] <mapreri> wait
[17:34] <ddstreet> ah ok
[17:34] <mapreri> as a "policy" do you think it would be useful to code what "non-participating" means?  like, skipping X meetings or not writing to the ML/bugs for X months, etc?
[17:35] <mapreri> or should we just leave it to our feeling as I mentioned via mail?
[17:35] <mapreri> also, should we code what to do when we think somebody is "non-participating"?  like writing him a mail saying so before voting on it, or so?
[17:35] <ddstreet> yeah we should work it out
[17:35] <mapreri> .
[17:36] <mapreri> in that case, let's do that once the charter is completed, in the separate policy page you recommended writing, I suppose.
[17:36] <ddstreet> on one hand, i'd like to think that the participating members would be able to figure out who isn't participating and follow up with them and then appropriately remove them
[17:37] <mapreri> that's what I feel, however that proves very awkward in debian (as I'm in the MIA team, I know the feeling…)
[17:37] <ddstreet> but...on the other hand, if that process is ambiguous, i've seen years go by with non-participating members
[17:37] <mapreri> yes, I'd like to see some clear line marked myself
[17:37] <ddstreet> yep i agree
[17:37] <mapreri> at least a line where we say "hey do something NOW or else.."
[17:37] <ddstreet> but, it should be separate from the charter, right?
[17:37] <mapreri> yes
[17:38] <ddstreet> ok yeah
[17:38] <mapreri> so it's not "i think this is wrapped into the charter,"
[17:38] <mapreri> :)
[17:39] <ddstreet> so lets' discuss the charter in more detail after the previous items, but re: this point, we should probably create a specific wiki page for 'policies'?
[17:39] <ddstreet> and keep all 'official' team policies in one place?
[17:39] <mapreri> didn't you already recommend so in the mail?
[17:39] <mapreri> I wonder how many policies we want
[17:39] <ddstreet> in the charter, the wording is that team polciies are 'in or linked from' the public docs, and the 'public docs' is the main backports wiki page
[17:40] <ddstreet> *hopefully* we need very few official policies
[17:40] <mapreri> but yes, this kind of thing should be written, but it doesn't fit the charter, so a separate page it is, that i like it or not :3
[17:40] <ddstreet> ok let's put an action for me to update the charter with that, and create a draft 'policies' wiki page
[17:41] <ddstreet> and i think the draft 'membership' page should move into the 'policies' wiki page?
[17:41] <ddstreet> so all our 'policies' are together?
[17:41] <mapreri> i'm not fussy about the naming
[17:41] <ddstreet> ack
[17:41] <mapreri> it's a membership policy, so it can be either way
[17:41] <ddstreet> #action ddstreet update draft charter to point to team policies at single wiki page, create draft wiki page for team policies
[17:41] <meetingology> ACTION: ddstreet update draft charter to point to team policies at single wiki page, create draft wiki page for team policies
[17:42] <mapreri> ♥
[17:42] <ddstreet> #subtopic ddstreet update agenda page with ML review topic item
[17:42] <ddstreet> done
[17:42] <ddstreet> #subtopic ddstreet update agenda page with open bug review topic item
[17:42] <ddstreet> done
[17:43] <ddstreet> #subtopic mapreri propose text for membership process to add to KB page (carried over)
[17:43] <mapreri> well, I guess this is superseded now
[17:43] <ddstreet> i think this is included in the charter discussion
[17:43] <ddstreet> yep
[17:43] <mapreri> thx for basically taking it over
[17:43] <ddstreet> lol np, i was motivated by...things... ;-)
[17:43] <ddstreet> #subtopic mapreri upload (more of) all the tools (carried over, in progress)
[17:44] <mapreri> carryover yep
[17:44] <ddstreet> #action mapreri upload (more of) all the tools (carried over, in progress)
[17:44] <meetingology> ACTION: mapreri upload (more of) all the tools (carried over, in progress)
[17:44] <mapreri> work took me over these few weeks :s
[17:44] <ddstreet> #subtopic mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[17:45] <mapreri> yeah, I chatted with lechner (lintian maint) but got nowhere, I have trouble following his mind sometime...  he is complaining about what for me is fictional troubles
[17:45] <mapreri> I'll try again when I'm less stressed
[17:45] <ddstreet> ack, lol :)
[17:45] <ddstreet> #subtopic mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[17:45] <ddstreet> ugh
[17:45] <ddstreet> #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[17:45] <meetingology> ACTION: mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[17:45] <ddstreet> #subtopic (unassigned) review delegation email on ML
[17:46] <ddstreet> this is in the new ML section too, but i think this is superceded by the charter?
[17:46] <mapreri> I think it should just stay there until we vote on our charter, then tell robie to take that charter and have the tb vote on it?
[17:46] <ddstreet> ack
[17:46] <mapreri> it's not superseded, it's like the final step of it, i think?
[17:47] <ddstreet> yes right, the TB ratification should definitely be the final step, of whatever we have - charter or the delegation email content
[17:47] <ddstreet> #action (unassigned) review delegation email on ML
[17:47] <meetingology> ACTION: (unassigned) review delegation email on ML
[17:47] <ddstreet> #subtopic (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
[17:47] <ddstreet> i'll carry this
[17:48] <ddstreet> well, i won't carry it...it will be carried :)
[17:48] <mapreri> lol
[17:48] <ddstreet> #action (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
[17:48] <meetingology> ACTION: (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
[17:48] <ddstreet> #subtopic (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over)
[17:48] <ddstreet> carry this as well i think
[17:48] <mapreri> ya
[17:48] <ddstreet> #action (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over)
[17:48] <meetingology> ACTION: (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over)
[17:48] <ddstreet> #subtopic (unassigned) reminder to review 'no-bug-required' backport exception email thread on ML
[17:48] <mapreri> oh
[17:48] <ddstreet> let's drop this action since it's in the 'open ml thread' section too
[17:49] <ddstreet> but we should still follow up on this on the ML, of course
[17:49] <mapreri> that dropped from my mind, it got buried in my todo
[17:49] <mapreri> thanks for the reminder, i guess
[17:49] <ddstreet> lol
[17:49] <ddstreet> ok that's all the previous action items
[17:49] <mapreri> it didn't fall out of my inbox, so it wasn't lost, but totally buried yes
[17:49] <ddstreet> should we move on to the ML threads? anyone want to discuss any previous actions first?
[17:50] <ddstreet> (besides the charter)
[17:50] <mapreri> i think besides the charter i don't have anything to discuss
[17:50] <ddstreet> #topic open mailing list threads
[17:50] <ddstreet> #subtopic clarification on specific wording for no-bug-required backport exceptions
[17:51] <ddstreet> gonna carry this one, just a reminder for us to look at it on the ML
[17:51] <mapreri> yeah, I don't have the topic in my mind atm, sorry
[17:51] <ddstreet> #action (ML) clarification on specific wording for no-bug-required backport exceptions
[17:51] <mapreri> would just lose time right now
[17:51] <meetingology> ACTION: (ML) clarification on specific wording for no-bug-required backport exceptions
[17:51] <ddstreet> yep, same for me...been consumed with the charter stuff and didn't get to everything else
[17:51] <ddstreet> #subtopic Ratifying a formal delegation
[17:51] <ddstreet> same here, as discussed earlier
[17:52] <ddstreet> #action (ML) Ratifying a formal delegation
[17:52] <meetingology> ACTION: (ML) Ratifying a formal delegation
[17:52] <ddstreet> #subtopic team charter
[17:52] <ddstreet> ok here is it
[17:52] <ddstreet> #link https://lists.ubuntu.com/archives/ubuntu-backports/2022-March/022719.html
[17:52] <ddstreet> :)
[17:52] <ddstreet> mapreri fyi i did just reply to your last reply minutes before the mtg
[17:52] <mapreri> yeah, I was reading it while chatting here
[17:52] <ddstreet> #link https://wiki.ubuntu.com/UbuntuBackports/Charter
[17:53] <mapreri> I think generally, both me and teward agreed with pretty much everything, roughly?
[17:53] <teward> yep as long as we clarify membership requirements either in charter or out of charter
[17:54] <ddstreet> ack, and that should be covered by the 'policies' wiki page action
[17:54] <mapreri> so you think very very strict requirements that really shouldn't change easily (like the team requirement) don't need to be within the charter?
[17:56] <mapreri> because in mind I'd like those things there.  then more details like ("has provided at least X bpo uploads before applying" or similar) is the kind of thing to go outside of the charter, in the policies
[17:56] <ddstreet> personally, no...my feeling is, we're already going to vote on whoever gets into the team, right? so why do we need the TB to decide specific qualifications?
[17:57] <mapreri> It looks like both of you think so, so I suppose that'll be fine :)
[17:57] <teward> TB can always override us by governance
[17:57] <teward> so :P
[17:58] <mapreri> right
[17:58] <ddstreet> mapreri if you feel strongly, i'm not strongly opposed to putting it in the charter
[17:59] <ddstreet> but i feel like it's more than is needed - if our team members are trusted to vote on new members, we should also be capable of voting to adjust candidate qualifications, right?
[17:59] <ddstreet> and for sure as teward said, the TB can undo anything we break :)
[17:59] <mapreri> I don't feel strong about *that* specific point, nope
[18:00] <ddstreet> ok so let's keep the membership qualifications in the team policies wiki then, yeah?
[18:00] <mapreri> I suppose so.  sometimes I just think it can be better to bind my/ourselves with rules that are harder to break, but…. looks like this is not the case here
[18:01] <ddstreet> besides the action to set up the team policy wiki page and point the charter at it, anything else in the charter we should discuss or change?
[18:01] <ddstreet> if not i can update the wiki after the mtg and send out a ML email for review before we send it to the TB
[18:02] <mapreri> since we're moving requirements out of the doc, the sru-dev thing is also out of scope now (and i'll follow up via ml anyway)
[18:02] <ddstreet> ack
[18:02] <ddstreet> ok moving on
[18:02] <mapreri> Please update it yes, I don't think there is anything that bothers me after it.  I'd like to read it a couple of more times before we vote, however
[18:02] <mapreri> just send a note after the next refresh ^^
[18:02] <ddstreet> yep for sure
[18:02] <ddstreet> lemme action that just to be sure
[18:03] <ddstreet> #action ddstreet send ML email after updating charter
[18:03] <meetingology> ACTION: ddstreet send ML email after updating charter
[18:03] <ddstreet> #topic open bugs
[18:03] <ddstreet> #subtopic update backportpackage and requestbackport scripts to behave according to new backport process
[18:03] <ddstreet> i think this is a carry-over
[18:03] <mapreri> isn't thi covered by an above action already?
[18:03] <mapreri> de-dup the agenda? :P
[18:04] <ddstreet> yeah, we probably don't need to track it here
[18:04] <ddstreet> i suppose this section is better served by tracking actual backport bugs
[18:04] <ddstreet> :)
[18:04] <mapreri> but I suppose I can take here about my 2 bpo bugs
[18:04] <ddstreet> sure go for it
[18:05] <mapreri> my Q is about LP#1962743 and LP#1962614 (disclosure, they are from an italian dev that hangs out in the italian channel and as such bothered to me privately…)
[18:06] <mapreri> in particular about memtest, I'm less concerned about freeipmi.  anyhow, my point is: the "pushing reason" behind both of those request is to fix actual bugs in focal.
[18:06] <ddstreet> this is similar to my ML thread about systemtap
[18:07] <mapreri> I'm aware that both packages carry new features that as such deserve to be backported, but the maintainer (that's a new maintainer in debian that took over) is basically telling me that he doesn't want to spend time figuring out patches or so for them to fix the bugs in focal.
[18:07] <ddstreet> i totally agree with your rejection of it - backports shouldn't be used as a 'easier' bug fix pocket
[18:08] <mapreri> (the freeipmi one is extra-annoying because it was clearly caused by canonical applying a patch (for a customer?) in bionic, then the patch got dropped, so focal regressed, and now jammy is fixed because the patch is upstream finally)
[18:08] <mapreri> I feel bad just rejecting them outright, however, because they do provide value.
[18:08] <ddstreet> lol that freeipmi definitely sounds like it should be sru'ed
[18:09] <ddstreet> yep i feel the same
[18:09] <mapreri> and I'm positive that those bugs won't be SRUd anytime soon, especially for memtest, where it got a big leap in the upstream version.
[18:10] <ddstreet> agreed
[18:10] <ddstreet> i don't know what the right thing to do is
[18:10] <mapreri> so basically I'm asking to provide your own opinion on what to do for those 2 bugs.  probably something you shouldn't decide right now, but after looking a bit in the next days?
[18:10] <ddstreet> +1
[18:10] <mapreri> and I suspect try to come up with some kind of vague "guidance" for similar cases, maybe?
[18:10] <ddstreet> yep
[18:11] <ddstreet> and once we have that, we should likely update the docs to clarify for uploaders
[18:11] <mapreri> teward: ↑ if you could give us your opinion too on these 2 bugs in the coming days, that would be most appreciated
[18:11] <mapreri> (by us, I won't speak for the uploader :P)
[18:11] <teward> sorry i keep getting pulled off for work
[18:12] <teward> which two, ipmi and memtest?
[18:12] <mapreri> yep
[18:12]  * mapreri wonder how did he trigger "surge protection" on wiki.u.c
[18:12] <teward> i'll have to review them.  i can't guarantee today but yes I can review and give my opinion in the next few days
[18:12] <ddstreet> i'll add action in the bugs section so we at least can follow up on them next mtg
[18:12] <teward> mapreri: not sure if you saw #canonical-sysadmin but they've been migrating today
[18:12] <teward> so it might be a fluke
[18:13] <mapreri> ddstreet: istr I left some "empty paragraph" in the main wiki page specifically for after we figure these kind of cases.
[18:13] <cjwatson> Yeah, there was a problem around surge protection earlier today related to the wiki migration
[18:13] <mapreri> teward: haven't read the backlog there, nope
[18:13] <teward> *points at cjwatson's message*
[18:13] <mapreri> teward: next few days is fine, nothing urgent
[18:13] <mapreri> cjwatson: ack, thanks
[18:13] <ddstreet> #action (BUGS) LP#1962743
[18:13] <meetingology> ACTION: (BUGS) LP#1962743
[18:13] <ddstreet> #action (BUGS)  LP#1962614
[18:13] <meetingology> ACTION: (BUGS)  LP#1962614
[18:14] <ddstreet> ok i think that's all the bugs, at least in the agenda list
[18:14] <ddstreet> #subtopic AOB
[18:15] <ddstreet> ok AOB, anything else?
[18:15] <mapreri> I think the other bugs currently are fine, yes
[18:15] <mapreri> mh, no more aob from me
[18:15] <ddstreet> i hope once we get the administrative stuff e.g. charter, etc done, these mtgs will be shorter
[18:16] <ddstreet> oh i suppose i should mention, our agenda currently lists our mtgs as 'as needed', but we probably should just admit they are fortnightly :)
[18:16] <ddstreet> ok with both of you?
[18:16] <mapreri> I think as the charter says we should aim to ditch them and make them quarterly (unless "a member calls for one"?)
[18:16] <mapreri> like, really
[18:16] <mapreri> I don't want to do meetings /o\
[18:17] <ddstreet> hey i am *all* for that!
[18:17] <mapreri> although I appreciate chatting with fellow devs
[18:17] <ddstreet> so should we just decide now to set them for quarterly?
[18:17] <mapreri> keep the "as needed" as a sign for an idealistic dream?
[18:17] <ddstreet> lol
[18:17] <ddstreet> ack that works for me :)
[18:17] <mapreri> let's decide on that at some future point :)
[18:17] <ddstreet> we'll get to that 'as needed' one day! xD
[18:17] <ddstreet> yep
[18:18] <ddstreet> ok leaving that as is
[18:18] <ddstreet> nothing else from me
[18:18] <mapreri> aye
[18:18] <ddstreet> ok thanks mapreri teward !!!!!
[18:18] <ddstreet> #endmeeting
[18:18] <meetingology> Meeting ended at 18:18:43 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-03-09-17.32.moin.txt
[18:18] <mapreri> o/ thank yo uboth
[18:18] <teward> o/
[18:18] <ddstreet> o/
[18:18] <teward> *goes back to beating his head against an Exchange server*