19:02 <sil2100> #startmeeting Ubuntu Technical Board
19:02 <meetingology> Meeting started at 19:02:22 UTC.  The chair is sil2100.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:02 <meetingology> Available commands: action, commands, idea, info, link, nick
19:02 <sil2100> #topic Apologies
19:02 <sil2100> No apologies for today, but I would like to apologize for missing last meeting - that was quite unexpected from my side
19:02 <sil2100> #topic Action review
19:03 * sil2100 Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns.
19:03 <mdeslaur> I was on vacation last time and forgot about the meeting :P
19:03 <sil2100> I think there was some movement on that during the last meeting, right rbasak?
19:03 <rbasak> I need to follow up with Martin again there I think.
19:03 <rbasak> There was movement, yes, but not since then.
19:04 <sil2100> Ok, so should we leave it as-is until we know more?
19:04 <rbasak> Yes - carry the action for me, please.
19:04 <sil2100> #action Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns.
19:04 * meetingology Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns.
19:05 <sil2100> The two next action items are on vorlon who doesn't seem to be around, so I'll carry them over
19:05 <sil2100> #action formal ratification of third party seeded snap security policy, depends on:
19:05 * meetingology formal ratification of third party seeded snap security policy, depends on:
19:05 <sil2100> #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:05 * meetingology 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:05 <sil2100> Next one is from vorlon as well - did anyone hear any update on that?
19:05 <sil2100> i.e. vorlon to reply to seeded snap upload permissions question on list
19:06 <sil2100> If not, we'll carry it over
19:06 <sil2100> ...let's carry over!
19:06 <sil2100> #action vorlon to reply to seeded snap upload permissions question on list
19:06 * meetingology vorlon to reply to seeded snap upload permissions question on list
19:07 <sil2100> And final one is on me, and sadly this is not done yet - but I have just started drafting a draft some time before the meeting
19:07 <sil2100> So hopefully, pinky promise, there'll be something to review for the next meeting
19:07 <sil2100> #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:07 * meetingology 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:07 <sil2100> #topic Scan the mailing list archive for anything we missed (standing item)
19:08 <sil2100> There are two ML items from June from what I see
19:08 <rbasak> There's two Flatpak related requests
19:08 <sil2100> Not sure if those got handled
19:08 <sil2100> Yeah, let's start with this one: https://lists.ubuntu.com/archives/technical-board/2021-June/002560.html
19:09 <rbasak> I'm tempted to delegate this decision to the security team
19:10 <rbasak> Any reason we shouldn't?
19:10 <rbasak> sarnold: FYI ^
19:10 <sil2100> Sounds fair, I personally don't feel strongly about changing the current status-quo, especially that it's an universe package
19:11 <sil2100> But if the security team feels that Ubuntu would benefit more if we'd change, I guess it's something up for discussion
19:11 <mdeslaur> I think delegating to the security team is fine, unless there is controversy about the decision, in that case, the security team can bring it back to the tech board
19:12 <mdeslaur> sil2100: it's being promoted to main
19:12 <sarnold> thanks rbasak, reading..
19:12 <sil2100> Ah, now I see mention of an MIR
19:13 <sil2100> hm, I must say that for packages we consider 'main' I like the idea of consistency, but I think it's fair to leave the decision to the security team
19:13 <rbasak> Let's ask the security team to provide an opinion in the first instance, at least.
19:13 <mdeslaur> I think it should be consistent too
19:14 <sil2100> Who wants to follow up on that e-mail? To get the security teams professional opinion?
19:15 <mdeslaur> I'd prefer someone else do the follow up
19:15 <sil2100> ;)
19:15 <rbasak> Sure
19:15 <rbasak> to ubuntu-hardened@l.u.c?
19:16 <sil2100> Oh, I didn't even know about such list?
19:16 * mdeslaur didn't either
19:17 <sil2100> rbasak: do you volunteer, or should I take it?
19:17 <sarnold> the one guy who used to use that list stopped writing us questions :(
19:17 <rbasak> I'm volunteering :)
19:17 <sil2100> \o/
19:17 <mdeslaur> rbasak: cc the list, and cc security@u.c please
19:17 <sil2100> #action rbasak to follow up regarding security-team's advice on the flatpak TB request
19:17 * meetingology rbasak to follow up regarding security-team's advice on the flatpak TB request
19:18 <rbasak> mdeslaur: by "the list", you mean ubuntu-hardened@?
19:18 <mdeslaur> yeah
19:18 <rbasak> OK :)
19:18 <sarnold> thanks :)
19:19 <sil2100> What about the other TB ML message from June? Re: https://lists.ubuntu.com/archives/technical-board/2021-June/002559.html
19:20 <sil2100> I didn't read the thread, does it have anything actionable?
19:20 <rbasak> So Erich uploaded displaycal to Impish Unapproved, and it's been sitting there since.
19:20 <rbasak> I don't know what the AAs are expecting - maybe the resolution of this thread?
19:21 <rbasak> (FWIW, IMHO they're right to wait until the thread is resolved)
19:21 <rbasak> I think this is a case where we just need to make a decision.
19:21 <rbasak> Either us, or the AAs, or the release team. The appropriate team is unclear to me.
19:21 <rbasak> So therefore maybe this is a case where the TB should just decide.
19:22 <rbasak> IMHO, the biggest issue is the UX where users usually expect stuff installed by default to remain stable for the lifetime of the release.
19:22 <sil2100> I don't think I have enough context right now, would have to read the whole thread first
19:22 <rbasak> And that expectation would be broken here I think.
19:23 <rbasak> chromium is an exception in this matter, but I don't think DisplayCAL qualifies.
19:23 <sil2100> Ah, so this is the case of a new dummy package but with flatpak as the real source, right?
19:23 <rbasak> Right
19:23 <mdeslaur> yeah, plus it adds a new flatpak repo
19:23 <rbasak> Eickmeyer: o/ ^
19:24 <mdeslaur> which is the thing that I personally don't like and is akin to adding PPAs
19:24 <rbasak> There are lots of open questions here, such as a flavour adding a third party software source by default, etc.
19:24 <sil2100> Yeah, tricky
19:24 <mdeslaur> doing that is the very reason we want mate to change how their store works
19:25 <rbasak> Eickmeyer points out that installing snaps by default, and the chromium deb that installs a snap, is also equivalent to "adding a third party software source".
19:25 <rbasak> However I don't think they're really the same, as I explained in the thread. Lots of differences that impact UX.
19:25 <mdeslaur> we ship with the snap repo preconfigured
19:25 <mdeslaur> the other one is adding a new one, contrary to user expectations
19:26 <sil2100> I mean, the difference is also that we make sure that the snaps that we do preinstall follow a certain level of 'stability', as rbasak already mentioned
19:26 <sil2100> Which I don't think we have the guarantee of with the case of the added flathub.org flatpak repository?
19:27 <rbasak> mdeslaur: I don't see the distinction you're describing. AIUI, Eickmeyer wants to ship with a Flatpak repo enabled by default, and a Flatpak installed, just as Ubuntu ships with the Snap Store enabled by default, and some snaps installed.
19:27 <rbasak> I do agree with what sil2100 just said though.
19:27 <mdeslaur> rbasak: he wants the deb package to enable a new flatpak repo
19:27 <mdeslaur> or am I misunderstanding
19:27 <sil2100> I mean, I would be fine if we just had the guarantee of stability with the new software they install - in one way or another
19:28 <rbasak> mdeslaur: that's just the mechanism. The snapd deb package enables the Snap Store :)
19:28 <rbasak> There's also questions over things like where the package is built, and the ability for Ubuntu developers to be able to override/patch what ships if required.
19:29 <rbasak> eg. if there's a security vulnerability and the upstream Flatpak repo maintainer is absent, then what happens?
19:29 <mdeslaur> Is the producer of the flatpak going to support it on ubuntu for the lifetime of the release?
19:29 <rbasak> In the Snap case, I believe there are arrangements to do with tracks and channels to support that situation.
19:29 <rbasak> mdeslaur: that's another difference. That isn't currently part of the proposal.
19:29 <sil2100> Yeah, so in my opinion it's not a matter of technology here, but a matter of arrangements with the people responsible
19:30 <mdeslaur> rbasak: (re: mechanism): one is installing the snapd software itself, the other is installing an random piece of software (displaycal) and getting a repo added
19:31 <sil2100> So it's not a problem that it's flatpak and from flathub.org, but more like a problem that we don't have arrangements with the people responsible, making sure that the flatpak remains stable and up-to-date with fixes
19:31 <sil2100> Since sure, we don't always have up-to-date universe packages, but Ubuntu developers have the powers to update them if needed
19:31 <sil2100> But here we need to have something arranged so that this still happens
19:31 <rbasak> Right - but also, that the package installed isn't a rolling release.
19:31 <rbasak> That's not what users expect from the average app that ships with Ubuntu by default.
19:32 <mdeslaur> and will that rolling release still support a 5 year old version of ubuntu in 5 years...
19:32 <rbasak> I think we basically have a fairly extensive list of "properties" of the system here, that we think users expect, but just adding this Flatpak will not deliver.
19:32 <sil2100> So personally I wouldn't straight away say 'no' to this proposal, but maybe before saying 'yes' try to get the discussion started on how to handle the maintenance situation from the Ubuntu perspective
19:33 <rbasak> Agreed
19:33 <rbasak> I think we need to enumerate the list.
19:33 <sil2100> If Eickmeyer finds a good way to solve this, we can say 'yes' no problem - I personally, right now, have no such good idea, but maybe Eickmeyer has a better concept!
19:33 <rbasak> And then see what Eickmeyer can come up with to meet those requirements (or negotiate them).
19:34 <sil2100> Ok, do you want to follow up, or maybe you want someone other from the TB to follow up instead?
19:34 <sil2100> (since I completely missed this thread)
19:35 <rbasak> I'm happy to do it, if others feel I'm the best person to tackle a reply!
19:35 <mdeslaur> can we work on that list of requirements?
19:36 <mdeslaur> I mean, can we collaborate on it before it is submitted?
19:36 <rbasak> How should we do that?
19:37 <rbasak> One way might be to do it on-list, making it clear that it's discussion towards a list of requirements rather than a final version? Or would you like to do this somewhere else?
19:37 <sil2100> Makes sense, but I'm not sure if we'd be able to discuss it fully during this meeting
19:38 <mdeslaur> rbasak: perhaps we can discuss it as a side-topic on the tech-board list and once we have a list of requirements we can submit them to the main topic?
19:38 <sil2100> On list is possible, there's also this uh, ugly way of using some shared document first? I know google docs isn't ideal, but maybe there are better technologies (more open)
19:38 <rbasak> Etherpad?
19:39 <sarnold> hey looks like ubuntu's instance is still live :)
19:39 <rbasak> I'm happy whichever way :)
19:39 <sil2100> Oh, etherpad! Been a while since I last used that - maybe that's a good idea?
19:40 <sil2100> Since it's good if each of us has time to think it through and leave some comments
19:40 <rbasak> https://pad.ubuntu.com/third-party-repository-requirements
19:41 <sil2100> Thanks for creating it! Let me add an action item for this for the next meeting
19:42 <sil2100> #action Work on getting a set of requirements for Ubuntu packages that enable third party software repositiories by default - related to a ML entry
19:42 * meetingology Work on getting a set of requirements for Ubuntu packages that enable third party software repositiories by default - related to a ML entry
19:42 <sil2100> Whoops, let me add the link there
19:42 <sil2100> #action ^ https://pad.ubuntu.com/third-party-repository-requirements
19:42 * meetingology ^ https://pad.ubuntu.com/third-party-repository-requirements
19:43 <sil2100> Ok, in the meantime, let us move on
19:43 <rbasak> Apparently it doesn't support apostrophes :-/
19:43 <sil2100> #topic Check up on community bugs (standing item)
19:43 <sil2100> I didn't see any open bugs, so let's move on
19:43 <sil2100> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:44 <sil2100> #info The next chair is mdeslaur, with cyphermox as backup
19:44 <mdeslaur> ack
19:44 <sil2100> Thanks!
19:44 <sil2100> #topic AOB
19:44 <sil2100> ...anything we need to talk about?
19:45 <sil2100> If not, then let us finish up and start working on those requirements, I see rbasak already proposed some!
19:45 <sil2100> So be sure to take a look and write your thoughts/comments
19:45 <sil2100> #endmeeting