| didrocks | cpaelzer: I will be away for this week MIR meeting, I will take mesa-amber (should be easy, just a rename), but if there are more help needed, I can take one (I will scrollback after the meeting) | 13:54 |
|---|---|---|
| cpaelzer | ok didrocks - thanks! | 14:01 |
| sarnold | good morning | 14:30 |
| cpaelzer | hi - meeting overload | 14:46 |
| cpaelzer | here I am | 14:46 |
| cpaelzer | let us do this for the logs and for everybody having a chance to catch up later | 14:46 |
| cpaelzer | also we are close to release - so anything that comes up now is urgent | 14:46 |
| cpaelzer | hi sarnold | 14:46 |
| cpaelzer | OTOH not much should (tm) be in flight | 14:47 |
| cpaelzer | let us see | 14:47 |
| cpaelzer | #startmeeting Weekly Main Inclusion Requests status | 14:47 |
| meetingology | Meeting started at 14:47:13 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 14:47 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 14:47 |
| cpaelzer | slyon is out, didrocks will read the log later - jamespage sarnold joalif - ping for (late) MIR meeting | 14:47 |
| cpaelzer | #topic Review of previous action items | 14:47 |
| cpaelzer | none - that was quick | 14:47 |
| joalif | o/ | 14:47 |
| cpaelzer | #topic current component mismatches | 14:47 |
| cpaelzer | Mission: Identify required actions and spread the load among the teams | 14:47 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 14:47 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 14:47 |
| cpaelzer | tk -> xterm was the newest false positive last week | 14:48 |
| cpaelzer | didrocks: already said he will take mesa-amber | 14:48 |
| cpaelzer | nothing else new in here AFAICS | 14:48 |
| sarnold | hey cpaelzer :) | 14:48 |
| cpaelzer | nftables | 14:48 |
| cpaelzer | actually is ready for promotion now | 14:48 |
| cpaelzer | the seed change landed | 14:48 |
| sarnold | woot! thanks for your help cpaelzer :) | 14:49 |
| cpaelzer | Oh I see, wrong status | 14:49 |
| cpaelzer | that is how it was missed | 14:49 |
| cpaelzer | resolving | 14:49 |
| cpaelzer | done | 14:55 |
| cpaelzer | sorry, I'm still slow doing a few more checks ... | 14:55 |
| cpaelzer | #topic New MIRs | 14:55 |
| cpaelzer | Mission: ensure to assign all incoming reviews for fast processing | 14:55 |
| cpaelzer | #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:55 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/mesa-amber/+bug/1967086 | 14:55 |
| ubottu | Launchpad bug 1967086 in mesa-amber (Ubuntu) "MIR: mesa-amber" [Undecided, New] | 14:55 |
| cpaelzer | already agreed to be on didrocks plate | 14:55 |
| cpaelzer | nothing else | 14:55 |
| cpaelzer | #topic Incomplete bugs / questions | 14:56 |
| cpaelzer | Mission: Identify required actions and spread the load among the teams | 14:56 |
| cpaelzer | #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:56 |
| cpaelzer | only rustc | 14:56 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1957932 | 14:56 |
| ubottu | Launchpad bug 1957932 in rustc (Ubuntu) "[MIR] rustc, cargo, dh-cargo" [Critical, In Progress] | 14:56 |
| cpaelzer | ok this can be done after the meeting | 14:57 |
| cpaelzer | schopin: do you expect us/me to ack on your seed or does anyone else from foundations have a look and merge it? | 14:57 |
| cpaelzer | no other case with recent updates | 14:58 |
| schopin | cpaelzer: if you have the bandwidth it'd be nice, but I can pester my teammates. | 14:58 |
| cpaelzer | since time is short, let us go on | 14:58 |
| cpaelzer | pester please - the interim M job takes a toll these days | 14:58 |
| cpaelzer | #topic MIR related Security Review Queue | 14:58 |
| cpaelzer | Mission: Check on progress, do deadlines seem doable? | 14:58 |
| cpaelzer | #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:58 |
| cpaelzer | the list is good, nothing with 22.04 deadline left unassigned | 14:59 |
| cpaelzer | that leaves https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1950321 as the only one | 14:59 |
| ubottu | Launchpad bug 1950321 in glusterfs (Ubuntu) "[MIR] glusterfs" [Critical, Confirmed] | 14:59 |
| cpaelzer | the only one we still wait on | 14:59 |
| cpaelzer | sarnold: ^^ help | 14:59 |
| cpaelzer | and sbeattie ^^ help | 14:59 |
| cpaelzer | I'd do anything for love ... umm .... this review :-) | 14:59 |
| didrocks | (this is an opportunity for beers at next sprint sarnold :p) | 15:00 |
| cpaelzer | if that would help sign me up | 15:00 |
| sarnold | alas there's only one sbeattie :( he's done enough of this review that it probably doesn't make sense to try to juggle it away to someone else | 15:00 |
| cpaelzer | I tried alredy - but if there is anything else we can help to get glusterfs completed let me know | 15:00 |
| cpaelzer | you can envision a team (and their committments and roadmap items) shivering in wait for this :-) | 15:01 |
| cpaelzer | ok, I guess sarnold and sbeattie know how urgent / important that is for us | 15:01 |
| sarnold | yes :( | 15:01 |
| sarnold | also yes | 15:01 |
| cpaelzer | and to be fair - we solved everything else already, so we are almost there and huge thanks for that | 15:01 |
| cpaelzer | #topic Any other business? | 15:01 |
| sarnold | none from me | 15:02 |
| didrocks | yeah, seeing the list few months ago, it’s awesome to get to that state now | 15:02 |
| didrocks | nothing either | 15:02 |
| cpaelzer | none from me either | 15:02 |
| cpaelzer | other than conflicting meeting | 15:02 |
| cpaelzer | ending here to join the other | 15:02 |
| sarnold | heh | 15:02 |
| cpaelzer | see you all | 15:02 |
| cpaelzer | #endmeeting | 15:02 |
| sarnold | thanks cpaelzer, all :) | 15:02 |
| meetingology | Meeting ended at 15:02:43 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-04-05-14.47.moin.txt | 15:02 |
| didrocks | see you, thanks all! | 15:02 |
| joalif | thanks all o/ | 15:02 |
| * vorlon waves | 18:48 | |
| vorlon | https://wiki.ubuntu.com/TechnicalBoardAgenda still says the next meeting is 2 weeks ago | 18:51 |
| sil2100 | o/ | 18:58 |
| rbasak | o/ | 18:58 |
| sil2100 | Anyone else still having issues loging onto the wiki? | 18:59 |
| vorlon | oh, I'm logged out hmm | 18:59 |
| * vorlon checks | 18:59 | |
| vorlon | "OpenID verification requires that you click this button" -> <spinning> | 19:00 |
| vorlon | 504 | 19:00 |
| sil2100 | Same | 19:01 |
| sil2100 | I filled in an RT | 19:01 |
| sil2100 | RT: #149245 | 19:02 |
| vorlon | well I was looking at it because it's possible I was supposed to chair, but it's more problematic if we don't have a working agenda | 19:02 |
| vorlon | we could try to run a meeting, but if there aren't any immediate items for discussion maybe it's more productive to spend the time escalating that RT? | 19:03 |
| sil2100 | vorlon: I think the item that might need reminding/discussing is the third-party app requirement doc | 19:04 |
| vorlon | which the agenda still links to the pad version :) | 19:04 |
| sil2100 | I spent a moment today to read up rbasak's preamble propositions and some of the other written down bits and left some comments | 19:04 |
| sil2100 | hah ;) | 19:05 |
| sil2100 | I think rbasak shared the document with us, so there should be an e-mail somewhere | 19:05 |
| rbasak | I think sil2100 raises some good questions which might benefit from being discussed in realtime | 19:05 |
| rbasak | https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit | 19:05 |
| rbasak | sil2100: I'm not sure I follow what you're saying about PPAs. I think it's been a longstanding requirement that for example flavors can't enable a PPA by default, and then drive flavor-supplied packages from there. Are you saying that you don't think this should be a requirement? | 19:09 |
| sil2100 | rbasak: I'm saying we should not think about changing that | 19:09 |
| sil2100 | i.e. we should still not enable flavors be able to enable third party PPAs | 19:10 |
| sil2100 | Ah, maybe I misunderstood your comment there! | 19:10 |
| rbasak | I don't think I'm proposing to change that. However it seems to me that the general principles we're specifying here actually cover our views on PPAs. So my question is on scope of this document. Should it just cover snaps? Or Flatpak as well? And/or PPAs as well? | 19:10 |
| sil2100 | Since I thought that what you meant in the comment was that maybe we should re-phrase and prepare the third-party app rules so that flavors *can* enable third-party PPAs *if* they are able to fulfill the requirements | 19:11 |
| vorlon | I would prefer it be comprehensive, so that if someone asks again why they can't ship flatpaks, we can point at this as the answer | 19:11 |
| vorlon | this discussion started with a flavor request for flatpaks | 19:11 |
| sil2100 | Yes, I'm +1 for this to apply to more than just snaps. I just don't think I'd want this to lead to a situation where developers create PPAs and processes that would fulfill our requirements and therefore be able to have third-party PPAs enabled by default | 19:13 |
| rbasak | sil2100: I think it would turn out to be that flavors *can* enable third-party PPAs *if* they are able to fulfill the requirements. However this would be impossible in practice since PPAs wouldn't meet the requirements. | 19:13 |
| sil2100 | rbasak: are we sure they wouldn't? I don't remember all the requirements now, but from my brief memory I think it still could be possible to fulfill the requirements with a PPA if it's allowed | 19:14 |
| rbasak | I think you have a point. | 19:14 |
| vorlon | in that case I think the rules are insufficiently strict because we shouldn't allow ppas :) | 19:15 |
| rbasak | I agree | 19:15 |
| rbasak | It's a good point | 19:15 |
| rbasak | We need to make sure that the rules don't inadvertently allow PPAs. | 19:15 |
| rbasak | However, I think we're all agreed then that the scope of the rules shall be general, and incorporate snaps, Flatpaks, PPAs and anything else. | 19:15 |
| sil2100 | And you know, in overall there wouldn't be anything wrong with PPAs if they fulfil the requirements - because then it means we have 'Ubuntu enough quality' - but I also think that since the Ubuntu archive does fulfil all the requirements, it should be the single-source-of-truth for debs | 19:16 |
| sil2100 | Yes, +1 | 19:16 |
| sil2100 | So yes, I think we should extend it to all cases as you mention rbasak and then work on the requirements a bit more to make sure it still would allow snaps to be preseeded but maybe not allow third-party PPAs | 19:17 |
| rbasak | How about we simply require individual TB requirement for every "class" of packaging system. This document would specify the minimum requirement, but a class would still be subject to TB approval. And the TB would simply decline to grant the PPA class of packaging because the Ubuntu archive should be used instead. | 19:17 |
| rbasak | individual TB *approval* | 19:17 |
| sil2100 | From the release perspective it would be really confusing, trying to guess what PPAs are official etc. | 19:17 |
| sil2100 | hm, that doesn't sound bad | 19:18 |
| rbasak | OK I'll work on some wording for that. | 19:18 |
| vorlon | I think using ppas instead of the Ubuntu archive would be bad for several reasons; lack of auditability, diffusion of community oversight are the first two that come to mind. I'm not sure if these concerns can be generalized across different packaging formats/ecosystems, though; it's more of an "the Ubuntu archive is right there so just use it" | 19:19 |
| sil2100 | Yeah | 19:20 |
| rbasak | +1 | 19:20 |
| vorlon | rbasak: you're happy to work on wording to address this, then? Any further discussion needed? | 19:21 |
| sil2100 | Do we want to discuss something more from the draft? rbasak thank you for starting the initial wording, it's looking very good so far! | 19:22 |
| rbasak | One moment please | 19:22 |
| sil2100 | I think if we're able to generalize it to all cases and maybe add this 'TB individual approval' requirement, this should be good to go | 19:22 |
| rbasak | vorlon: your opinion on sil2100's comment on snap branches please? | 19:23 |
| rbasak | Under requirement A | 19:23 |
| sil2100 | I don't know however if one can easily switch tracks for snaps - I think yes? | 19:23 |
| sil2100 | Or maybe asking the snapd and snapstore teams for persistent branches | 19:24 |
| rbasak | I thought we did what you suggest already? | 19:24 |
| vorlon | ah I guess I missed that comment, looking | 19:24 |
| sil2100 | I have concerns on the maintainability of such tracks/branches though | 19:24 |
| vorlon | well, this is exactly what we require today for all seeded snaps | 19:25 |
| sil2100 | vorlon: well, we require 'branchs' | 19:25 |
| vorlon | yes | 19:25 |
| sil2100 | 'branches' | 19:25 |
| rbasak | I think it is also what gives us the ability for Ubuntu developers to be able to override (requiremetn B) | 19:25 |
| sil2100 | And branches auto-close after 30 days and default to stable | 19:26 |
| vorlon | with the vague promise that if we ever needed long-term branches to meet these requirements, the store team would give them to us | 19:26 |
| sil2100 | So basically some of those branches close down and people are automatically switched to stable | 19:26 |
| vorlon | hmm how is this working in practice with subiquity today? that's a real-world use case where we are seeding snaps at different revisions across per-release branches | 19:26 |
| rbasak | So we have a) the general requirement; and b) how the general requirement is implemented for snaps specifically | 19:27 |
| sil2100 | vorlon: I don't know exactly, but I vaguely remember a few cases where I had to request re-opening of the stable ubuntu branches before a point-release as they were not present anymore | 19:27 |
| vorlon | from my perspective, it is a requirement that we retain the ability for users of different releases to automatically be kept on the correct revision of the snap which integrates with the version of the OS they're running | 19:27 |
| rbasak | Are we agreed that the general requirement sounds OK in principle? | 19:27 |
| sil2100 | I might be misremembering, but with branches how they are it's certainly a possibility | 19:27 |
| rbasak | And we're just trying to figure out how that's achieved for snaps specifically now? | 19:28 |
| sil2100 | rbasak: +1 on the general requirement | 19:28 |
| rbasak | So maybe it'd be useful to have an appendix detailing how the general requirements are fulfilled for snaps. Or | 19:28 |
| vorlon | sil2100: I haven't heard any explosions as a result of users who were on these branches having been auto switched client side to the branchless 'stable' | 19:28 |
| rbasak | For subiquity, I think a TB-granted exception is probably warranted. | 19:29 |
| vorlon | lxd is another real-world example, I think? | 19:29 |
| vorlon | rbasak: not clear to me that subiquity should get any exceptions on this | 19:29 |
| vorlon | if the requirement is "stability", we certainly want our LTS installers to remain stable :) | 19:29 |
| rbasak | vorlon: I think we've added features at approximately point release time in subiquity in the past? | 19:30 |
| sil2100 | vorlon: yeah, no issues so far, but that doesn't change the fact that we do introduce a lot of features and changes to users when those switches happen ;p Which we usually try to avoid for SRUs | 19:30 |
| sil2100 | Of course subiquity probably should have an exception, but I think that's a separate discussion to be had | 19:30 |
| vorlon | we have discussed the meaning of "stability" before and didn't think we had converged on any general rules that forbade the introduction of new features | 19:31 |
| rbasak | I propose to kick this can down the road for now. Let me get the draft a bit more done. Then we can look at subiquity again. Before we ratify anything I mean. | 19:31 |
| vorlon | ok | 19:31 |
| rbasak | OK I think I'm happy to move on from this topic now - thanks. I have plenty to adjust in the draft. | 19:32 |
| sil2100 | THanks again for working on this! | 19:32 |
| rbasak | yw, and thank you for the ongoing feedback! | 19:33 |
| sil2100 | ...actually, too bad we didn't start the meeting, since maybe it would have been good to have this logged by meetingology ! | 19:33 |
| vorlon | :) | 19:33 |
| sil2100 | Oh well ;) | 19:33 |
| rbasak | It's in irclogs at least | 19:33 |
| vorlon | anyway, thanks for the discussion | 19:33 |
| sil2100 | It's logged anyway! | 19:33 |
| sil2100 | Thanks vorlon, rbasak o/ | 19:34 |
| rbasak | There was also ddstreet's request for his backports charter ratification | 19:34 |
| rbasak | Maybe you can participate on the ML please? | 19:34 |
| vorlon | ack | 19:35 |
| sil2100 | Will take a look | 19:40 |
| sil2100 | o/ | 19:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
