| === genii is now known as genii-meeting | ||
| === genii-meeting is now known as genii-core | ||
| === unixlab is now known as nicozdeb | ||
| === nicoz- is now known as nicoz | ||
| === unixlab is now known as nicoz- | ||
| cpaelzer | hiho | 15:29 |
|---|---|---|
| cpaelzer | #startmeeting Weekly Main Inclusion Requests status | 15:29 |
| meetingology | Meeting started at 15:29:52 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 15:29 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 15:29 |
| cpaelzer | ping slyon, didrocks, sarnold, joalif, jamespage for MIR meeting | 15:29 |
| joalif | o/ | 15:30 |
| cpaelzer | no previous logged actions to review | 15:30 |
| didrocks | hey! | 15:30 |
| slyon | o/ | 15:30 |
| cpaelzer | #topic current component mismatches | 15:31 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 15:31 |
| cpaelzer | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 15:31 |
| jamespage | o/ | 15:31 |
| cpaelzer | I see one new thing which is mesa -> llvm-toolchain-13 | 15:31 |
| sarnold | good morning | 15:31 |
| cpaelzer | which is slightly odd since we just had that with postgresql | 15:31 |
| cpaelzer | But either way doko is tasked by mclemenceau to process and promote it | 15:32 |
| cpaelzer | didrocks: worth for you to know I guess | 15:32 |
| didrocks | yeah, if doko is going to promote it, no action I guess? | 15:32 |
| cpaelzer | other than maybe chasing doko - no :-) | 15:33 |
| didrocks | heh :) | 15:33 |
| cpaelzer | eventually it is a new version | 15:33 |
| cpaelzer | that usually isn't even worth any process | 15:34 |
| cpaelzer | so you (didrocks) being an AA might consider promoting it if nothing happens from doko as he might have no time for it | 15:34 |
| cpaelzer | sugegstion: if we see it two more weeks then you could promote it didrocks | 15:34 |
| cpaelzer | #topic New MIRs | 15: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 | 15:34 |
| didrocks | cpaelzer: ack | 15:35 |
| cpaelzer | ok, there are 4 | 15:35 |
| cpaelzer | looking for reviewers for ... | 15:35 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/protobuf-c/+bug/1956617 | 15:35 |
| ubottu | Launchpad bug 1956617 in protobuf-c (Ubuntu) "[MIR] protobuf-c" [Undecided, New] | 15:35 |
| cpaelzer | now signed up by foundations | 15:35 |
| cpaelzer | I could review that | 15:36 |
| cpaelzer | now two by the server team which belong together | 15:36 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1951834 | 15:36 |
| ubottu | Launchpad bug 1951834 in frr (Ubuntu) "[MIR]: frr" [Undecided, New] | 15:36 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/libyang2/+bug/1958293 | 15:36 |
| ubottu | Launchpad bug 1958293 in libyang2 (Ubuntu) "[MIR]: libyang2" [Undecided, New] | 15:36 |
| cpaelzer | it is important to know that FRR is a fork of quaggy which is in main | 15:36 |
| cpaelzer | quagga | 15:36 |
| cpaelzer | volunteers ? | 15:37 |
| didrocks | sounds a little bit big, but I can make some time for it | 15:37 |
| cpaelzer | do you want the lib or frr itself didrocks? | 15:37 |
| didrocks | frr is big, I would like someone else to do the lib if possible | 15:38 |
| didrocks | if not, I will take both | 15:38 |
| cpaelzer | joalif: how about libyang2 for you then? | 15:38 |
| joalif | yes I could do that | 15:38 |
| cpaelzer | and then there is https://bugs.launchpad.net/ubuntu/+bug/1958109 | 15:38 |
| ubottu | Launchpad bug 1958109 in OEM Priority Project "[MIR] v4l2-relayd" [High, In Progress] | 15:38 |
| slyon | I guess that leaves e2l2-relayd for me :) | 15:39 |
| slyon | v4l2-relayd* | 15:39 |
| cpaelzer | yeah | 15:39 |
| cpaelzer | jamespage: if joalif would need help on libyang2 would you be around this week to help? | 15:40 |
| cpaelzer | that way each of us gets something :-) | 15:40 |
| jamespage | yep | 15:40 |
| joalif | thanks :) | 15:40 |
| cpaelzer | great | 15:40 |
| cpaelzer | all assigned then | 15:40 |
| cpaelzer | #topic Incomplete bugs / questions | 15:40 |
| 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 | 15:40 |
| sarnold | hrm, what's the .tar.xz and .dsc files attached to that v4l2-relayd? | 15:40 |
| cpaelzer | sarnold: oO | 15:41 |
| cpaelzer | this isn't even inth e archive yet | 15:41 |
| cpaelzer | the tarballs are probably there to show the full content | 15:41 |
| sarnold | d'oh | 15:41 |
| sarnold | I missed that it wasn't attached to a package | 15:42 |
| cpaelzer | slyon: can probably expect some non matured packaging on that | 15:42 |
| slyon | yea, we might need some more iterations on that one | 15:42 |
| cpaelzer | recent updates on libio-prompt-tiny-perl , rustc and ledmon | 15:43 |
| cpaelzer | ledmon is cancelled | 15:43 |
| cpaelzer | the other two have updates but none needs action by us atm | 15:43 |
| cpaelzer | #topic MIR related Security Review Queue | 15:44 |
| 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 | 15:44 |
| slyon | libio-prompt-tiny-perl should be resolved as of https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/1959004 | 15:44 |
| ubottu | Launchpad bug 1959004 in lintian (Ubuntu) "lintian: remove unused non-main dependency libio-prompt-tiny-perl" [High, In Progress] | 15:44 |
| cpaelzer | good to hear slyon | 15:44 |
| cpaelzer | sarnold: any progress, report of things started or anything else ? | 15:44 |
| sarnold | yes, python-cheroot is in progress, and I started in on adsys before last week, but made no progress on it last week. I'll return to it tonight | 15:45 |
| cpaelzer | awesome | 15:45 |
| cpaelzer | #topic Any other business? | 15:45 |
| cpaelzer | I have ... | 15:45 |
| cpaelzer | we have three PRs for our wiki | 15:45 |
| cpaelzer | https://github.com/cpaelzer/ubuntu-mir/pull/6 | 15:45 |
| ubottu | Pull 6 in cpaelzer/ubuntu-mir "Clarify check-mir and such are not to stay in the post" [Open] | 15:45 |
| cpaelzer | https://github.com/cpaelzer/ubuntu-mir/pull/7 | 15:45 |
| ubottu | Pull 7 in cpaelzer/ubuntu-mir "Update Ubuntu CVE Tracker URL" [Open] | 15:45 |
| cpaelzer | https://github.com/cpaelzer/ubuntu-mir/pull/8 | 15:45 |
| ubottu | Pull 8 in cpaelzer/ubuntu-mir "Add deadlines to a MIR request" [Open] | 15:45 |
| cpaelzer | so far I hae only positive feedback | 15:46 |
| cpaelzer | please take a minute and discuss or agree | 15:46 |
| cpaelzer | I'd then make them live after the meeting (unless we object too much) | 15:46 |
| didrocks | Sorry, haven’t took time for them, will read quickly after meeting | 15:46 |
| * slyon approved PR | 15:46 | |
| slyon | 7 | 15:46 |
| sarnold | ack on all three | 15:47 |
| joalif | they all lgtm too | 15:47 |
| cpaelzer | ok, that seems to be enough | 15:47 |
| cpaelzer | I'll make them active then | 15:48 |
| slyon | all good! | 15:48 |
| cpaelzer | thank you all | 15:48 |
| cpaelzer | anything else for this section? | 15:48 |
| sarnold | nothing from me, thanks for the prioritization meeting last week :) | 15:48 |
| didrocks | nothing either | 15:49 |
| joalif | nothing | 15:49 |
| slyon | nothing. foundations is still working on their priorities :) | 15:49 |
| cpaelzer | slyon: yeah I've seen that swtom still isn't bumped | 15:49 |
| cpaelzer | slyon: could you ensure foundations prios are complete by the end of the week please ? | 15:50 |
| slyon | I do have a meeting with mclemenceau after this meeting, and will discuss with him | 15:50 |
| cpaelzer | of those in the security review queue | 15:50 |
| cpaelzer | ok | 15:50 |
| cpaelzer | then we seem to be done for today ... | 15:50 |
| cpaelzer | o/ | 15:50 |
| sarnold | thanks cpaelzer, all :) | 15:50 |
| slyon | thanks! o/ | 15:50 |
| joalif | thanks all bye o/ | 15:50 |
| cpaelzer | #endmeeting | 15:51 |
| meetingology | Meeting ended at 15:51:44 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-01-25-15.29.moin.txt | 15:51 |
| didrocks999 | (sorry, my connection dropped) | 15:53 |
| === genii-core is now known as genii | ||
| sil2100 | o/ | 20:00 |
| mdeslaur | o/ | 20:00 |
| * vorlon waves | 20:00 | |
| vorlon | https://wiki.ubuntu.com/TechnicalBoardAgenda does not appear to have been updated wrt chair or date - does this mean cyphermox is still supposed to chair? | 20:01 |
| sil2100 | I think he was supposed to chair last time but was absent | 20:03 |
| vorlon | is rbasak still the correct fallback? | 20:03 |
| rbasak | o/ | 20:03 |
| sil2100 | I somehow feel rbasak was the one chairing last week, hm | 20:03 |
| rbasak | Ah did I fail to update the agenda? | 20:03 |
| vorlon | appears so | 20:03 |
| rbasak | I did chair last week, and I nominated someone else to chair if cyphermox was absent again | 20:04 |
| rbasak | It was vorlon | 20:04 |
| rbasak | If you're available please. | 20:04 |
| vorlon | :) | 20:04 |
| vorlon | #startmeeting | 20:04 |
| meetingology | Meeting started at 20:04:33 UTC. The chair is vorlon. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 20:04 |
| rbasak | (just because you're next on the list) | 20:04 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 20:04 |
| vorlon | [topic] apologies | 20:04 |
| vorlon | #topic apologies | 20:04 |
| vorlon | nothing seen on the mailing list | 20:05 |
| vorlon | #topic Action review | 20:05 |
| vorlon | ACTION: formal ratification of third party seeded snap security policy, depends on: (rbasak, 19:06) | 20:05 |
| vorlon | I don't understand this dependency statement | 20:05 |
| rbasak | It relies on the following line | 20:05 |
| vorlon | oh sorry - the latter bit is just timestamp etc and it depends on the next item | 20:05 |
| 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. | 20:06 |
| vorlon | carry-over | 20:06 |
| vorlon | ACTION: vorlon to reply to seeded snap upload permissions question on list | 20:06 |
| vorlon | carry-over | 20:06 |
| 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 | 20:06 |
| sil2100 | Yes | 20:06 |
| rbasak | Sort of mixed up in all of this is to make progress on the requirements pad | 20:06 |
| vorlon | yes it's done? :) | 20:06 |
| rbasak | (previous item) | 20:06 |
| * vorlon nods | 20:06 | |
| sil2100 | So I have the draft in progress, last time I mentioned that I needed some additional info about the state of the OEM archive. We discussed it a bit | 20:06 |
| sil2100 | I was able to get some information | 20:06 |
| vorlon | great | 20:07 |
| vorlon | do you need anything more from us? | 20:07 |
| sil2100 | The things I was previously thinking about was: who has access to the OEM archive (upload rights) and what processes they follow | 20:07 |
| sil2100 | I got some documents from the OEM team and I still need to read them up, but basically the main uploaders are part of this team: | 20:07 |
| sil2100 | https://launchpad.net/~oem-archive/+members | 20:08 |
| vorlon | fwiw, I raised an eyebrow at the response on ubuntu-devel to your recent email | 20:08 |
| vorlon | which says that OEM builds default to release upgrades being disabled | 20:08 |
| mdeslaur | o_O | 20:08 |
| sil2100 | Yeah, I don't remember knowing about that! | 20:08 |
| sil2100 | First time I hear it | 20:08 |
| vorlon | I talked with the Desktop Team about it this morning, they didn't know either | 20:08 |
| rbasak | We did wonder what rules the OEM builds followed. Turns out they exist without any TB input or approval. | 20:08 |
| rbasak | So it seems like exactly how they behave hasn't really ever been reviewed. | 20:09 |
| rbasak | (by anyone wearing an Ubuntu hat) | 20:09 |
| sil2100 | rbasak: I'll check the docs and materials they gave me and update the OEM archive wiki page. The good news is they have quite a formalized release process for their packages | 20:09 |
| rbasak | And perhaps that needs to happen | 20:09 |
| rbasak | I appreciate the progress you're making on this sil2100! | 20:10 |
| sil2100 | Like, there's a lot of automation, every package update has a special LP bug that triggers automation and there are clear steps on how things move from one stage to another | 20:10 |
| sil2100 | But sadly, I didn't wrap my head around it yet | 20:10 |
| sil2100 | For the record, the OEM archive draft is in progress here: https://wiki.ubuntu.com/OEMArchive | 20:10 |
| sil2100 | But no progress yet since last week! | 20:10 |
| vorlon | ok, thanks for the summary/update | 20:11 |
| sil2100 | Let's carry it over for now, but I think at least there's progress | 20:11 |
| vorlon | #topic ACTION: all members to continue discussion at https://pad.ubuntu.com/third-party-repository-requirements | 20:11 |
| vorlon | how's this going? :) | 20:11 |
| rbasak | I'd like to run through where we are per proposed requirement please. | 20:12 |
| vorlon | ok | 20:12 |
| rbasak | I think some are differently blocked and it'd be good to clear them up so I can try and turn them into drafts. | 20:12 |
| rbasak | Prop. req. A: I provided draft wording as we discussed previously. Does vorlon have feedback on that please? | 20:13 |
| rbasak | sil2100 and mdeslaur: am I right in thinking that you don't want to diverge from the user expectation of stability, and therefore are in favour of the proposal if we can figure out details? Or something else? | 20:14 |
| vorlon | just trying to suss out ordering of the comments in that etherpad; oh to be doing this in git (or even google docs) | 20:14 |
| rbasak | Yeah I regret using the pad. If everyone's fine with it I can migrate to Google Docs. | 20:15 |
| rbasak | (but cyphermox isn't here) | 20:15 |
| mdeslaur | rbasak: I don't think it is up to make that decision. But I am in favour of the status quo of the proposal | 20:15 |
| vorlon | I don't think you need to mention channel there, "the snap presented to Ubuntu users" encompasses this | 20:15 |
| mdeslaur | s/up to/up to us/ | 20:15 |
| rbasak | vorlon: removed, thanks | 20:15 |
| vorlon | rbasak: otherwise I think it looks good, captures the intent, and of course we know up front the browser gets an exception | 20:16 |
| rbasak | mdeslaur: could you add yourself to "Support:" in that case please? Or do I misunderstand? | 20:16 |
| rbasak | And same to vorlon :) | 20:17 |
| vorlon | ack | 20:17 |
| vorlon | as it happens I was just looking at seeded snaps on the focal desktop today, due to fixing a livecd-rootfs bug | 20:17 |
| mdeslaur | ok, added | 20:17 |
| vorlon | would it be worth talking about what's currently there? | 20:17 |
| mdeslaur | (and look, my colour changed) | 20:17 |
| rbasak | vorlon: you mean in terms of which packages will need an exception? | 20:18 |
| vorlon | yes | 20:18 |
| vorlon | particularly as, uh, some of the dependency snaps have changed since 20.04 release | 20:19 |
| rbasak | I suppose in particular we should understand if there are any packages that currently have a de-facto exception that we would like to withdraw. | 20:19 |
| rbasak | sil2100: your opinion please on the status quo? | 20:20 |
| sil2100 | Yeah, a discussion with seeded snap owners might be helpful here | 20:20 |
| vorlon | 20.04.3 shipped with gnome-3-34-1804; 20.04 daily now has gnome-3-38-2004 | 20:20 |
| vorlon | fwiw | 20:20 |
| vorlon | so I'm sure gnome-3-34-1804 is very stable :P | 20:20 |
| sil2100 | Since my worry was that basically the expectatio of snaps is that they can be quickly deployed and updated, so maybe some users actually expect snaps to be the newest version around always | 20:20 |
| rbasak | In order to make progress, I actually think I'd prefer to see the general case agreed upon, and then worry about specific cases and exceptions later. | 20:20 |
| vorlon | ack | 20:20 |
| rbasak | sil2100: but they don't know it's a snap. It's there by default (for example). | 20:21 |
| sil2100 | But thinking about it more I guess let's just try keeping this standard, maybe by requiring the usage of per-release tracks | 20:21 |
| rbasak | And if they want to opt-in to always-update, then that's usually available to opt-in to. | 20:22 |
| sil2100 | Ok, added my +1 on that then | 20:22 |
| rbasak | Thanks | 20:22 |
| sil2100 | True! | 20:22 |
| rbasak | So prop. req. B next | 20:22 |
| sil2100 | Valid point, they can just switch tracks then | 20:22 |
| rbasak | I think we have general support, so maybe this is just an action for me to draft the wording for further discussion. | 20:22 |
| rbasak | Any other comments? | 20:22 |
| rbasak | (on how to proceed) | 20:23 |
| sil2100 | +1 | 20:23 |
| rbasak | And same for C and D. | 20:23 |
| sil2100 | This is something that was bothering us at the release team since ages, requirement B | 20:23 |
| sil2100 | Even such simple things as opening a branch or promoting some snap always required going back and forth with the owners of the snap | 20:24 |
| vorlon | sil2100: your 'support' on B has a footnote though? | 20:24 |
| sil2100 | I think I generally agree, I think my footnote was just about having power for selected subsets of users | 20:26 |
| vorlon | so do you want language amended / fleshed out here to capture this? | 20:27 |
| mdeslaur | do we want to be able to override ownership if the publisher is unresponsive, or do we want to have rights from the get go? | 20:28 |
| sil2100 | Just specifying that it's not just about the uploading, but also about promoting from channel to channel - but I'd say this would have to be limited to say release-team for given tracks | 20:28 |
| sil2100 | Tracks/branches | 20:28 |
| sil2100 | But maybe that's overcomplicating things, as this would require changes to the store possibly | 20:29 |
| vorlon | well - to be clear, my assumption is that we are ONLY guaranteed to have rights to override the per-Ubuntu-release channels | 20:29 |
| rbasak | mdeslaur: I don't mind as long as it's possible, and to make progress I'm trying to get consensus on the requirement first, over how exactly it must be implemented. | 20:29 |
| mdeslaur | ok | 20:29 |
| rbasak | (and then we can approve specific implementations later) | 20:29 |
| vorlon | needing the ability to update firefox on the latest/stable/ubuntu-22.04 channel definitely doesn't mean we get to update latest/stable | 20:30 |
| mdeslaur | right | 20:32 |
| vorlon | and the snap store permissions model (i.e. no such thing as groups/teams) means that granting the release team prior access to open/close channels isn't a good solution either | 20:32 |
| rbasak | Any further discussion on B? | 20:33 |
| mdeslaur | ok, anything else about B? | 20:33 |
| vorlon | sil2100: so my $.02, I'm sensitive to the frustrations of the release team (I, too, have been annoyed by image builds blocked at release opening due to missing snap channels), but I don't think there's anything we should change here in the TB requirements | 20:33 |
| sil2100 | All good here now | 20:34 |
| rbasak | Anything to say on C or D, or with the general agreement we have are we good to leave me to draft those? | 20:34 |
| sil2100 | Yeah, I think it's okay as is, we can think of a way to fix the channel management problem some other time | 20:35 |
| vorlon | I'm good w/ C, D | 20:35 |
| mdeslaur | I'm good with C as long as security updates and testing is mentioned | 20:36 |
| sil2100 | Yeah, I think the only comment was to maybe include req G as part of C? | 20:36 |
| rbasak | I'm not sure I feel the need to require G. | 20:37 |
| rbasak | How do others feel about this? | 20:37 |
| mdeslaur | as long as testing is mentioned in C, we can get rid of G | 20:37 |
| rbasak | Ubuntu membership would probably be granted to anyone consistently maintaining a package and meeting our requirements anyway, I think? Ie. fulfilling C. | 20:38 |
| vorlon | Ubuntu membership via the DMB, or otherwise? | 20:38 |
| rbasak | Otherwise - via one of the regional boards. | 20:38 |
| vorlon | ok | 20:39 |
| rbasak | Because it'd be a "signifcant and sustained contribution to Ubuntu" to be doing C. | 20:39 |
| vorlon | one question that comes to mind: do we expect them to have agreed to the Ubuntu Code of Conduct, which is a condition of membership? | 20:39 |
| rbasak | I'm not sure I understand the relevance of anything being DMB-approved here. What would their acceptance criteria for an application be? | 20:39 |
| vorlon | I don't think it is relevant to be DMB approved, I just don't have much visibility on the regional board process | 20:40 |
| rbasak | That's a good point. | 20:40 |
| rbasak | Maybe CoC acceptance should be a hard requirement. | 20:40 |
| mdeslaur | +1 | 20:40 |
| rbasak | What if we added that to C? | 20:40 |
| sil2100 | So Ubuntu membership as a requirement then? This would mean CoC being signed and having presence in the Ubuntu ecosystem | 20:40 |
| vorlon | I would feel more strongly about that if the Ubuntu CoC had been refreshed in the past 15 years :) | 20:40 |
| rbasak | It's a good starting point though. | 20:41 |
| vorlon | I know it's me that raised the question, but I'm +0 and will go with the group's consensus on CoC | 20:41 |
| mdeslaur | adhering to the CoC, and the fact that the CoC is outdated are two different things | 20:41 |
| rbasak | So people who can push snaps to users who receive them by default must have signed the CoC, and their work qualifies under the work required for Ubuntu membership. But no further requirement (ie. no DMB involvement). | 20:42 |
| sil2100 | +1, sounds good I think? | 20:42 |
| rbasak | Let me add that quickly. | 20:42 |
| mdeslaur | +1 from me | 20:42 |
| rbasak | Lines 48-50 added. | 20:44 |
| rbasak | Is that consistent with everyone's agreement? | 20:44 |
| mdeslaur | yep | 20:44 |
| rbasak | We might need to ask the CC to ratify the membership bit but I don't see a problem with that happening. | 20:44 |
| vorlon | sorry, going to quibble a bit on the mechanics of the snap store - "people who can upload the package", or "people who publish to the Ubuntu channels"? | 20:45 |
| rbasak | "People who publish to the Ubuntu channels" is what I meant. | 20:45 |
| vorlon | ok | 20:45 |
| rbasak | So if you're at Mozilla publishing to edge, you don't need to care. | 20:45 |
| vorlon | right, precisely the case I was thinking of | 20:45 |
| rbasak | I've amended it in a hurry; I'll make the wording pretty when I write up the draft properly. | 20:47 |
| rbasak | If we're done with C? | 20:47 |
| vorlon | yes please | 20:47 |
| mdeslaur | yes | 20:47 |
| rbasak | Any comments on D? I assume this is uncontroversial and we can move on? | 20:47 |
| vorlon | yes | 20:47 |
| mdeslaur | no comment on D | 20:47 |
| rbasak | On E, I think I've failed to define it clearly, and it's probably better to focus on the others for now. | 20:47 |
| mdeslaur | agreed | 20:48 |
| rbasak | The telemetry/phone-home example does bother me a little, but we can come back to it. Notably we can always patch thanks to requirement B, and I think that's an example of the catch-all ability the TB will be able to have thanks to B, which means that we can defer consideration of that type of thing. | 20:48 |
| rbasak | F and F2 are also I think basically uncontroversial? | 20:49 |
| mdeslaur | I would like for F to simply say launchpad instead of hinting that there's a process to get a build farm trusted | 20:50 |
| vorlon | I tend to agree | 20:50 |
| sil2100 | +1 | 20:51 |
| rbasak | I'm sort of +0, but I suppose it doesn't matter then :) | 20:51 |
| rbasak | I've added a comment | 20:52 |
| rbasak | And I'll draft accordingly. | 20:52 |
| rbasak | Anything else on F or F2? | 20:52 |
| vorlon | nothing from em | 20:53 |
| vorlon | me | 20:53 |
| mdeslaur | not form me | 20:53 |
| mdeslaur | *from | 20:53 |
| sil2100 | All good | 20:53 |
| vorlon | well - do people agree with my comment on f2? | 20:53 |
| rbasak | More or less. | 20:53 |
| mdeslaur | that would be ideal | 20:53 |
| vorlon | ok | 20:53 |
| mdeslaur | but I'm ok with an alternative | 20:53 |
| rbasak | I don't know about the binary itself, because that seems circular. | 20:53 |
| sil2100 | It's not a hard requirement for me, but certainly would be a nice touch | 20:53 |
| mdeslaur | as long as it's something documented | 20:53 |
| rbasak | You can't do that from a deb binary for example. | 20:53 |
| vorlon | the deb control file says the source package name | 20:54 |
| vorlon | and snap meta.yaml has fields for this sort of thing I believe | 20:54 |
| sil2100 | I think you can in a sense, there's the copyright file as well which states the source | 20:54 |
| vorlon | we just need to insist they be used | 20:54 |
| mdeslaur | oh, if there are fields, then yes, they should be used | 20:55 |
| rbasak | I think what you're saying is: if I have a snap binary, the machinery that supplied it (store/Launchpad) must be able to map it back and provide the build information/logs with the metadata I have | 20:55 |
| mdeslaur | that sould be a requirement | 20:55 |
| rbasak | If so, then +1 | 20:55 |
| rbasak | (to some reasonable time limit) | 20:55 |
| vorlon | mdeslaur: I mean, if there AREN'T fields then that's a gap we should address with the snapd/snapcraft teams - my understanding is that it's specified but I wouldn't be able to tell you the field name off hand | 20:56 |
| mdeslaur | yeah | 20:56 |
| mdeslaur | an end user should be able to find the build information/logs | 20:57 |
| rbasak | We're nearly out of time. | 20:58 |
| rbasak | G is dealt with by having been adjusted and adopted into C. | 20:58 |
| mdeslaur | we only have H left | 20:58 |
| rbasak | I'm not sure what to do about H. | 20:58 |
| vorlon | H was about trust anchors of the third-party repository | 20:58 |
| vorlon | i.e. no we won't trust the flatpak store which has a trust anchor owned by a different entity | 20:59 |
| vorlon | (flathub) | 20:59 |
| mdeslaur | I don't want pre-seeded snaps to come from a store that we don't own the trust of | 20:59 |
| rbasak | Ah. | 21:00 |
| vorlon | if we scope this to "seeded snaps" then H may be unneccessary in practice because this policy is encoded in the snapd binary | 21:00 |
| rbasak | So F is currently "package is built on a build farm that is trusted by the Ubuntu project" | 21:00 |
| rbasak | What if that's changed to "package is built *and published from* infrastructure that is trusted by the Ubuntu project"? | 21:00 |
| mdeslaur | yeah, that could be added to H | 21:01 |
| rbasak | And s/Ubuntu project/Launchpad and Snap Store/ based on earlier discussion? | 21:01 |
| vorlon | just as I think it's best to be explicit that Launchpad is the build farm we trust, I think it's best to be explicit about our policies as a community about what publishing infrastructure we trust | 21:01 |
| mdeslaur | sorry, I mean that could be added to F | 21:01 |
| mdeslaur | but I tend to agree vorlon, those are two different things | 21:02 |
| vorlon | we are at time | 21:02 |
| vorlon | how do we want to proceed? | 21:02 |
| mdeslaur | ok I see it's being added to F (by rbasak I presume) | 21:03 |
| rbasak | I tried that but if you disagree we can take it out | 21:03 |
| rbasak | Maybe defer further discussion to the next meeting? We've made plenty of progress and I have a lot of drafting to do. | 21:03 |
| vorlon | ok | 21:03 |
| mdeslaur | vorlon: so specifying launchpad and snap store would be ok for you? | 21:03 |
| mdeslaur | ok, we can defer | 21:03 |
| vorlon | mdeslaur: yes | 21:04 |
| vorlon | #topic scan the mailing list archive for anything we missed | 21:04 |
| rbasak | There is a private thread that needs attention | 21:04 |
| vorlon | #link https://lists.ubuntu.com/archives/technical-board/2022-January/thread.html | 21:04 |
| vorlon | nothing there - but what rbasak says | 21:04 |
| vorlon | (on my todo list for this afternoon) | 21:04 |
| rbasak | OK thanks. I'll wait for vorlon on that one then. | 21:04 |
| vorlon | #topic check up on community bugs | 21:04 |
| vorlon | #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard | 21:05 |
| vorlon | nothing to see there | 21:05 |
| vorlon | #topic Select a chair for the next meeting | 21:05 |
| vorlon | cyphermox gets to keep first billing, with sil2100 as backup | 21:05 |
| vorlon | sil2100: provided that's ok / you have no conflicts | 21:05 |
| * xnox ponders what i can do to stop being pinged by TB every time they have a meeting | 21:06 | |
| mdeslaur | change your nick | 21:06 |
| vorlon | hahahaa | 21:06 |
| vorlon | #agreed next meeting 2022-02-08 20:00 London time, chair: cyphermox, backup: sil2100 | 21:07 |
| meetingology | AGREED: next meeting 2022-02-08 20:00 London time, chair: cyphermox, backup: sil2100 | 21:07 |
| vorlon | #topic aob | 21:07 |
| vorlon | just in case - anything? | 21:07 |
| mdeslaur | *crickets* | 21:07 |
| vorlon | #endmeeting | 21:07 |
| meetingology | Meeting ended at 21:07:54 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-01-25-20.04.moin.txt | 21:07 |
| vorlon | thanks, all! | 21:07 |
| mdeslaur | thanks vorlon, thanks everyone! | 21:07 |
| vorlon | and particular thanks to rbasak for driving the policy | 21:08 |
| mdeslaur | yes! | 21:08 |
| rbasak | You're welcome and thank you for chairing! | 21:08 |
| sil2100 | o/ | 21:08 |
| sil2100 | Thank you! | 21:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
