| === RikMills__ is now known as RikMills | ||
| === genii-core is now known as genii | ||
| didrocks | sarnold: hey, would you have few minutes after the MIR team meeting to discuss adsys vs security review on a HO? | 15:29 |
|---|---|---|
| sarnold | good morning | 15:31 |
| sarnold | didrocks: sure | 15:31 |
| didrocks | IIRC cpaelzer mentioned that he is on holidays this week? | 15:31 |
| slyon | o/ | 15:33 |
| slyon | I can try to run the meeting | 15:33 |
| didrocks | oh please, I was going to volunteered but multi-tasking meanwhile which isn’t the best to lead it :) | 15:34 |
| slyon | #startmeeting Weekly Main Inclusion Requests status | 15:34 |
| meetingology | Meeting started at 15:34:07 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 15:34 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 15:34 |
| slyon | #topic Review of previous action items | 15:34 |
| sarnold | aha :) thanks slyon | 15:34 |
| slyon | IIRC we did not have any open action items from last week, other than paelzer wanting to merge the latest github PR into the wiki | 15:35 |
| slyon | that's not yet done, but he's off that it's not critical, so let's postpone that | 15:35 |
| slyon | #topic current component mismatches | 15:35 |
| slyon | Mission: Identify required actions and spread the load among the teams | 15:35 |
| slyon | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 15:35 |
| slyon | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 15:35 |
| didrocks | nothing new/unknown from what I see? (libreoffice and others desktopy things -> I repinged to figure out if those are false positives now or not) | 15:36 |
| slyon | non-proposed looks pretty much normal to me | 15:36 |
| sarnold | libhandy-1 -> glade feels vaguely new to me | 15:37 |
| sarnold | but .. no scrollback :( | 15:37 |
| didrocks | it’s not, already dealt with last week | 15:37 |
| slyon | didrocks: I agree. I think we still need some comment about head->pythonv-vitrageclient->twitter-bootstrap3 from jamespage | 15:37 |
| didrocks | apparently fixed, but still on the list | 15:37 |
| didrocks | so I reopened and reasked seb128 to have a look if now this is a false positive or not | 15:37 |
| sarnold | cool, thanks | 15:37 |
| didrocks | context: https://bugs.launchpad.net/ubuntu/+source/glade/+bug/1961023/comments/2 | 15:37 |
| ubottu | Launchpad bug 1961023 in glade (Ubuntu) "[MIR] glade" [Undecided, Incomplete] | 15:37 |
| jamespage | you do - vitrageclient seems to be needed the other is a transient doc dependency AFAICT | 15:38 |
| slyon | thanks didrocks! | 15:38 |
| slyon | jamespage: what's the plan forward with vitrageclient? could you coordinate with your team to have the MIR created for that? | 15:39 |
| jamespage | yep | 15:39 |
| slyon | thank you! | 15:39 |
| slyon | moving on | 15:39 |
| slyon | #topic New MIRs | 15:39 |
| slyon | Mission: ensure to assign all incoming reviews for fast processing | 15:39 |
| slyon | #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir | 15:39 |
| sarnold | wireguard is recently acked by security team | 15:40 |
| sarnold | nftables is recently the start of the mir process by the security team | 15:41 |
| slyon | sarnold: alright. should we assign ubuntu-security to the nftables MIR then? | 15:41 |
| slyon | i think otherwise the status would be correct | 15:41 |
| sarnold | slyon: no, I think it needs MIR team review | 15:42 |
| slyon | ah! | 15:42 |
| slyon | do we have any volunteers to look into that? bug #1887187 | 15:42 |
| ubottu | Bug 1887187 in nftables (Ubuntu) "[MIR] nftables" [Critical, New] https://launchpad.net/bugs/1887187 | 15:42 |
| sarnold | I think the wireguard needs 'fix committed' status, but I'm not sure.. | 15:42 |
| didrocks | yeah, wireguard should be fix committed to me | 15:42 |
| sarnold | done | 15:43 |
| didrocks | nftables -> can’t commit this week, next is the sprint one… Afterwards, could be, but might be late? | 15:43 |
| slyon | thanks sarnold | 15:44 |
| slyon | joalif: would you be interested in the nftables MIR? otherwise I could have a look maybe by the end of this week | 15:44 |
| joalif | slyon I'm interested but cannot promise it'll be ready until next meeting | 15:45 |
| slyon | joalif: cool! Next meeting is sprint time, so I'm not sure if we'll have a meeting | 15:46 |
| joalif | ok I'll take it then | 15:46 |
| slyon | joalif: thank you! I can do the double-checking for you again. | 15:46 |
| joalif | :) | 15:46 |
| sarnold | \o/ thanks joalif, slyon :) | 15:47 |
| slyon | #topic Incomplete bugs / questions | 15:47 |
| slyon | Mission: Identify required actions and spread the load among the teams | 15:47 |
| slyon | #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir | 15:47 |
| slyon | libapache2-mod-auth-openidc is back to the reporter | 15:48 |
| slyon | rustc was updated by schopin and I think he coordinated with ubuntu-security that review can start in parallel, while he's investigating the armhf failures | 15:49 |
| slyon | plocate needs sponsoring, there's a debdiff available. Let me look at that, as nick is a fellow Foundations member | 15:50 |
| didrocks | tell me once you need it to be promoted | 15:51 |
| slyon | didrocks: thanks, will do! | 15:51 |
| slyon | v4l2-relayd: I did some review and comments on that, but the comments are not yet fully resolved. so still waiting on the reporter | 15:51 |
| slyon | suitesparse-graphblas is waiting for a response from seb | 15:52 |
| slyon | glade is a template bug that needs work from the desktop team | 15:52 |
| slyon | so nothing else to do here, I think | 15:52 |
| slyon | #topic MIR related Security Review Queue | 15:52 |
| slyon | Mission: Check on progress, do deadlines seem doable? | 15:52 |
| slyon | #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir | 15:52 |
| slyon | sarnold: got any good news for us, wrt. the security review backlog? | 15:53 |
| sarnold | ahh, I need to keep better notes, don't I .. sorry. we've acked wireguard, I've made pretty good progress on adsys and intend to ack it when finishing up the paperwork on it, I hope an issue I found during review won't be too much hassle to clear up | 15:54 |
| sarnold | python-asgiref is done | 15:54 |
| sarnold | python-cheroot we asked some questions but they've been left unanswered so far | 15:54 |
| sarnold | https://bugs.launchpad.net/ubuntu/+source/python-cheroot/+bug/1930111 | 15:54 |
| ubottu | Launchpad bug 1930111 in python-cheroot (Ubuntu) "[MIR] new dependencies of cherrypy3: jaraco.collections, jaraco.classes, jaraco.text, python-cheroot, python-jaraco.functools, python-tempora, python-portend, zc.lockfile" [Undecided, In Progress] | 15:54 |
| slyon | sarnold: thanks for the update! You've probably been in touch with the release team wrt. adsys, right? AFAIK it was/is needed for 20.04.4 | 15:56 |
| sarnold | here's python-asgiref https://bugs.launchpad.net/ubuntu/+source/python-asgiref/+bug/1953173 | 15:56 |
| ubottu | Launchpad bug 1953173 in python-asgiref (Ubuntu) "[MIR] python-asgiref" [Critical, In Progress] | 15:56 |
| sarnold | .. probably that bug also needs the status updated | 15:56 |
| didrocks | slyon: we discussed with them, it can stay unseeded anyway, so we can still be on time :) | 15:56 |
| slyon | nice | 15:57 |
| sarnold | slyon: well, I hope so -- sunday night I sent a message to sil2100 about it, but was on holiday yesterday, so I'm not sure if he saw it :) | 15:57 |
| slyon | sarnold: yes. he mentioned something about it in our standup | 15:57 |
| slyon | so should we update python-cheroot and python-asgiref to "Incomplete"? | 15:58 |
| slyon | and back to the reporter? | 15:58 |
| slyon | I will do that after the meeting. | 15:58 |
| slyon | #topic Any other business? | 15:58 |
| slyon | This meeting took longer that usual, sorry for that. | 15:59 |
| slyon | do we have anything else? | 15:59 |
| didrocks | nothing for me, and thanks slyon for hosting it! | 15:59 |
| sarnold | nothing for me, thanks slyon, all :) | 15:59 |
| joalif | thanks all o/ | 15:59 |
| sarnold | python-asgiref may be correct, I don't see anything in the mismatches svg that pulls it into main | 15:59 |
| slyon | ack sarnold | 16:00 |
| slyon | ok, thank you all! And we're just on time :) | 16:00 |
| slyon | #endmeeting | 16:00 |
| meetingology | Meeting ended at 16:00:12 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-02-22-15.34.moin.txt | 16:00 |
| ahasenack | hi guys, I missed the meeting, can this also be set to committed? https://bugs.launchpad.net/ubuntu/+source/libyang2/+bug/1958293 | 16:11 |
| ubottu | Launchpad bug 1958293 in libyang2 (Ubuntu) "[MIR]: libyang2" [Critical, In Progress] | 16:11 |
| ahasenack | I think it's done | 16:11 |
| ahasenack | and https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1951834 which depended on libyang2 being acked | 16:12 |
| ubottu | Launchpad bug 1951834 in frr (Ubuntu) "[MIR]: frr" [Critical, In Progress] | 16:12 |
| ahasenack | sarnold: ^ security was the last step? | 16:12 |
| ahasenack | or does it go back to MIR, who then decide if it's done or not? | 16:12 |
| slyon | ahasenack: we have MIR team ACK and security team ACK on libyang2, so that's done. It can be "In Progress" or "Fix Comitted" depending on the change that pulls it into main | 16:26 |
| slyon | ahasenack: Both those MIRs are "In Progress" (i.e. ready to be promoted). So you could do the seed change for frr and set both bugs to "Fix Committed" | 16:29 |
| ahasenack | ok, will do | 16:31 |
| ahasenack | I also forgot the seed change for wireguard | 16:31 |
| slyon | yes! wireguard is ready as well. | 16:32 |
| ahasenack | hoorray | 16:36 |
| ahasenack | just glusterfs now | 16:37 |
| === lifeless_ is now known as lifeless | ||
| * vorlon waves | 19:58 | |
| sil2100 | o/ | 19:59 |
| rbasak | o/ | 20:02 |
| sil2100 | hm, cyphermox seems to be absent again, sadly | 20:03 |
| sil2100 | rbasak: will you be able to chair today? | 20:04 |
| sil2100 | As one additional action item for today we probably need to discuss TB elections, right? | 20:05 |
| rbasak | I can chair, but probably best have a cochair to handle the DMB item | 20:05 |
| rbasak | #startmeeting Technical Board | 20:05 |
| meetingology | Meeting started at 20:05:41 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 20:05 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 20:05 |
| rbasak | #topic Action review | 20:06 |
| rbasak | ACTION: formal ratification of third party seeded snap security policy, depends on: (rbasak, 19:06) | 20:06 |
| rbasak | Let's discuss that in a separate topic | 20:06 |
| rbasak | ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. (rbasak, 19:06) | 20:06 |
| rbasak | Same as above? | 20:06 |
| rbasak | ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step (rbasak, 19:08) | 20:06 |
| sil2100 | Apologies... | 20:06 |
| rbasak | OK, carry over | 20:06 |
| rbasak | ACTION: Review and leave feedback on the first version of the preamble and three first requirements https://pad.ubuntu.com/third-party-repository-requirements (all of the TB) (sil2100, 20:09) | 20:06 |
| rbasak | In the next topic | 20:06 |
| rbasak | ACTION: Discuss DMB inactivity expiration policy (all of the TB) (sil2100, 20:27) | 20:07 |
| rbasak | We should have a separate topic later for that too. | 20:07 |
| rbasak | #topic Definition of our third party repository policy | 20:07 |
| rbasak | I requested feedback on my initial drafts in https://pad.ubuntu.com/third-party-repository-requirements | 20:07 |
| vorlon | rbasak: carry-over on my action | 20:07 |
| rbasak | OK, and for sil2100 too I guess | 20:08 |
| sil2100 | Yes, apologies for that, I didn't have too much time recently | 20:08 |
| rbasak | #topic Discuss DMB inactivity expiration policy (all of the TB) | 20:08 |
| rbasak | #chair vorlon | 20:09 |
| meetingology | Current chairs: rbasak, vorlon | 20:09 |
| rbasak | Speaking for myself and not as the chair, the DMB seems paralyzed on this currently. | 20:09 |
| rbasak | I'd appreciate getting it resolved quickly. | 20:09 |
| vorlon | right, so | 20:09 |
| rbasak | vorlon: did you manage to consult with non-DMB on the TB as you were seeking? | 20:09 |
| vorlon | I have not; the non-DMB members on the TB having been cyphermox who has unfortunately been inactive, and mdeslaur who has stepped down | 20:10 |
| vorlon | I have failed to reach out directly to cyphermox, which I can still do, but at the end of the day I think it's going to largely come down to us three again | 20:11 |
| vorlon | unless the three of us don't actually agree I guess :) | 20:11 |
| rbasak | OK, so how do you want to proceed? | 20:12 |
| vorlon | well, as a metapoint, I recognize the desire to have a quick resolution but I think it is not possible for there to be a quick removal of any current members of the DMB. Given my position that the DMB doesn't have the authority to set a policy for removing its own members, this has to go through TB discussion (which I've myself failed to move forward promptly), vote, and execution | 20:13 |
| vorlon | given this reality, how should this be managed with respect to the frustrations of the active members of the DMB | 20:14 |
| rbasak | I think the DMB's position that members who have been inactive for some time should be removed is in general completely reasonable. | 20:14 |
| vorlon | I agree | 20:15 |
| rbasak | If procedurally the DMB can't do this themselves, then sure, ask the TB to agree. | 20:15 |
| sil2100 | Same | 20:15 |
| vorlon | no disagreement with this principle. Only flagging the concern that I don't think we can actually put this in practice fast enough to address current DMB frustrations | 20:15 |
| rbasak | If the TB agrees (sounds like it does) then the question of procedure of who makes the decision shouldn't matter. We can decide it here and be done. | 20:16 |
| rbasak | A nuance is *how* the removal ought to be done. | 20:16 |
| vorlon | so you would like to move forward on a vote to remove specific members of the DMB for inactivity, without first formalizing a policy? | 20:16 |
| rbasak | But maybe we can make progress by agreeing that it should be done, and then worry about how? | 20:16 |
| rbasak | (we can decide how afterwards in this meeting too) | 20:16 |
| rbasak | vorlon: yes, if that sounds good to you and sil2100 | 20:17 |
| vorlon | ok | 20:17 |
| rbasak | But let's make it clear that it is pending further discussion on how to do it, which we will discuss shortly | 20:17 |
| sil2100 | You mean deciding on removal of individual inactive DMB members right now and later working on the actual policy, yes? | 20:18 |
| rbasak | When I say how I'm referring to my request that they be contacted privately first | 20:18 |
| rbasak | So I'm saying: 1) the TB agrees to remove the two (previously absent) members now. | 20:19 |
| rbasak | That will presumably need a vote. | 20:19 |
| rbasak | And it would be in principle only, because 2) the TB discusses how to approach doing this (in terms of whether to contact them privately first or not, and how long to wait after sending those emails before actually removing them from the LP team) | 20:20 |
| vorlon | of specific concern to me is Simon's statement that he wishes to continue to serve; if he is not actively participating in the work of the DMB but also not stepping back, that's not good. Wouldn't change my vote, just means a harder conversation. AIUI there would've been another DMB meeting since then, did he attend? | 20:20 |
| rbasak | He did not, and we were unable to reach quorum | 20:20 |
| sil2100 | I had hoped that he would after the e-mail he has sent | 20:21 |
| rbasak | IMHO, that ship has sailed, and it isn't sufficient just to reappear after missing so many meetings, including the discussions the DMB had about absentee members, and the vote the DMB had that passed. | 20:21 |
| sil2100 | But yeah | 20:21 |
| * vorlon nods | 20:21 | |
| sil2100 | I'm +1 on the plan that rbasak outlined | 20:22 |
| vorlon | yes, I'm fine with it | 20:22 |
| rbasak | #agreed The TB moves to remove the two absentee DMB members in principle, with the specifics yet to be agreed | 20:22 |
| meetingology | AGREED: The TB moves to remove the two absentee DMB members in principle, with the specifics yet to be agreed | 20:22 |
| rbasak | OK, so next, I requested that before the removal we privately contact the members to explain why they are being removed and thank them for their contributions. | 20:23 |
| vorlon | +1 | 20:23 |
| sil2100 | +1 | 20:24 |
| rbasak | And that this be done before sending out a call for nominations with the idea being that the members are not suprised to see the call for nominations for their own seats first. | 20:24 |
| rbasak | I suggested therefore to wait a minimum of a week after sending the emails before (removing them from the LP team and sending a call for nominations) | 20:25 |
| rbasak | However ddstreet objected very vocally to do this, and that's the point in contention for which this item got escalated to the TB in the first place. | 20:26 |
| vorlon | right | 20:26 |
| rbasak | Obviously I think we should do this anyway, and I've explained in the email thread why I think it's not appropriate to recuse myself. | 20:26 |
| vorlon | I am ok with a 1-week timeline. It's not clear to me that ddstreet will be, but OTOH 2 weeks have already passed since the escalation so that ship may have sailed | 20:26 |
| rbasak | So it's down to you two really. | 20:26 |
| vorlon | my apologies for having let this continue for yet another DMB meeting cycle | 20:27 |
| sil2100 | In principle I'm +1 with waiting a week, my earlier stance of not waiting was caused by the fact that the policy that we decided on did not require that | 20:28 |
| sil2100 | But since the policy is moot, because of what is mentioned above, I'm good with going with the 1 week approach now | 20:29 |
| vorlon | I don't feel strongly that there be any particular waiting period. I think the ordering matters (contacting them before a public call for nominations). | 20:30 |
| vorlon | and I don't think 1 week significantly changes the impact on the DMB in either direction, due to the realities of an election timeline | 20:31 |
| vorlon | so I am +1 | 20:31 |
| sil2100 | That being said, I'd like this to be resolved as soon as possible. So I'd even propose trying to contact the members that will be removed by means other than e-mail | 20:31 |
| sil2100 | (additionally to sending the e-mail) | 20:31 |
| vorlon | is this agreed then? | 20:34 |
| sil2100 | +1! | 20:36 |
| rbasak | OK great | 20:36 |
| rbasak | #agreed We will contact the members as best as we can, and wait a minimum of one week before removing them from the LP team and sending out a call for nominations | 20:37 |
| meetingology | AGREED: We will contact the members as best as we can, and wait a minimum of one week before removing them from the LP team and sending out a call for nominations | 20:37 |
| rbasak | FWIW, if we get an ack from both of them sooner, then I am happy to get moving sooner. I assume nobody will object to that. | 20:38 |
| rbasak | There are still some loose ends to tie up though. | 20:38 |
| rbasak | One member of the DMB resigned privately, and has removed themselves from the LP team. So there will be three seats up for election now, and the other four in May I think. | 20:39 |
| rbasak | I assume that's fine? Are we running one election, or two? | 20:39 |
| rbasak | What if, for example, we opened all seats for election in a week, and the top three would start immediately and the other four would start in May? That might save a bunch of admin. | 20:39 |
| vorlon | what if the top three are candidates who are standing for reelection | 20:40 |
| vorlon | doesn't help you any | 20:41 |
| rbasak | Good point. Pick the top three who are actually eligible then? | 20:41 |
| sil2100 | I would just aim for two elections | 20:41 |
| rbasak | OK fine | 20:41 |
| rbasak | Second, ddstreet did escalate a second issue to the TB wrt. my conduct | 20:41 |
| vorlon | btw we have agreement to contact the DMB members, who is taking the action | 20:42 |
| rbasak | I am happy to do it. | 20:42 |
| rbasak | I didn't before because I didn't think ddstreet would wait before sending a call for nominations, which he later confirmed. | 20:42 |
| rbasak | But now the TB has decided the way it will be done, I am happy to take the action. | 20:43 |
| rbasak | Are you both happy for me to take the action or would you prefer that I didn't? | 20:44 |
| vorlon | I think it's fine - just wanted to be clear about action assignment | 20:44 |
| rbasak | sil2100? | 20:45 |
| sil2100 | +1 | 20:45 |
| rbasak | #action rbasak will send out the private removal emails | 20:45 |
| meetingology | ACTION: rbasak will send out the private removal emails | 20:45 |
| rbasak | Also, who will run the election? | 20:45 |
| vorlon | in the past the DMB have run them | 20:45 |
| rbasak | So let the DMB decide for themselves? | 20:46 |
| vorlon | which I have no objection to, as I mentioned on list this is administrative work so I see no conflict of interest | 20:46 |
| vorlon | rbasak: what part of it is deciding? | 20:46 |
| rbasak | The actual person who does the admin work. | 20:46 |
| vorlon | yeah | 20:46 |
| rbasak | OK, so we'll leave that to the next DMB meeting then. | 20:46 |
| vorlon | I'm not worried someone elected to the DMB is going to rig the election in their favor | 20:46 |
| sil2100 | ;) | 20:47 |
| rbasak | So finally on this topic I think | 20:47 |
| rbasak | https://lists.ubuntu.com/archives/technical-board/2022-February/002607.html | 20:47 |
| rbasak | ddstreet said: " | 20:47 |
| rbasak | The bigger problem is that a single DMB member is able to block the | 20:47 |
| rbasak | team from following explicitly written policies because they do not | 20:47 |
| rbasak | agree with the policies. That is what I would ask the TB to clarify. I | 20:47 |
| rbasak | think it's unfortunate that we even need to state something like that | 20:47 |
| rbasak | in writing, but here we are." | 20:47 |
| rbasak | This relates to my conduct, so I think I must recuse myself from any TB decision. | 20:47 |
| vorlon | understood | 20:48 |
| vorlon | I'm unsure what clarification we can satisfactorily offer here | 20:48 |
| vorlon | I think there was a clear disagreement about the interpretation of a policy | 20:48 |
| rbasak | Speaking for myself personally, obviously I think that it's entirely appropriate that when we couldn't resolve a disagreement we escalated to the TB. That is IMHO the correct process and is even defined as such by the CoC. | 20:48 |
| vorlon | interpretation and application | 20:48 |
| sil2100 | So, I don't think any single person should be able to block anything - if a policy is defined and ratified correctly, then no one objection (if not part of the policy) should block anything | 20:49 |
| rbasak | I had a good faith disagreement on how to interpret the policy. | 20:49 |
| vorlon | and again, there's also the fundamental that the policy in question was out of order | 20:49 |
| sil2100 | Yeah, indeed | 20:50 |
| ddstreet | i will mention that there are 2 members of the TB that participated in the DMB policy discussion, and NEITHER brought up its invalidity during discussion | 20:51 |
| vorlon | ddstreet: hi | 20:51 |
| ddstreet | yello | 20:51 |
| sil2100 | ddstreet: hello! It never occured to me as I am quite 'fresh' to the TB, only vorlon actually noticed this fact | 20:51 |
| ddstreet | just pointing out that the invalidity of the policy is really irrelevant to the issue | 20:52 |
| sil2100 | This thought never occured to me before that indeed the DMB should not be the authoritative body | 20:52 |
| rbasak | I felt that the discussion was not permitted to proceed properly. It was rushed and was never brought to a meeting for discussion. | 20:52 |
| vorlon | fair; important from my perspective but irrelevant to the actual circumstances of blocking | 20:52 |
| rbasak | It did cross my mind that it probably needed to go to the TB, but I didn't think it mattered much because I didn't see the TB objecting, and I didn't want to block progress. | 20:52 |
| sil2100 | But in case where such a policy as we agreed on had been properly ratified, I would just follow the policy | 20:53 |
| rbasak | But, where your wording said that the members would be removed, I did assume that meant that we'd be asking the TB to do that removal. | 20:54 |
| rbasak | And therefore if the TB objected, they could do so at that time. | 20:54 |
| rbasak | I don't see how it could be interpreted any differently since LP ACLs do not allow a non-TB person to remove people from the team. | 20:54 |
| sil2100 | If the ratified policy did not mention any wait period or any e-mail to be sent beforehand, to me this is not a breach of CoC personally. The CoC "Be respectful" is very vague and can mean a lot, and I don't like making decisions on something that is not as much expicitly defined as possible | 20:55 |
| vorlon | ddstreet: so, I'm unsure how the TB can help with this. Personally, I value your service on the DMB. I'm unsure if I'm misinterpreting your email, which reads to me like an ultimatum that if the TB doesn't agree with you that it was wrong for rbasak to block things from moving forward on the timeline you sought, you would step back from the DMB. I can't agree with that; I do think this was a | 20:55 |
| vorlon | good-faith difference of interpretation of a policy, that escalating to the TB was reasonable under the circumstances | 20:55 |
| ddstreet | vorlon no I don't "require" you to agree with me - I just want the TB to address this; specifically, if a DMB member can block implementation of written policy | 20:56 |
| vorlon | and I do absolutely understand your frustration with absenteeism blocking the work | 20:56 |
| vorlon | ok | 20:56 |
| ddstreet | if the answer is 'yes they can' then I can work with that, but I can't work with 'who knows!' | 20:57 |
| vorlon | ok, thanks | 20:57 |
| ddstreet | and, if the answer is 'the DMB should decide this specific policy' that's fine with me, as well | 20:58 |
| ddstreet | ('this policy' being how/if exactly members can block policy implementation) | 20:58 |
| rbasak | IMHO, it should *always* be possible for any team in Ubuntu to escalate to leadership. Leadership can act quickly if the situation warrants (the need to do that is actually in the CoC) so that wouldn't really be blocking anything. And if leadership decides that the person was behaving in bad faith, then they can sanction that person. | 20:59 |
| vorlon | quick off-the-cuff wording of a draft statement, let me know whether this would address your concern: "in matters of disagreement within the DMB over the interpretation of a DMB-ratified policy, it is appropriate to escalate to the TB for a decision" | 20:59 |
| vorlon | to be clear, from my perspective it was also not rbasak's intention to block moving forward under the policy; there was disagreement about what moving forward looked like | 21:00 |
| sil2100 | rbasak: escalation, agreed. If someone objects with some policy it is the right thing to do. But until the policy is invalidated, I don't think an objection should block any policy from being executed, right? | 21:00 |
| sil2100 | Just want to make sure we all have the same baseline | 21:00 |
| ddstreet | well if you are *asking* me for my opinion, I think fortnightly meetings, at which some members don't always show up, can *really* cause delays in progress if things get 'official'. I'd much prefer *defaulting* to following the written policy, while at the same time leaving the option to any team member to escalate to the TB to reverse any decision | 21:01 |
| ddstreet | i.e. JFDI and the TB can revert if needed | 21:01 |
| rbasak | sil2100: I think it depends. If the objection is on the principle of preventing harm, then it's appropraite to wait for a leadership decision. And I think that applied here. | 21:01 |
| rbasak | You can't just revert removing someone, since the harm is social, not the membership of the team itself. | 21:01 |
| ddstreet | that's something that should be brought up during discussion of individual policies | 21:02 |
| rbasak | Also, in this case, it was about how the written policy was to be interpreted. You say you wanted to follow the policy, I say I wanted to follow the policy. But we were talking about two different things. | 21:02 |
| * ddstreet stops discussion this specific policy | 21:02 | |
| rbasak | For example, how exactly was a DMB member going to remove other DMB members from the LP team without asking a TB member to do it? | 21:02 |
| ddstreet | this isn't about this specific policy | 21:03 |
| rbasak | It's never too late to ask to prevent harm. | 21:03 |
| rbasak | If someone notices something harmful long after a policy was decided, it's not appropriate just to blindly follow the policy. | 21:03 |
| rbasak | Even if there were no question about its interpretation. | 21:03 |
| sil2100 | rbasak: so in my personal opinion the particular situation was not really harmful - since as I said, 'respect' is a very vague term, some actions might feel respectful for some, for others less. It's very open to interpretation. Though I do agree that contacting beforehand would be a good gesture | 21:05 |
| sil2100 | But yes, in the end the policy was not quite fully correct, as you mentioned with actually regulating the membership status (requiring the TB) | 21:05 |
| vorlon | right, so for the specific question ddstreet asked, narrowly described, can a single member of the DMB veto the application of the DMB's policies: no. But I don't think a 'no' answer to that question helps anything | 21:05 |
| sil2100 | So I think in the end we'd still be in this situation, as we'd have to go to the TB to actually execute the policy | 21:06 |
| ddstreet | possibly the DMB needs to figure out a more structured arrangement to its meetings and implementations of policy (which, as i said, is unfortunate that we need to go to) | 21:09 |
| ddstreet | i think my point is that, if the TB needs to arbitrate 100% of DMB disagreements, I'm not sure what the point of the DMB is at all | 21:09 |
| ddstreet | or i should say, what the point of having DMB rules/policies is | 21:09 |
| sil2100 | I think this was the first time where TB arbitration was required, right? Or did something similar happened before? | 21:10 |
| ddstreet | well, what i mean is that we spent ~1 month discussing the policy, then ~3 months waiting for the policy period, then at the point of implementation there was disagreement that needed escalation | 21:11 |
| ddstreet | so do the dmb 'policies' actually mean anything? | 21:12 |
| rbasak | I'll say again that we never properly discussed the policy. It was rushed through on the ML during a very busy time for regular applications. Normally the meetings aren't so busy. | 21:12 |
| rbasak | So as a result it was ill thought out. | 21:12 |
| sil2100 | I think it's good to have a third party help resolving conflicts or making sure policies are correct. Sometimes that's even necessary. I don't think disagreements like this should be blocking. | 21:13 |
| rbasak | If you don't want that to happen, I'll ask that you be patient, put things on the meeting agenda, and wait until we actually have time to discuss them properly. | 21:13 |
| vorlon | just a quick time check, we are 13 minutes over | 21:13 |
| rbasak | Then we'll have fewer disagreements about interpretation because we'll actually have had the opportunity to make sure we all understand the details. | 21:14 |
| vorlon | from my side I don't need to stop discussing, but I also want to make sure people feel discussing this now is the best continued use of time | 21:14 |
| ddstreet | i'm not on the TB, but IMHO i'd like to see an answer to 'are DMB policies valid, as written, until modified'? | 21:15 |
| sil2100 | I also understand ddstreet's frustration here, since I think the policy was proposed and I felt that we did discuss it to some extent. Maybe such a on-DMB-meeting discussion as proposed by rbasak could be helpful, but we know how things look with the DMB attendance | 21:15 |
| ddstreet | from my perspective: I spent way too much time pedantically writing, proposing, and discussing this policy, then finally gathering votes for it, adding it to the DMB KB, waiting 3 months, and then finally at the time of implementation, rbasak decided we should not follow its specific wording. | 21:17 |
| ddstreet | if that seems ok, then ok. if not, maybe clarify things. | 21:17 |
| vorlon | ddstreet: I feel I can say "yes" to that question as posed, but that this again doesn't help you? Because the disagreement was about the part that wasn't written when it came time to implement | 21:17 |
| rbasak | from my perspective: I appreciated ddstreet working on driving this until he suddenly got impatient and rushed it through, and then tripped up when it later turned out that ddstreet's interpretation of what he wrote didn't match rbasak's interpration of what he wrote. | 21:18 |
| sil2100 | (apologies everyone, but I have to drop now - I think my opinion is known on this topic already, if anything!) | 21:18 |
| vorlon | thanks sil2100 | 21:19 |
| ddstreet | just for clarification - and again, i wish we weren't focusing on this specific policy - here is the policy as i wrote in the KB https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Board_Member_Attendance | 21:19 |
| ddstreet | I didn't think I could be *more* pedantic in the wording, but clearly I could have ;-) | 21:19 |
| rbasak | I don't think I've got anything else to add. | 21:20 |
| rbasak | I also don't see how the current thread of discussion is helpful. I don't see what ddstreet is trying to achieve by posing tautological questions. | 21:20 |
| vorlon | I don't think ddstreet is being deliberately tautological but I also am uncertain how to move things forward satisfactorily from here | 21:21 |
| rbasak | Teams can set their own policies. That's a given. Ubuntu has paths for escalation when there's a disagreement. That's also a given. | 21:22 |
| vorlon | because it still seems to be a difference of framing | 21:22 |
| rbasak | That is the structure in which we operate. | 21:22 |
| ddstreet | what i would like is some clear (in whatever meaning 'clear' might have) definition of what objections to written policies could possibly block policy implementation while escalated to the TB | 21:22 |
| rbasak | Either this is acceptable to ddstreet or it is not, but that's how it is. | 21:22 |
| ddstreet | if the answer to that is 'anything' then, ok | 21:22 |
| vorlon | well, yes, from my perspective the answer is 'anything' | 21:23 |
| rbasak | My understanding is that leadership teams in Ubuntu can override everything. | 21:23 |
| vorlon | I don't think we can draft a meta-policy that applies here | 21:23 |
| rbasak | (that is within their scope) | 21:23 |
| vorlon | exceptions are exceptional | 21:23 |
| rbasak | It's also a principle of leadership to try not to interfere. | 21:24 |
| rbasak | But obviously they have to, to some extent, if something is escalated to them. | 21:24 |
| rbasak | My approach on the TB in dealing with other matters is to try as hard as possible to interfere as little as possible. | 21:24 |
| rbasak | And that's it really. Everything else is case-by-case. | 21:25 |
| ddstreet | more specifically what i mean is, can a team member object to ANYTHING for ANY REASON and block its implementation until the TB resolves the dispute? Or, are there any cases where the implementation proceeds? Obviously, the TB can revert *any* decision | 21:25 |
| ddstreet | though the TB can't undo side-effects from implementations | 21:25 |
| rbasak | I think the answer should be Yes. | 21:25 |
| vorlon | yes, though like mushrooms being edible, it may be something an individual member can only do once | 21:26 |
| sarnold | lol | 21:26 |
| ddstreet | oh you can definitely do that multiple times | 21:26 |
| vorlon | i.e. if it's egregiously in bad faith (which I assert was not the case here), there may be consequences | 21:26 |
| rbasak | The TB doesn't need to fully resolve a dispute before making some kind of interim decision, FWIW. | 21:27 |
| rbasak | So something could be escalated, and the TB might say "proceed for now because it won't do any harm while we deal with some of the details" | 21:27 |
| rbasak | It's also not really possible to make someone stop doing something, if that's what you're asking. | 21:28 |
| rbasak | Like I couldn't stop you from sending a call for nominations. | 21:28 |
| rbasak | I live too far away for that :) | 21:28 |
| rbasak | But then whether that was a reasonable thing to do or not would be for the later judgement of the TB | 21:29 |
| rbasak | Since we're talking generally, I'd expect parties to a dispute to try and act in good faith, do the thing that causes/results in the least harm, and leave it for leadership to decide how to proceed. | 21:30 |
| rbasak | That may mean proceeding with something, or not proceeding with it, depending. | 21:30 |
| rbasak | If there's a disagreement about what would cause the least harm, try to respect each other and figure it out? | 21:31 |
| rbasak | We're at 90 minutes now | 21:33 |
| rbasak | And I'm hungry | 21:33 |
| rbasak | Where are we now? ddstreet, what more do you want from this topic? | 21:33 |
| ddstreet | if everyone is just continuing this for my benefit, please feel free to close :) | 21:33 |
| rbasak | Close this topic for now, or close the escalation you raised? | 21:34 |
| ddstreet | re: absent member resolution, that's already been decided i think | 21:35 |
| ddstreet | re: general DMB policy process, yeah don't worry about me :) | 21:35 |
| rbasak | OK thanks | 21:35 |
| rbasak | #topic Scan the mailing list archive for anything we missed (standing item) | 21:36 |
| rbasak | We need to organise an election following mdeslaur's resignication | 21:36 |
| rbasak | resignation | 21:36 |
| rbasak | Maybe given the time, we leave that for this week? | 21:37 |
| vorlon | yeah I'm tapped out, sorry | 21:37 |
| rbasak | I don't see anything else recent | 21:37 |
| rbasak | Dimitri continued the ~ubuntu-archive thread but I'm don't think there's a TB action there. | 21:37 |
| rbasak | #topic Check up on community bugs (standing item) | 21:38 |
| rbasak | I don't see anything. | 21:38 |
| rbasak | #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) | 21:38 |
| rbasak | #info Next chair will be cyphermox with vorlon as backup | 21:38 |
| rbasak | #topic | 21:38 |
| rbasak | #topic AOB | 21:38 |
| rbasak | AOB? | 21:38 |
| vorlon | nothing from me | 21:38 |
| rbasak | #endmeeting | 21:39 |
| meetingology | Meeting ended at 21:39:01 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-02-22-20.05.moin.txt | 21:39 |
| vorlon | rbasak, sil2100, ddstreet: thanks | 21:39 |
| xnox | rbasak: indeed no action; i think it is simply ongoing thing to incrementally improve. | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
