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 ddstreet update tooling, requestbackport, backportpackage (carried over)
17:33 <ddstreet> #action ddstreet draft a team charter for discussion
17:33 * meetingology 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 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 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 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:44 <ubottu> Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open]
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 mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
17:45 <ubottu> Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open]
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 (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 (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 (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 (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 (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 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:05 <ubottu> Launchpad bug 1962743 in freeipmi (Ubuntu Focal) "[BPO] freeipmi/1.6.9-2 from Jammy to Focal" [Undecided, Confirmed] https://launchpad.net/bugs/1962743
18:05 <ubottu> Launchpad bug 1962614 in memtest86+ (Ubuntu) "[BPO] memtest86+/5.31b+dfsg-4  from Jammy to Focal" [Undecided, Incomplete] https://launchpad.net/bugs/1962614
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 (BUGS) LP#1962743
18:13 <ubottu> Launchpad bug 1962743 in freeipmi (Ubuntu Focal) "[BPO] freeipmi/1.6.9-2 from Jammy to Focal" [Undecided, Confirmed] https://launchpad.net/bugs/1962743
18:13 <ddstreet> #action (BUGS)  LP#1962614
18:13 * meetingology (BUGS)  LP#1962614
18:13 <ubottu> Launchpad bug 1962614 in memtest86+ (Ubuntu) "[BPO] memtest86+/5.31b+dfsg-4  from Jammy to Focal" [Undecided, Incomplete] https://launchpad.net/bugs/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