| === JanC is now known as Guest7641 | ||
| === JanC_ is now known as JanC | ||
| slyon | heyho o/ | 14:31 |
|---|---|---|
| eslerm | hello o/ | 14:31 |
| joalif | o/ | 14:31 |
| slyon | I wonder if cpaelzer is around ... (I thought he would be) | 14:34 |
| slyon | Let's wait for one more minute, otherwise I can run us through the script. I don't think there's a lot on the normal agenda today, due to being in release week. | 14:35 |
| slyon | #startmeeting Weekly Main Inclusion Requests status | 14:36 |
| meetingology | Meeting started at 14:36:08 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 14:36 |
| slyon | Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) | 14:36 |
| slyon | #topic current component mismatches | 14:36 |
| slyon | Missio | 14:36 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 14:36 |
| slyon | Mission: Identify required actions and spread the load among the teams | 14:36 |
| slyon | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 14:36 |
| slyon | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 14:36 |
| slyon | This looks all very common. Mostly known false-positives. Except for jaraco.text, which apparently didn't make it this cycle, again. :( | 14:37 |
| slyon | #topic New MIRs | 14:37 |
| slyon | Mission: ensure to assign all incoming reviews for fast processing | 14:37 |
| 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 | 14:37 |
| slyon | empty. | 14:37 |
| cpaelzer | I'm here now, but not the full length | 14:37 |
| cpaelzer | thanks for driving the meeting slyon | 14:37 |
| slyon | #topic Incomplete bugs / questions | 14:37 |
| slyon | Mission: Identify required actions and spread the load among the teams | 14:37 |
| 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 | 14:37 |
| slyon | going back one week 2023-10-03, we have only one update in bug #2023971 | 14:38 |
| -ubottu:#ubuntu-meeting- Bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [Undecided, Incomplete] https://launchpad.net/bugs/2023971 | 14:38 | |
| * slyon reading | 14:38 | |
| cpaelzer | I know that mirespace follows some leads I have given her | 14:39 |
| cpaelzer | which will cut down the list of packages needed a lot | 14:39 |
| cpaelzer | essentially she is trying to save us all 40 more MIR packages | 14:39 |
| slyon | nice! | 14:39 |
| slyon | Seems there are some clear next steps defined on her side | 14:40 |
| slyon | Nothing to do for us, right now. | 14:40 |
| slyon | #topic Process/Documentation improvements | 14:40 |
| slyon | Mission: Review pending process/documentation pull-requests or issues | 14:40 |
| slyon | #link https://github.com/canonical/ubuntu-mir/pulls | 14:40 |
| slyon | #link https://github.com/canonical/ubuntu-mir/issues | 14:40 |
| cpaelzer | PR is a draft and held back for better times | 14:40 |
| cpaelzer | the issues are also old news | 14:41 |
| cpaelzer | I think we can go on | 14:41 |
| slyon | ack. | 14:41 |
| slyon | #topic MIR related Security Review Queue | 14:41 |
| eslerm | Simon asked for clarification on when tools in main needed re-review, as we had fro s390-tools | 14:41 |
| slyon | Mission: Check on progress, do deadlines seem doable? | 14:41 |
| slyon | Some clients can only work with one, some with the other escaping - the URLs point to the same place. | 14:41 |
| 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 | 14:41 |
| cpaelzer | eslerm: you know the discussion on re-review as a process | 14:41 |
| slyon | #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-mir | 14:41 |
| cpaelzer | which has thoughts, but everyone saying "no resources for that, please do not add it atm" | 14:42 |
| slyon | eslerm: cpaelzer: and for s390-tools it was also a (hidden) component-mismatch | 14:42 |
| cpaelzer | the reason for s390-tools has been because it was a voluntary (appreciated) "there is a massive change" | 14:42 |
| slyon | as it was pulling in new non-reviewed dependencies. (even though vendored) | 14:42 |
| cpaelzer | exactly - ack to slyon | 14:42 |
| eslerm | thank you | 14:43 |
| slyon | Internal link | 14:43 |
| slyon | #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 | 14:43 |
| slyon | So eslerm, do you want to give and update on the security review process? | 14:43 |
| cpaelzer | or rather s/process/progress/ :-) | 14:43 |
| eslerm | non-reviewed dependencies sounds like the whole process in general ? | 14:43 |
| cpaelzer | it is the whole process, but they could have sneaked them in as they would have been vendored | 14:44 |
| eslerm | Security doesn't have a great way to work through all vendoreded dependencies, rustc has ~700 and we can't review them all | 14:44 |
| cpaelzer | so the tooling would not have stopped them | 14:44 |
| cpaelzer | eslerm: you mean rustc itself has 700 other things? | 14:45 |
| eslerm | ah, understood, I'll add a task to the jira board above | 14:45 |
| eslerm | rustc/cargo has ~700 vendored packages | 14:45 |
| eslerm | issues in those packages should be tracked too | 14:46 |
| eslerm | rustc 1.70.0 has 532 folders in ./vendor/ | 14:46 |
| slyon | I agree. I'll start a discussion at the next engineering sprint about having toolchain maintainers provide a set of "base" dependencies (tiny but ubiquitous) for their ecosystem and help maintaining them in "main". Hopefully that should cover many of those 532 folders | 14:47 |
| eslerm | thank you slyon | 14:48 |
| eslerm | overlap with rustc is appreciated | 14:48 |
| cpaelzer | which is one of the issues you see in github | 14:48 |
| cpaelzer | talk about these base sets | 14:48 |
| slyon | any other update from the security team? | 14:48 |
| eslerm | none, except s390-tools being ack'd last week | 14:49 |
| slyon | eslerm: Thanks and kudos. That's much appreciated! I know timing was very tight. | 14:49 |
| slyon | #topic Any other business? | 14:49 |
| slyon | cpaelzer: did you want to bring up anything? | 14:50 |
| cpaelzer | no | 14:50 |
| joalif | none | 14:50 |
| slyon | ok. Nothing from my side either. | 14:50 |
| eslerm | none | 14:50 |
| slyon | Alright. I guess that's it then for today. | 14:50 |
| slyon | thank you all! | 14:50 |
| eslerm | thanks slyon, all o/ | 14:50 |
| slyon | #endmeeting | 14:51 |
| meetingology | Meeting ended at 14:51:25 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-10-10-14.36.moin.txt | 14:51 |
| cpaelzer | thanks slyon | 14:51 |
| joalif | thanks all | 14:52 |
| rbasak | o/ | 19:01 |
| seb128 | hey | 19:01 |
| * vorlon waves | 19:02 | |
| vorlon | sil2100 is at the release sprint this week, so given the timing I think he probably won't be joining (he's hopefully getting some dinner now) | 19:03 |
| vorlon | #startmeeting | 19:03 |
| meetingology | Meeting started at 19:03:10 UTC. The chair is vorlon. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 19:03 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 19:03 |
| vorlon | #topic apologies | 19:03 |
| vorlon | amurray sent his apologies to the list | 19:03 |
| vorlon | and as mentioned, I expect sil2100 is indisposed due to release sprint | 19:03 |
| vorlon | #topic action review | 19:03 |
| vorlon | seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage | 19:04 |
| vorlon | seb128: anything to update here? | 19:04 |
| seb128 | not from me, and I didn't see activity from the others either | 19:04 |
| vorlon | ok, carrying over | 19:04 |
| vorlon | #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage | 19:04 |
| meetingology | ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage | 19:04 |
| vorlon | rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 19:04 |
| vorlon | rbasak: ? | 19:05 |
| rbasak | Carry over again please | 19:05 |
| vorlon | #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 19:05 |
| meetingology | ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 19:05 |
| vorlon | rbasak to follow up on finding consensus on question of test plans for third party apps | 19:05 |
| rbasak | Same again | 19:05 |
| vorlon | #action rbasak to follow up on finding consensus on question of test plans for third party apps | 19:05 |
| meetingology | ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps | 19:05 |
| rbasak | And my third too | 19:05 |
| vorlon | #action rbasak to open wider discussion on third-party repo policy | 19:05 |
| meetingology | ACTION: rbasak to open wider discussion on third-party repo policy | 19:05 |
| vorlon | seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations | 19:05 |
| vorlon | this appears to be in process | 19:05 |
| seb128 | I finally found some time to reach out to the teams | 19:05 |
| vorlon | seb128: I was surprised that you were emailing the AAs about this because you are an admin in that team, and I thought in a previous round of discussion I suggested that you should take the point on drafting? | 19:06 |
| seb128 | but it was only yesterday, rbasak replied for the SRU team today | 19:06 |
| vorlon | yes | 19:06 |
| seb128 | vorlon, I do plan to follow up/work on that but I decided to email anyway to give the context to everyone in the team | 19:06 |
| seb128 | I should perhaps have included a note about that directly | 19:07 |
| seb128 | I will follow up | 19:07 |
| vorlon | ok | 19:07 |
| vorlon | is there a new action that should be recorded now that this is in progress? the follow-up is done but of course there's nothing to record on the wiki yet | 19:08 |
| seb128 | maybe reword slightly the action item? | 19:08 |
| rbasak | +1 | 19:08 |
| vorlon | huh maybe the new action would also be follow-up? :) | 19:09 |
| seb128 | follow up -> continue working | 19:09 |
| vorlon | ok | 19:09 |
| vorlon | #action seb128 to continue working with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations | 19:09 |
| meetingology | ACTION: seb128 to continue working with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations | 19:09 |
| vorlon | and mine is also carry-over | 19:09 |
| vorlon | #action vorlon to write up draft guidelines for packages in the archive that download from the Internet | 19:09 |
| meetingology | ACTION: vorlon to write up draft guidelines for packages in the archive that download from the Internet | 19:09 |
| vorlon | #topic Scan the mailing list archive for anything we missed (standing item) | 19:10 |
| vorlon | so in https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html seb128 says he would like to "put the topic back on the agenda for the next TB meeting" | 19:11 |
| vorlon | seb128: is there a discussion you want to have about this right now? | 19:11 |
| seb128 | vorlon, let's postpone to next time to let a chance for the concerned team to follow up on the emails I just sent, and also to have more TB members around? | 19:12 |
| vorlon | ok | 19:12 |
| vorlon | #action add to next meeting agenda to have follow-up discussion on https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html | 19:12 |
| meetingology | ACTION: add to next meeting agenda to have follow-up discussion on https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html | 19:12 |
| vorlon | then there is also https://lists.ubuntu.com/archives/technical-board/2023-October/002767.html | 19:13 |
| vorlon | in which rbasak asks for TB sign-off | 19:13 |
| vorlon | while we could vote here with 3 of us, that seems better done via the mailing list IMHO? | 19:13 |
| rbasak | But nobody replied in the ML | 19:13 |
| seb128 | I was waiting for the meeting thinking it would be easier | 19:14 |
| seb128 | I will reply on the list since that didn't work out | 19:14 |
| rbasak | We're here, so could we just do it now? | 19:14 |
| rbasak | If you're both happy, then we could just call it done, and I can reply to the ML and speak for the TB in approving. | 19:15 |
| rbasak | If you have questions or concerns, then we could discuss that right now. | 19:15 |
| vorlon | rbasak: I'm happy, and additionally I don't see the fact that this is done after EoSS to be something that structurally requires TB signoff | 19:15 |
| seb128 | I'm +1 as well | 19:16 |
| rbasak | I was unclear if that aspect was for the TB or SRU team to decide - it's unclear that the SRU team has any say after EoSS at all. | 19:16 |
| vorlon | if we're doing the formal signoff here let's call a vote | 19:16 |
| rbasak | But I figured that if the TB and SRU team are both happy, then we can call it done. | 19:16 |
| vorlon | rbasak: <shrug> the fact that there is a difference between standard support and esm support, and the fact that we keep the archive open past the end of standard support, is also not anything that required TB signoff | 19:17 |
| rbasak | We don't have any formal definition of what requires TB sign-off :) | 19:17 |
| vorlon | #vote sign off on UbuntuAdvantageToolsUpdates exception that "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default" and "Updates shall be permitted as usual for SRUs and additionally after EoSS." | 19:17 |
| meetingology | Please vote on: sign off on UbuntuAdvantageToolsUpdates exception that "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default" and "Updates shall be permitted as usual for SRUs and additionally after EoSS." | 19:17 |
| meetingology | Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') | 19:17 |
| vorlon | +1 | 19:18 |
| meetingology | +1 received from vorlon | 19:18 |
| rbasak | The whole ESM arrangement was done with TB members involved so I think we can assume the TB is happy with it. | 19:18 |
| rbasak | +1 | 19:18 |
| meetingology | +1 received from rbasak | 19:18 |
| seb128 | +1 | 19:18 |
| meetingology | +1 received from seb128 | 19:18 |
| vorlon | #endvote | 19:18 |
| meetingology | Voting ended on: sign off on UbuntuAdvantageToolsUpdates exception that "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default" and "Updates shall be permitted as usual for SRUs and additionally after EoSS." | 19:18 |
| meetingology | Votes for: 3, Votes against: 0, Abstentions: 0 | 19:18 |
| meetingology | Motion carried | 19:18 |
| rbasak | Great! Thanks. | 19:18 |
| vorlon | that's it for mailing list | 19:18 |
| vorlon | #topic Check up on community bugs and techboard bugs | 19:18 |
| vorlon | #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard | 19:19 |
| vorlon | 0 | 19:19 |
| vorlon | #link https://bugs.launchpad.net/techboard | 19:19 |
| vorlon | nothing new... | 19:19 |
| vorlon | (and both covered via outstanding actions) | 19:19 |
| vorlon | #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) | 19:20 |
| vorlon | I believe next is sil2100 with amurray as backup | 19:20 |
| seb128 | ack | 19:21 |
| vorlon | #agreed next chair: sil2100, backup: amurray | 19:21 |
| meetingology | AGREED: next chair: sil2100, backup: amurray | 19:21 |
| vorlon | #topic AOB | 19:21 |
| vorlon | one little thing that might be worth mentioning here vs in a direct message | 19:22 |
| vorlon | DMB recently approved philroche's PPU application for livecd-rootfs | 19:22 |
| vorlon | and the packageset stuff seemed to all happen behind the scenes, which is fine - I assume rbasak switched hats DMB->TB and got it done? | 19:22 |
| vorlon | anyway I also gave him direct commit rights on the git repo (because it's not git-ubuntu yet cough cough) which caused me to notice that rcj who is no longer actively involved in Ubuntu development still has livecd-rootfs ppu rights as well | 19:23 |
| seb128 | vorlon, it was mentioned on https://lists.ubuntu.com/archives/devel-permissions/2023-October/002350.html I think? | 19:23 |
| rbasak | Yes I just did the PPU addition wearing my TB hat, without bothering with the process for a bug, because I'm on both teams. | 19:23 |
| vorlon | seb128: right, TB isn't expected to be subscribed to that list? (I'm not) | 19:23 |
| seb128 | fair enough | 19:24 |
| vorlon | so anyway, this made me aware that DMB doesn't review historic PPU rights or packagesets to confirm they're still relevant and appropriate | 19:24 |
| rbasak | We only created the bug process to request PPU changes because we were struggling to get the changes done otherwise. I think we should keep that option open (eg. if a TB+DMB member is unavailable or retires) but didn't think it was mandatory to use. | 19:24 |
| vorlon | and I just wanted to make the rest of the TB aware of this | 19:24 |
| rbasak | doesn't review historic> this applies to things like core dev, too. | 19:25 |
| vorlon | very true | 19:25 |
| seb128 | I was going to say that, taking the archive team as another example | 19:25 |
| rbasak | It has been suggested that perhaps we should expire people from those teams if they haven't uploaded for some period of time. | 19:25 |
| rbasak | Although I wouldn't want to encourage uploaders to make junk uploads to keep their rights, either. | 19:26 |
| vorlon | fwiw it feels to me that ppu should have >= scrutiny to the general uploader teams; because someone who has passed muster for core-dev might perhaps dip in and out of involvement over time while still having passed the bar for technical knowledge of Ubuntu as a whole | 19:26 |
| rbasak | That would help keep the archive secure - less attack surface for an adversary getting hold of uploaders' keys, etc. | 19:27 |
| vorlon | whereas someone who has only been approved for PPU of a particular package(set), and has NOT been involved in the maintenance of it... well? | 19:27 |
| vorlon | Anyway! this isn't something I wanted to demand / propose immediate changes around, just raising awareness and food for thought | 19:27 |
| rbasak | I'm not sure I see that distinction really, but I agree with the general principle. | 19:28 |
| rbasak | FWIW, this sort of thing has been discussed within the DMB before. I don't remember anyone having any particular objections. | 19:28 |
| vorlon | rbasak: well in this specific case I would say that if rcj actually exercised his PPU rights on livecd-rootfs I would immediately be checking if his account was compromised (or, er, if he was personally compromised) | 19:28 |
| rbasak | We don't currently have the mechanism. Somebody would have to write the code. | 19:28 |
| vorlon | also while security is always a concern, I also want to balance that against not causing folks in the broader Ubuntu developer community feel like they are being cast off if they have had less time to be involved | 19:29 |
| rbasak | I'm not keen on singling out individuals FWIW. If we want to implement this kind of policy, we should do it, but we should define the criteria and apply it at once for whomever it's met. | 19:29 |
| rbasak | Perhaps we could "downgrade" them to "Contributing Developer", and the DMB should have a lower bar on reapplication. | 19:30 |
| vorlon | of course. I'm just using him as an example of why we might want a policy, because I'm familiar enough with the specifics there | 19:30 |
| rbasak | So that they are still recognised for their previous contributions. | 19:30 |
| vorlon | oh, one other practical implication of all of this | 19:30 |
| vorlon | the release team bot that auto-approves non-frozen packages in the unapproved queue ... honors packagesets. So having stale packagesets wastes some developer time during release freezes | 19:32 |
| rbasak | honors packagesets> what does that mean, exactly? | 19:32 |
| rbasak | Is it re-applying an ACL somehow? | 19:33 |
| rbasak | Because apart from that, a packageset is just a list of packages, no? | 19:33 |
| vorlon | rbasak: the bot assumes that packages that are part of a packageset, but not seeded in main, should not be blindly waved through the queue | 19:33 |
| vorlon | which means they sit in the queue longer until a human reviews them | 19:33 |
| vorlon | maybe the answer is "the bot shouldn't do that" | 19:33 |
| rbasak | I was going to say that :) | 19:33 |
| rbasak | Can it use seeded-in-ubuntu instead perhaps? | 19:34 |
| vorlon | well now we're getting into the weeds | 19:34 |
| vorlon | because I have issues with the implementation of that command too :) | 19:34 |
| vorlon | anyway, enough of this digression IMHO | 19:35 |
| rbasak | The thing is, the DMB doesn't actively maintain packagesets | 19:35 |
| rbasak | It's sort of difficult to do. | 19:35 |
| rbasak | In practice they are only tweaked on request | 19:35 |
| vorlon | yeah | 19:35 |
| vorlon | IMHO https://ubuntu-archive-team.ubuntu.com/packagesets/mantic/ has some definitely dodgy stuff | 19:36 |
| seb128 | we should probably try to review those at some point indeed | 19:37 |
| seb128 | the ubuntugnome one for example doesn't make sense anymore | 19:37 |
| seb128 | just to pick one random example | 19:37 |
| vorlon | would we want the TB to do that review? DMB? Random Ubuntu devs (maybe on the release team) proposing removals? | 19:38 |
| seb128 | having the devs proposing removals might make sense, I'm unsure the TB or DMB have enough context on the specifics of each set | 19:39 |
| vorlon | sounds fine to me | 19:40 |
| vorlon | anyway - | 19:40 |
| vorlon | AOB? | 19:40 |
| rbasak | I just managed to dig up https://irclogs.ubuntu.com/2023/08/07/%23ubuntu-meeting.html#t19:24 | 19:41 |
| rbasak | This is an example of Brian noticing the mythbuntu packageset still existing | 19:41 |
| vorlon | oh augh | 19:41 |
| vorlon | :) | 19:41 |
| seb128 | vorlon, on the cleaning of packagesets should we take a note / action item to maybe at least start a discussion about it on a project list tbd? | 19:41 |
| rbasak | He got an action item to clear it up since he noticed, but I'm not sure if that was recorded properly. | 19:41 |
| vorlon | seb128: I don't want to take the action because it's low-priority, and I don't want it to be "everybody's responsibility" either :) | 19:42 |
| seb128 | rbasak, the action isn't listed on the wiki so it seems it wasn't recorded properly | 19:43 |
| seb128 | vorlon, fair enough, I keep a note on my backlog of things I might try to do one day if nobody beats me to it | 19:44 |
| vorlon | sounds good | 19:44 |
| vorlon | shall we call the meeting there? | 19:44 |
| rbasak | Sure, thanks. | 19:44 |
| vorlon | #endmeeting | 19:44 |
| meetingology | Meeting ended at 19:44:28 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-10-10-19.03.moin.txt | 19:44 |
| vorlon | rbasak, seb128 thanks! | 19:44 |
| seb128 | thanks! | 19:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
