| === cpaelzer_ is now known as cpaelzer | ||
| === genii-core is now known as genii | ||
| === cpaelzer_ is now known as cpaelzer | ||
| cpaelzer | Hiho everyone | 14:29 |
|---|---|---|
| cpaelzer | #startmeeting Weekly Main Inclusion Requests status | 14:29 |
| meetingology | Meeting started at 14:29:40 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 14:29 |
| sarnold | good morning | 14:29 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 14:29 |
| cpaelzer | ping ddstreet, sarnold, didrocks, slyon, (doko) and jamespage for MIR team meeting | 14:29 |
| didrocks | hey | 14:30 |
| cpaelzer | Hello everyone o/ | 14:30 |
| slyon | o/ | 14:30 |
| cpaelzer | #topic Review of previous action items | 14:30 |
| cpaelzer | I've seen we had a few review upadtes but those (if needed) will come at later stages | 14:31 |
| cpaelzer | the only independent activty is the update to the microlib testing that I was driving | 14:31 |
| cpaelzer | latest state is here https://github.com/cpaelzer/ubuntu-mir/pull/1/files | 14:31 |
| ubottu | Pull 1 in cpaelzer/ubuntu-mir "Rules for tests on the app-level" [Open] | 14:31 |
| cpaelzer | I have two acks on the PR and a "ok" on the mail | 14:31 |
| cpaelzer | no other feedback | 14:31 |
| cpaelzer | therefore I'd think I can merge this after the meeting | 14:31 |
| cpaelzer | please speak up if you think otherwise | 14:31 |
| slyon | +1 | 14:32 |
| slyon | (for merging it) | 14:32 |
| sarnold | +1 (I can't recall if I replied via email or elsewhere..) | 14:32 |
| cpaelzer | Thanks, I'll somewhen in the next weeks then take the bigger task to unite rules and templates | 14:32 |
| sarnold | good luck :) | 14:32 |
| cpaelzer | Once I have something reviewable I'll again send a PR around to everyone | 14:32 |
| cpaelzer | Going on with the agenda | 14:33 |
| cpaelzer | #topic current component mismatches | 14:33 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 14:33 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 14:33 |
| sarnold | looks like nothing new | 14:33 |
| cpaelzer | agreed | 14:33 |
| cpaelzer | the latest news on fence-agents is that we have uploaded a fix to the one remaining blocker | 14:33 |
| cpaelzer | it is currently held in impish-unapproved | 14:33 |
| ddstreet | o/ | 14:34 |
| cpaelzer | once through there I'll ping for promotion to main | 14:34 |
| ddstreet | hello sorry im late o/ | 14:34 |
| cpaelzer | np ddstreet | 14:34 |
| cpaelzer | ok, nothing new here - going on ... | 14:34 |
| cpaelzer | #topic New MIRs | 14:34 |
| sarnold | cpaelzer: do we care about the amt_ws agent? https://github.com/ClusterLabs/fence-agents/issues/434 may or may not be important | 14:34 |
| 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:34 |
| ubottu | Issue 434 in ClusterLabs/fence-agents "misplaced python 'or' causes dead code" [Open] | 14:34 |
| cpaelzer | here we have a first of a kind in https://bugs.launchpad.net/ubuntu/+source/egl-wayland/+bug/1935082 | 14:35 |
| ubottu | Launchpad bug 1935082 in egl-wayland (Ubuntu) "[MIR] egl-wayland" [Undecided, Confirmed] | 14:35 |
| cpaelzer | this refers to the recently added rules about "testing with special HW" | 14:35 |
| cpaelzer | I didn't want to ake the call alone as interperting a very new rule might be interesting | 14:35 |
| cpaelzer | so I wanted to ask if the statement at | 14:35 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/egl-wayland/+bug/1935082/comments/20 | 14:35 |
| sarnold | I wish tseliot had been more detailed in his responses.. but as a first, it's not so bad. | 14:36 |
| cpaelzer | Rule is | 14:36 |
| cpaelzer | "If no build tests nor autopkgtests are included, and/or if the package requires specific hardware to perform testing, the subscribed team must provide a written test plan in a comment to the MIR bug, and commit to running that test either at each upload of the package or at least once each release cycle. In the comment to the MIR bug, please link to the codebase of these tests (scripts or doc of manual steps) and attach a full log of these | 14:36 |
| cpaelzer | test runs. This is meant to assess their validity (e.g. not just superficial)" | 14:36 |
| didrocks | I agree this fully apply to the testing with special HW rule | 14:36 |
| cpaelzer | The "test plan" is a bit lighter than I'd have hoped | 14:37 |
| didrocks | agreed | 14:37 |
| sarnold | I don't know how to enable KMS, nor how to make sure it is enabled; I don't know what games would work -- what's glxgears on wayland? :) etc | 14:37 |
| cpaelzer | the idea when writing the rule was "if we see an example plan and test log we can be more sure it is actually done" | 14:37 |
| cpaelzer | but in this case not much logs exist as it is all UI | 14:37 |
| cpaelzer | so my question to eventually vote on - is that statement enough or do we want/need to return that for something better (making a bad first case might invite others to be sloppy where it could be better)? | 14:38 |
| slyon | I think we should ask for something better. | 14:39 |
| sarnold | mm, good point | 14:39 |
| slyon | Like some commands of how to check if KMS is enabled, which application to run, etc. (as sarnold suggested) | 14:39 |
| cpaelzer | I'm tending to request something better as well | 14:40 |
| cpaelzer | but I had expressed it in https://bugs.launchpad.net/ubuntu/+source/egl-wayland/+bug/1935082/comments/19 and that didn't help "enough" | 14:40 |
| ubottu | Launchpad bug 1935082 in egl-wayland (Ubuntu) "[MIR] egl-wayland" [Undecided, Confirmed] | 14:40 |
| cpaelzer | would anyone volunteer to help Alberto to add something better in this bug? | 14:40 |
| sarnold | sure | 14:40 |
| cpaelzer | is that the volunteering sarnold? | 14:41 |
| sarnold | yup! | 14:41 |
| cpaelzer | thank you a lot | 14:41 |
| didrocks | I agree that we should have a better test case. As this is trusting the uploader that each upload is carefully tested, not wanting to write it up won’t help and make future uploads trustable IMHO | 14:41 |
| cpaelzer | #action sarnold to contact alberto milone to make a better "special HW test statement" on bug 1935082 | 14:41 |
| meetingology | ACTION: sarnold to contact alberto milone to make a better "special HW test statement" on bug 1935082 | 14:41 |
| ubottu | Bug 1935082 in egl-wayland (Ubuntu) "[MIR] egl-wayland" [Undecided, Confirmed] https://launchpad.net/bugs/1935082 | 14:42 |
| cpaelzer | ok, going on then | 14:42 |
| cpaelzer | #topic Incomplete bugs / questions | 14:42 |
| 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:42 |
| cpaelzer | the recent bumps are fuse (Trevinho was so kind to help all upstremas by providing PRs) | 14:43 |
| cpaelzer | and libportal which didrocks reviewed | 14:43 |
| cpaelzer | nothing that needs immediate further activity AFAICS | 14:43 |
| cpaelzer | #topic Any other business? | 14:43 |
| cpaelzer | nothing from me | 14:43 |
| slyon | nothing here | 14:43 |
| didrocks | nothing either | 14:43 |
| sarnold | nothing from me | 14:44 |
| cpaelzer | ddstreet: I know you are busy, but do you have anything else or a comment ont he backlog? | 14:44 |
| cpaelzer | ok I consider this a no and he also knows where to reach us | 14:44 |
| cpaelzer | closing ... | 14:44 |
| cpaelzer | thank you all! | 14:44 |
| sarnold | thanks cpaelzer, all :) | 14:44 |
| cpaelzer | #endmeeting | 14:45 |
| meetingology | Meeting ended at 14:45:01 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-09-28-14.29.moin.txt | 14:45 |
| slyon | thank you o/ | 14:45 |
| ddstreet | nothing from me | 14:45 |
| sarnold | woot | 14:45 |
| didrocks | thanks! | 14:46 |
| rbasak | o/ | 19:00 |
| * vorlon waves | 19:01 | |
| mdeslaur | o/ | 19:03 |
| vorlon | #startmeeting | 19:05 |
| meetingology | Meeting started at 19:05:06 UTC. The chair is vorlon. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 19:05 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 19:05 |
| vorlon | #topic Apologies | 19:05 |
| vorlon | I haven't seen any on the mailing list, I guess sil2100 and cyphermox are just lost somewhere ;) | 19:06 |
| vorlon | hmm https://wiki.ubuntu.com/TechnicalBoardAgenda seems to have been mangled somewhat, please hold while I look at history | 19:07 |
| vorlon | #topic Action review | 19:07 |
| vorlon | AGREED: MATE is required to resolve the PPA situation by the J release. Otherwise, MATE will not be an official flavour in J. (rbasak, 19:11) | 19:08 |
| rbasak | Looks like I mistakenly copied that as an action but it wasn't an action. | 19:08 |
| vorlon | ok, was going to ask :) | 19:08 |
| vorlon | ACTION: rbasak to communicate the TB's MATE resolution to the MATE flavour leads. | 19:08 |
| rbasak | However, I do have an action to make sure the MATE team know about this, and I haven't done that yet :-/ | 19:08 |
| vorlon | ack, carrying over | 19:08 |
| vorlon | ACTION: formal ratification of third party seeded snap security policy, depends on: | 19:09 |
| vorlon | 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. | 19:09 |
| vorlon | these are carry-over for me | 19:09 |
| vorlon | ACTION: vorlon to reply to seeded snap upload permissions question on list | 19:09 |
| vorlon | also carry-over, though, I've made myself some jira cards for these now so I'm tracking better in one place | 19:09 |
| vorlon | ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which xnox and TB will review, edit, and ratify before we move on to figuring out the next step | 19:09 |
| vorlon | sil2100 not here, so carrying over for him | 19:09 |
| vorlon | ACTION: all TB members to "vote" or explain what they do not like of a proposal on https://pad.ubuntu.com/third-party-repository-requirements | 19:09 |
| vorlon | I've only just started on this today (sorry) - I did leave comments objecting to the very first proposed requirement though ;) would we want to discuss that here? | 19:10 |
| rbasak | I just added a response to your comment. Maybe we can bring that in here now? | 19:11 |
| vorlon | or wait until we have more comments or more TB members present at the meeting? | 19:11 |
| vorlon | happy to discuss now | 19:11 |
| rbasak | I'd like to better understand your reasoning on this point so might as well do that part now at least please | 19:12 |
| vorlon | so, I understand your suggestion that this be an exception only for the browsers (firefox, chromium) because for other seeded snaps, maintained by Ubuntu developers / Canonical employees, it is likely that we want these to be stably maintained | 19:13 |
| vorlon | however, I am not convinced that this should be expressed as a TB policy | 19:13 |
| vorlon | I expect the number of snaps installed by default (which I think is what we're talking about here) is going to be fairly small | 19:14 |
| rbasak | I think that LTSness in the "doesn't massively change" sense is important. I'm not comfortable with packages shipping in a future LTS "switching over" to snaps that don't LTS wily-nily | 19:14 |
| rbasak | Hence my desire for it to be a TB policy. I'm not opposed to maintaining a list of exceptions, much like the TB used to do for MREs. | 19:15 |
| rbasak | And I'm open to non-browser exceptions too, depending. | 19:15 |
| rbasak | Counter-example: recently we had https://bugs.launchpad.net/ubuntu/+source/telegram-desktop/+bug/1942699, which I advocated against for the SRU team, and that was the final team decision (an exception would require a TB approval anyway I think) | 19:16 |
| ubottu | Launchpad bug 1942699 in telegram-desktop (Ubuntu Impish) "SRU: Update Telegram Desktop to 2.9.2" [Undecided, Fix Released] | 19:16 |
| rbasak | Although if that were a snap, it'd be unlikely to be seeded I think | 19:16 |
| vorlon | I think my main concerns with putting this in a TB policy are: 1) how do we express that in a policy that's not confusing, given that the snap experience in general explicitly does not make such committments, and 2) how do we actually gate any of this (because without a gate, the policy will likely be violated sooner or later) | 19:17 |
| rbasak | But a flavour might | 19:17 |
| vorlon | (and granted, there's a lot of policies we'd apply that are specific to default seeded snaps and not part of the snap store generally) | 19:17 |
| rbasak | We already document the requirements for seeded snaps. Why would it be confusing to have this as a requirement? | 19:18 |
| vorlon | right | 19:18 |
| rbasak | Or are you asking how I would define "stable"? | 19:19 |
| vorlon | yeah, I think that's the core of it | 19:19 |
| rbasak | I agree any judgement here is subjective. And the tricky part is that we (the Ubuntu governance structure) won't be gating or deciding on a per-upload basis, unlike SRUs. | 19:20 |
| mdeslaur | I'm a bit conflicted on this one...while I do think leaf desktop applications should be allowed to be updated to new versions, I don't like the idea of something like apache becoming a snap and getting behavioural changes all the time | 19:21 |
| rbasak | So I think it'd have to document the gist of what we mean, trust/rely on the intentions of snap packagers, and deal with issues if they are raised with us after the fact - for example by requiring a subsequent release to drop the seed. | 19:21 |
| rbasak | mdeslaur: while I do think leaf desktop applications should be allowed to be updated to new versions> interesting - I think we are opposed there. | 19:22 |
| rbasak | Well, specifically, leaf desktop applications that are installed by default, I mean. If a user chooses to install a specific snap, then that's something different. | 19:23 |
| vorlon | for another not-entirely-hypothetical example: if bluez were a snap on the desktop, how would we expect a policy around stability to be applied? | 19:23 |
| vorlon | are we going to have a policy with carve-outs for browsers, + hardware enablement, + ... | 19:24 |
| rbasak | I suppose what I want is the ability for an Ubuntu LTS install to avoid changing as much as possible, so users aren't forced into "rolling" any more than they have to be, and any deviation from that is opt-in. That causes me to not want this to happen for default installed apps, since they're not really opt-in. Not possible for firefox of course. | 19:24 |
| rbasak | vorlon: good question. Maybe we can grant a standing exception for anything that would be acceptable under SRU policy? | 19:25 |
| mdeslaur | why would someone want to get a snap installed by default instead of a deb if they can't update versions? | 19:25 |
| vorlon | well - there are some packages explicitly called out under hwe, but I think a number of them wind up being case-by-case decisions by the SRU team; and the SRU team is not in the loop on snap updates | 19:25 |
| mdeslaur | I mean, that's the whole point | 19:26 |
| vorlon | I think both Ubuntu Desktop and Ubuntu Server have a rather confined set of "default installed apps", by design, and that this would not change as a result of snaps | 19:26 |
| vorlon | flavors of course may take a different view | 19:27 |
| vorlon | (cough, Ubuntu Studio isos currently fail to build because the root squashfs is now too large to be a file on an iso9660 fs, cough) | 19:27 |
| rbasak | mdeslaur: can we distinguish users from Ubuntu developers? I think LTS users expect behaviour not to change as much as possible (with pragmatic exceptions). Developers might find it easier to just ship a snap instead of packaging a stable deb - such as in this DisplayCAL example that brought up this entire topic. I don't think a not-stable snap is appropriate in this kind of case - hence my desire | 19:28 |
| rbasak | to not permit it. | 19:28 |
| rbasak | Unless it fits under our normal HWE exception, but that requires behaviour to generally not change. | 19:28 |
| rbasak | Rather than throwing the baby out with the bathwater and allowing "anything goes". | 19:29 |
| vorlon | rbasak: as a path forward, could I suggest you draft some text for what you think the rule should look like, including the appropriate exceptions, and we can have a conversation about what that full rule might look like? | 19:31 |
| vorlon | I think my concern distills down to this being too cumbersome to express the rule accurately and therefore it's overhead that won't improve the outcomes, but I'm willing to give on this | 19:31 |
| rbasak | vorlon: ack | 19:31 |
| rbasak | We can leave the rest of this item until after you've finished reviewing it? | 19:32 |
| vorlon | #action rbasak to draft refined rules for the proposed "stability" requirement for third-party software repositories | 19:32 |
| meetingology | ACTION: rbasak to draft refined rules for the proposed "stability" requirement for third-party software repositories | 19:32 |
| vorlon | sounds good to me | 19:32 |
| mdeslaur | ok | 19:33 |
| vorlon | the next thing on TechnicalBoardAgenda is about displaycal, but I'm not sure if that's a leftover? | 19:34 |
| rbasak | I have a better understanding of your views now FWIW, which will be really helpful. | 19:34 |
| rbasak | I consider the displaycal item blocked on the previous one just discussed. | 19:34 |
| vorlon | ok | 19:35 |
| vorlon | #topic Scan the mailing list archive for anything we missed (standing item) | 19:35 |
| vorlon | last mails on https://lists.ubuntu.com/archives/technical-board/ were from August and have been addressed | 19:36 |
| vorlon | #topic Check up on community bugs (standing item) | 19:36 |
| vorlon | https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard zarro boogs | 19:36 |
| vorlon | #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) | 19:36 |
| vorlon | looks like it should be sil2100 w/ mdeslaur as backup? | 19:36 |
| mdeslaur | ack | 19:37 |
| vorlon | #info Next meeting 2021-10-12 @ 20:00 London time; chair: sil2100, backup: mdesleaur | 19:37 |
| vorlon | #topic AOB | 19:37 |
| vorlon | anything else? | 19:37 |
| mdeslaur | not from me | 19:37 |
| rbasak | Not from me | 19:38 |
| vorlon | #endmeeting | 19:38 |
| meetingology | Meeting ended at 19:38:13 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-09-28-19.05.moin.txt | 19:38 |
| vorlon | mdeslaur, rbasak: thanks! | 19:38 |
| mdeslaur | thanks vorlon, rbasak | 19:38 |
| rbasak | Thank you for chairing, and for everyone's patience on the seeded snap requirements item | 19:38 |
| === genii is now known as genii-core | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
