=== JanC_ is now known as JanC
sarnoldgood morning14:32
didrocksok, I think this is only us, let me lead the meeting14:33
didrocks#startmeeting Weekly Main Inclusion Requests status14:34
meetingologyMeeting started at 14:34:24 UTC.  The chair is didrocks.  Information about MeetBot at https://wiki.ubuntu.com/meetingology14:34
didrocksPing for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )14:34
meetingologyAvailable commands: action, commands, idea, info, link, nick14:34
didrocks#topic current component mismatches14:34
didrocksMission: Identify required actions and spread the load among the teams14:34
didrocks#link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg14:34
didrocks#link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg14:34
didrocksc-m-p: I don’t see anything new, the whole mm/pp stack is in discussion with the desktop team14:34
didrocksc-m: all good too, nothing to add14:35
didrocks#topic New MIRs14:35
didrocksMission: ensure to assign all incoming reviews for fast processing14:35
didrocks#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-mir14:35
didrocksthe status is incorrect on all of them14:36
didrocksjbicha: please, look at https://github.com/canonical/ubuntu-mir for the correct status, it should be New once ready for review14:36
sarnoldis it? the process states section has "new/confirmed" even on step 114:36
didrocksoh, I still had the old wiki version in mind :)14:37
jbichaIn this case, I specifically chose Confirmed, but LP automatically upgrades bugs to Confirmed if someone clicks "this affects me" :/14:37
didrocksah, that was maybe why it was changed to it14:37
didrocksok, my bad then :)14:37
didrockssorry for the false ping14:38
didrocksok, so we need to split them14:38
didrocksbut as I’m the only non security member here, I think nobody else can take any other?14:38
didrocksand I don’t want to assign for joalif or jamespage with them being away14:39
jbichathe 5 packages are fairly similar to each other14:39
didrocksI can take a second for the next pulse but can’t act more, I already have one14:39
sarnoldyeah, at this point it's probably just a question of "how many does didrocks want?" :)14:39
didrockssarnold: we agreed with management to take 2 by pulse14:40
didrocksthis pulse was already full, so next pulse, I already have 114:40
didrocks+ another one14:40
sarnoldsounds like the start of the cycle, indeed14:40
didrocksbut it means I can’t take anymore for the next 2 pulses14:40
didrockssorry 2 weeks*14:40
didrocksso meh, let’s do that, and maybe that will convince people to add more people to the MIR team :)14:41
didrocksI think libglibmm is the one making more sense, isn’t it jbicha?14:41
jbichathat's fine with me to start there14:41
jbichaoh it actually depends on libsigc++-3.0 though14:42
didrocksjbicha: I see that most of them have a bunch of lintian warnings, some could be fixed if we are working on debian, is it the case?14:42
jbichalibsig actually has a symbols file already :)14:42
jbichamy opinion is that the lintian warnings are harmless, but yes I can fix things in Debian if needed14:43
didrocksjbicha: at worst with lintian override? that way, you get a clean list, and when a new one is introduced, you will notice it rather than being list in the existing list14:43
didrocksok, taking libsigc++ first14:43
didrocksif joalif or jamespage reads afterwards, please, take one on the list ^14:44
didrocks#topic Incomplete bugs / questions14:45
didrocksMission: Identify required actions and spread the load among the teams14:45
didrocks#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-mir14:45
jbichasarnold: I try to ignore m4 files14:45
sarnoldjbicha: ahh, apparently, as did I, I saw the 'x86_64-linux-gnu' and assumed it was an .so :)14:45
didrocksok, on the incomplete list, only tagging and other in progress comments as far as I can see14:46
didrockslet’s move on14:46
sarnoldduktape assigned to band_ali, probably for todos?14:46
sarnoldand cargo, similar, tagged14:46
didrocks#topic Process/Documentation improvements14:46
didrocksMission: Review pending process/documentation pull-requests or issues14:46
didrocks#link https://github.com/canonical/ubuntu-mir/pulls14:46
didrocks#link https://github.com/canonical/ubuntu-mir/issues14:46
didrocksunsure I will have time to go to your PR dviererbe this week, but nice to see this work!14:47
dviererbeNo problem :)14:47
didrocksI think for typos, an approval from a peer is enough to merge14:48
sarnoldooo is there an easy way to see the rendered flowchart?14:48
dviererbeJust go to my repo14:48
sarnolddviererbe: ah!14:48
didrocksthat’s nice, I didn’t know that was rendered by GH!14:48
dviererbeI just learned about that this week14:49
didrocksjust used mermaid today and rendered a svg…14:49
didrocksso ok, I have some PR to open :)14:49
didrocksok, let’s move to the next section14:50
didrocks#topic MIR related Security Review Queue14:50
didrocksMission: Check on progress, do deadlines seem doable?14:50
didrocksSome clients can only work with one, some with the other escaping - the URLs point to the same place.14:50
didrocks#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-mir14:50
didrocks#link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir14:50
didrocksInternal link14:50
didrocks- ensure your teams items are prioritized among each other as you'd expect14:50
didrocks- ensure community requests do not get stomped by teams calling for favors too much14:50
didrocks#link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/59414:50
didrockssarnold:  anything to mention at this point?14:50
sarnolddidrocks: eslerm finished cpdb-libs last week \o/ :) and we've assigned tasks around14:51
didrocksironic that for once, you are more on the security side than the reviewer side :p14:51
eslermI'm working on dbus-broker14:51
didrocksoh, that will make seb128 happy14:51
eslermsomeone signed up for cargo, but since it is incomplete I'll suggest other cargo dependencies14:51
didrocksunsure we got a conclusion on the maintaince side yet14:52
didrocksok, so good progress on that front :)14:52
didrocks#topic Any other business?14:52
sarnoldthe one missing piece from dbus-daemon does seem like a large risk..14:52
didrocksand we need to know where we are heading to, to prevent doing a MIR security review check for nothing14:53
sarnoldwe're not interested in *two* running dbus daemons, one for system and one for user14:53
eslermI could hold off for now14:53
didrocksmaybe check with seb128 first, as he was the one checking with foundation IIRC14:53
didrocksapart from breaking dbus (oh wait… broker, not breaker :p) anything else to note?14:54
eslermI'll ping ~mir-security-review-priority on MM14:54
didrockssounds good to me14:54
sarnoldI think eslerm ought to continue onwards; dbus is an integral part of everything, and getting issues with it sorted out as early as possible seems like a good approach14:54
eslermI'll just do what Seth suggests :D14:54
sarnoldand even if we decide to stick with what we've got because it meets gdm's needs, maybe we'll find useful things for upstream to work on before we return14:55
sarnoldoh yes! we missed the .../issues/ section earlier14:56
sarnoldI just added one about team members :) and eslerm added one a few days ago https://github.com/canonical/ubuntu-mir/issues/2214:56
-ubottu:#ubuntu-meeting- Issue 22 in canonical/ubuntu-mir "re-ACK after a set time period" [Open]14:56
didrockshttps://github.com/canonical/ubuntu-mir/issues/24 has been "opened" for years14:56
-ubottu:#ubuntu-meeting- Issue 24 in canonical/ubuntu-mir "More team members" [Open]14:56
didrocksyeah, agreed on 22, but it’s also blocked on 24 still14:57
didrocksanyway, I think we should discuss processes when more team members are around, wdyt?14:57
sarnoldnow that it's written down somewhere, I can trust cpaelzer will be annoyed enough by it to try to drive that through to an answer of how we do this :)14:57
didrocksheh, sounds good!14:57
sarnoldthat's it for me14:58
didrocksok, going once…14:58
didrocksgoing twice…14:58
didrocksand here we go! Thanks everyone :)14:58
sarnoldthanks didrocks, dviererbe, eslerm, jbicha  :)14:58
meetingologyMeeting ended at 14:58:40 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-30-14.34.moin.txt14:58
dviererbeThanks everyone!14:58
eslermthanks for hosting didrocks \o/14:58
didrocksyw! Have a good week14:58
seb128hey! :)19:00
rbasakseb128: o/ you're up to chair I think?19:00
seb128#startmeeting Technical Board19:01
meetingologyMeeting started at 19:01:04 UTC.  The chair is seb128.  Information about MeetBot at https://wiki.ubuntu.com/meetingology19:01
meetingologyAvailable commands: action, commands, idea, info, link, nick19:01
seb128#topic Action Review19:01
seb128#topic Apologies19:02
seb128I don't see any on the list/wiki19:02
seb128Lukasz doesn't seem to be online though19:02
seb128anyway, let's move one19:03
* vorlon waves19:03
seb128#topic Action Review19:03
seb128ACTION: amurray to follow up with backporters team on Mattia's draft charter proposal19:03
seb128amurray, did you get a reply since the previous meeting?19:03
amurrayNo - I've sent two emails to the backporters team asking them to ack mattia's proposal but had no response still19:03
rbasakAt the last meeting I said this:19:04
rbasakIt'd be nice to see a conclusion on this. I wonder if it would be appropriate to set a deadline at some point, and if no reply then we just use the current draft and call it done. I wouldn't mind it being long eg. months, but it'd be nice to have _some_ end point.19:04
seb128I'm +1 with that19:04
rbasakWe've already adjusted the draft to their suggestion, dropping what I had originally proposed.19:04
vorlonalso +119:05
rbasakCould we agree that this draft becomes final at some future date now, and encourage the backporters team to engage with us if they disagree?19:05
amurrayI agree - how about I send one more follow-up later today and stipulate that if we get no response within another 2 weeks (that would be over 1 month since my original email asking for their ack) then this will become final19:05
rbasakeg. two months from today, so 30 July.19:05
vorlonI think that should be the default.  We want the involved teams to be on board with what we rule, but if they're not going to engage, it's the TB who has the authority here19:06
rbasakI'm easy on the actual date as long as we set one :)19:06
seb128I was going to suggest start of July, seems similar timeframe19:06
rbasakSounds like we're all on the same page, so as amurray is driving I suggest he sets the date as he feels appropriate.19:06
amurraysure - I prefer going with say 2 weeks to avoid this dragging on much longer19:07
seb128so June 13 ?19:08
rbasakFWIW, we should also work with some of the other teams to establish some similar documentation. I'm not trying to single out the backporters team here! In the past few years, questions have arisen on the scope of the DMB's role, as well as AAs.19:08
amurrayI suggest June 12th - that way it falls just before the next TB meeting19:09
rbasakThough, to be clear, I don't think it should take a further TB meeting to agree. We're agreeing it now :)19:10
rbasak(but I welcome further discussion at a TB meeting should it arise)19:10
amurrayindeed - but this way at that meeting we have a clear outcome with any luck19:10
seb128#agreed  amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final19:11
meetingologyAGREED: amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final19:11
vorlonalso means that if there is any feedback given on the current draft we can quickly ratify those changes19:11
rbasakseb128: o/19:12
seb128k, let's move on?19:12
seb128rbasak, yes?19:12
rbasakMinor point: "if we get no response before" -> that sounds like if they respond, then it won't become final.19:12
seb128how do I edit an agreed? :p19:12
rbasakBut I think we just agreed to make it final regardless, on 12 June, unless the TB (and only the TB) decide otherwise before that date.19:13
rbasakYou can use #undo19:13
meetingologyRemoving item from minutes: AGREED19:13
rbasakThen #agreed something else19:13
seb128#agreed  amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise19:14
meetingologyAGREED: amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise19:14
seb128moving on19:15
seb128ACTION: seb128 to help draft an exception to the "must build on all architectures" requirement for snaps19:15
rbasakI'll discuss the status of the draft in a bit.19:15
rbasakBut we're a bit blocked on this now :-/19:15
seb128sorry, I've still been struggling with finding time for those items but rbasak started editing which pushed me to go back to it now19:16
seb128ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage19:16
seb128ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification19:16
rbasakCarry this please - I've been focused on the other thing19:16
seb128ACTION: 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 step19:16
rbasakCarry again I guess, as he's not here19:17
seb128Lukasz is not around today so that's another carry over19:17
seb128#topic Scan the mailing list archive for anything we missed (standing item)19:17
seb128nothing recent on the list19:17
rbasakI see some emails from amurray :-P19:17
seb128#topic Check up on community bugs and techboard bugs19:17
rbasakOh, did we lose the progress item on the third party repository requirements doc in general? I'd like to discuss that please.19:18
seb128rbasak, I was expecting that it come as an AOB since we don't have a specific item on the agenda for it19:19
seb128but yes we should add it back as an action19:19
seb128#info No new community bug activity19:19
seb128#topic Select a chair for the next meeting19:19
seb128next would be vorlon and if we follow the ordering on the launchpad page Lukasz as a backup19:20
seb128#info vorlon will chair next, with sil2100 as backup19:21
* vorlon nods19:21
seb128#topic third party repository requirements status update19:21
seb128rbasak, ^19:21
rbasakI have been working on the doc and I think it's ready. Apart from the appendices and the wording of the "build on all architectures exception" for the desktop packages that I think, we agree we need.19:22
vorlonfwiw I have another topic for AOB after this19:22
rbasakNext, I'd like to publish this for wider feedback.19:22
rbasakBefore I do that, could the TB please review the main body of the document and check you're happy with it?19:22
rbasakPerhaps we could give all TB members an opportunity to do that before our next meeting?19:22
vorlonsounds good to me19:22
amurrayrbasak: so I noticed there is nothing in the document regarding testability- ie. how do we integrate a seeded snap with britney?19:22
rbasakAnd unless there are any further comments from the TB, I'll present that as the TB's draft position, pending further feedback.19:23
rbasakamurray: I'm not sure I follow19:23
amurraydo we want to stipulate that a seeded snap must be able to be tested / have some tests that can be run to ensure it is "stable" before being released?19:24
rbasakI think we should definitely do those things. But I'm not sure it should be within the scope of this doc - just as we leave the specifics of how to test debs up to Ubuntu developers.19:24
rbasakFor example a package can be a deb in the Ubuntu archive with no tests whatsoever - that's currently permitted, even if it's not best practice.19:25
seb128well we have a MIR process, it sort of opens the question of it should apply to snaps that we want seeded19:25
rbasakCurrently the MIR team may decide to permit something in main without tests though, without involvement of the TB.19:25
rbasakSo in my mind, for a seeded snap, we're leaving that kind of decision to the Ubuntu developer making the change (in the seed, presumably).19:26
rbasakIt's a good question though.19:26
amurrayI don't want to be too specific here - but I do want to make sure that we can maintain quality for any third party packages and I see testing as a big part of that19:27
rbasakDo you think we should require something? And if so, would we require this for debs as well?19:27
rbasakamurray: I see your concern addressed by "Proposed requirement C: the package maintainer agrees to maintain the package for the lifetime of the Ubuntu release" already19:27
rbasakAnd the paragraph that says "the precise meaning of "maintain", is enforced by trust only"19:27
rbasakIOW - we agree that this is important, but we aren't dictating the specifics19:28
vorlonagreed w/ rbasak on this19:28
seb128but should a pre-installed snap get a +1 from the MIR team?19:28
vorlonI like that idea but think we should discuss it with the MIR team first to make sure they're comfortable taking on that duty19:29
amurrayfor debs we have britney and proposed-migration that enforces a level of quality on SRUs (assuming there are dep8 tests etc) by doing automated testing - if cups becomes a snap, how do we make sure it doesn't regress on updates in future releases? a lot of stuff depends on cups so I see this as important (as a topical example)19:30
rbasakI have no objection to a process requirement to get a review from some appropriate team19:30
rbasakBut whether that's the TB, the MIR team, or some new kind of snap-MIR team, is an open question I think.19:30
rbasakAnother option might be to start softer - by requiring such changes to be announced eg. to ubuntu-devel@ and be done before eg. feature freeze. That would allow the TB to object, but without the friction of a team requiring an approval.19:31
rbasakOr indeed to give some notice before doing it19:32
rbasak(or committing to doing it)19:32
rbasakamurray: would that address your concern with your cups example?19:33
amurrayyes I think that would work19:33
rbasakSo I'm open to any of the above. I would add it as a snap-specific policy requirement in the document (so into appendix C)19:34
rbasakWhich of those options should I take?19:34
rbasakPersonally I think I'd favour "soft, with notice" if that works for everyone?19:35
rbasakI'll write that up then. Thanks!19:37
amurraythank you :)19:37
rbasakSo, to summarise, homework for the TB: you have until the next meeting to study the doc and raise any other concerns you may have at the next meeting.19:37
rbasakAnd I'll write up the "snap MIR" process (just notice) requirement into appendix C.19:38
rbasakAny other comments on this topic for today?19:38
vorlonnone from me19:38
seb128#agreed the TB members have until the next meeting to review the third party repository requirements document and raise concerns19:39
meetingologyAGREED: the TB members have until the next meeting to review the third party repository requirements document and raise concerns19:39
seb128#topic AOB19:39
seb128vorlon, ?19:39
vorlonlast meeting we talked about the question of core teams governance19:40
vorlonI had just sent an email to the private thread, which I understood folks had the action to review and reply to?19:40
vorlonI haven't seen any responses yet :)19:40
rbasakOh, right19:40
rbasakIIRC, we said we'd make it public today?19:41
seb128yes, in fact I wanted to mention that, it's another of those action items I failed at acting on19:41
vorlongoing back to meeting log to see what we said19:41
seb128would people be ok to postpone until the next meeting?19:41
seb128Lukasz hasn't been around/commented on it19:42
rbasakSure. The thread hasn't had any activity recently. Perhaps we could agree that all further discussion on that topic can be expected to be public?19:42
vorlonweeks were given and no objections were raised, so maybe "replay the thread but publicly" is the correct next action here?19:42
vorlonin which case I guess it would be an action for seb128 to kick it off? :)19:43
vorlonif I correctly understand what is meant by "replay"19:43
rbasakThat was my wording IIRC, and yes I think you do.19:43
seb128#agreed seb128 to resend 'core teams governance' email to the public techboard list19:44
meetingologyAGREED: seb128 to resend 'core teams governance' email to the public techboard list19:44
rbasakBecause if seb128 posts it, then I can provide basically the same reply I did privately, and then the public will be able to follow my position/opinion on it.19:44
meetingologyRemoving item from minutes: AGREED19:44
seb128#agreed seb128 to resend the 'core teams governance' email to the public techboard list19:44
meetingologyAGREED: seb128 to resend the 'core teams governance' email to the public techboard list19:44
seb128any other AOB?19:44
amurraynothing from me19:45
vorlonnor me19:45
rbasakNone from me.19:45
seb128ok, it's a wrap then, thanks everyone!19:45
rbasakThank you all for a productive meeting!19:45
meetingologyMeeting ended at 19:45:21 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-30-19.01.moin.txt19:45
sarnold(heh "any other AOB" :)19:45
vorlonthanks, all!19:45
seb128sarnold, :p19:45
vorlonsarnold: "AOOB"19:45
amurraythanks folks19:45
=== Bashing-1m is now known as Bashing-om
=== bdrung_ is now known as bdrung
=== JanC is now known as Guest503
=== JanC_ is now known as JanC

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!