=== genii is now known as genii-core [08:54] o/ [12:12] \o === genii-core is now known as genii [17:31] o/ [17:31] teward i got a decline from mapreri, so it may just be us today [17:43] ok well just me i guess :) [17:44] i'll at least run thru the mtg to clear out completed action items [17:44] #startmeeting Ubuntu Backporters [17:44] Meeting started at 17:44:20 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology [17:44] Available commands: action, commands, idea, info, link, nick [17:44] #topic previous action items [17:44] #subtopic ddstreet email ubuntu-devel list to announce re-opening of backports (carried over) [17:44] done! [17:45] #link https://lists.ubuntu.com/archives/ubuntu-devel/2022-February/041827.html [17:45] #subtopic ddstreet update internal KB page with details about uploads going to 'New' instead of 'Unapproved' queue (carried over) [17:45] done! [17:45] #link https://wiki.ubuntu.com/UbuntuBackports/KnowledgeBase#Upload_Queues [17:45] #subtopic ddstreet update tooling, requestbackport, backportpackage (carried over) [17:45] not done :( [17:45] #action ddstreet update tooling, requestbackport, backportpackage (carried over) [17:45] ACTION: ddstreet update tooling, requestbackport, backportpackage (carried over) [17:46] #subtopic ddstreet schedule next meeting at 12:30pm Eastern time, following USA DST schedule [17:46] done [17:46] #subtopic ddstreet make sure wiki page includes requirement to add LP:# tag in backport changelog [17:46] done [17:46] #link https://wiki.ubuntu.com/UbuntuBackports#Preparing_the_Backported_Package [17:46] #subtopic ddstreet start thread on ML to clarify wording for no-bug-required backports [17:46] #link https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022680.html [17:46] done [17:47] since nobody else is here, i'll just carryover the other action items [17:47] sorry i am late [17:47] hello! o/ [17:47] no problem [17:47] just going over previous items [17:47] was deep in a buggy software and fixing it [17:47] #action mapreri propose text for membership process to add to KB page (carried over) [17:47] ACTION: mapreri propose text for membership process to add to KB page (carried over) [17:47] #action mapreri upload (more of) all the tools (carried over, in progress) [17:47] ACTION: mapreri upload (more of) all the tools (carried over, in progress) [17:47] #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) [17:47] ACTION: mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over) [17:47] Debian bug 1001399 in lintian "lintian: adjust backports-upload-has-incorrect-version-number for ubuntu" [Normal, Open] [17:47] #action (unassigned) define details on handling members/leads who are no longer participating (carried over) [17:47] ACTION: (unassigned) define details on handling members/leads who are no longer participating (carried over) [17:48] #action (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [17:48] ACTION: (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over) [17:48] #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] 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] ok that's all the previous actions [17:48] #topic discussion [17:48] i have one item on the agenda [17:48] #subtopic I (ddstreet) would like to start a discussion on a non-participating member policy [17:48] ddstreet: given the other thing perhaps the no longer participating thing should be a TB decison [17:48] as a matter of policy [17:49] lol coincidence thats the topic now [17:49] mm, i'm 100% fine with the TB doing the actual member removal/addition/modification...but i'm not ok with the TB deciding membership policy for the team [17:49] i propose we come up with something to present to the TB for their ratification [17:50] so they can sign off, etc. but that way it gets proper review, etc. [17:50] i have no problem presenting our decision to the TB, and if they want to or need to ratify it, that's fine too [17:50] as far as i'm concerned, that step is simply an implementation detail [17:51] so i think we're in agreement on that particular part right? [17:51] just to confirm [17:52] teward you still there? [17:52] mmmmm... [17:52] ye typing from a phone ya impatient [17:53] ah ok [17:53] no hurry just checking :) [17:53] i think my issue is a lack of clarity overall from a policy perspective that is apparently present at all levels - namely does a team get to decide its own policies for removals of members etc. [17:54] can i suggest we carry over this action item and discussion to next meeting? i want to poke a few individuals first [17:54] get a general pulse on that core question [17:55] i have no issue starting a discussion on how we shoukd handle inactives but with that issue being a big one on a radar far higher than ours I want to get that issue clarified at a higher level first [17:55] since this team has only the 3 of us, and generally we have no problem at all currently with lack of participation, i'm ok deferring to the next meeting...but, i really would like to make progress on this item in that meeting [17:55] ok [17:56] i'll say that i am personally unconvinced that there can be a single policy that applies to all teams that covers what a 'non-participating member' is [17:56] and certainly not how to best handle the situation [17:56] but i think it's ok to give them 2 weeks to try to come up with a policy before we start on our own :) [17:56] o/ [17:57] #action ddstreet at next meeting, re-raise issue of non-participating member policy [17:57] ACTION: ddstreet at next meeting, re-raise issue of non-participating member policy [17:57] rbasak looks like you have something to add to the topic? [17:57] Something I was hoping to do was to ask the backporters team to ratify its responsibilities, as I had originally proposed in the ubuntu-devel@ thread during the backporter reboot discussion [17:57] That's slightly related to this topic. [17:58] Let me find a link [17:58] i was just gonna ask for a link lol [17:58] sure i'm all for that, i think best to put an action item for the next meeting and/or ML discussion [17:58] if that sounds ok to everyone [17:58] https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html, under "Team Responsibilities" [17:58] "Handle your own process reform and membership management..." [17:59] So that's done, and the TB ratifies, then you'd be handling your own membership management. [17:59] no disagreement from me. [17:59] if the TB ratifies that part i have no issues then [17:59] However, given what Steve raised with the DMB, that might need further discussion with the TB because maybe that wouldn't be acceptable to them. [18:00] So *if* that's done sorry [18:01] personally, i'd prefer to just assume we will get approval and make progress based on that assumption. if it turns out that assumption was wrong, things can be reevaluated later. i do not want to delay our own discussion and decision making however [18:01] OTOH, maybe this team will follow the pattern of some of the other teams (SRU, archive, release) in managing their own membership, unlike the DMB which is vote-based. [18:01] rbasak: on steves point DMB never had any say in SRU reviewers either and I think Backporters falls into that category [18:01] Yeah probably [18:01] of there is precedent to be handled independently of DMB entirely [18:02] So maybe best to proceed on the assumption that my "Team responsibilities" section would be ratified by both the TB and the backporters team? [18:02] just fyi, there is an existing action item that is assigned to mapreri to "propose text for membership process to add to KB page" [18:02] so clearly, the assumption so far as been that the team will decide its own membership process [18:03] the TB of course can clarify if that assumption is wrong, but i see no reason to change anything until that clarification is made from the TB [18:03] given the... other chaos... can we get the TB'S blessing on backporters managing our own members though?, [18:03] Anyway, I was intending to send an email to the backporters list asking if that text is something you'd be willing to ratify, and then take it up with the TB if the answer was yes. [18:03] But I was watching this meeting and on this topic that seemed relevant, so I thought it might be helpful to mention it now. [18:03] yes, i think it's best to carry the discussion of the specific text to ratify to the ML [18:04] agreed [18:04] ok i can throw up an action for that then, rbasak if you want to send the email i'll assign to you? :) [18:04] Assign me to send the email you mean? Sure. [18:05] #action rbasak send email to ML to clarify specific wording of team responsibilities, for proposal to TB for ratification [18:05] ACTION: rbasak send email to ML to clarify specific wording of team responsibilities, for proposal to TB for ratification [18:05] hopefully i worded that well enough :) [18:06] Yep, thanks [18:06] and i do still have the action added earlier to bring this topic back up next meeting, so we can review what's ahppend on the ML then [18:06] oh robie grab me aftet tbe [18:06] after the meeting [18:06] ok i think that topic is done for now, so aob [18:06] #topic AOB [18:06] anyhting else? [18:06] not from me [18:07] only thing i will mention is for members (teward ;-) to be sure to check the ML, i did send a couple emails to start discussion threads, e.g. no-bug backports, etc. [18:07] no hurry though :) [18:07] ok i think we're done then, thanks all! [18:07] #endmeeting [18:07] Meeting ended at 18:07:52 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-02-09-17.44.moin.txt