19:05 <mdeslaur> #startmeeting
19:05 <meetingology> Meeting started at 19:05:43 UTC.  The chair is mdeslaur.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:05 <meetingology> Available commands: action, commands, idea, info, link, nick
19:05 <mdeslaur> [topic] Apologies
19:05 <mdeslaur> no apologies
19:06 <mdeslaur> [topic] Action review
19:06 <mdeslaur> "Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. "
19:06 <mdeslaur> Wimpy ^
19:07 <mdeslaur> I'm trying to remember, didn't someone volunteer to get in touch with the mate team about that?
19:07 <rbasak> I did manage to speak to Martin very briefly on IRC
19:08 <mdeslaur> did anything come out of it?
19:08 * rbasak is looking for the log
19:08 <rbasak> Can we come back to it in a moment?
19:09 <mdeslaur> sure, let's move on in the meantime
19:09 <mdeslaur> orlon 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 <mdeslaur> whoops
19:09 <mdeslaur> s/orlon/vorlon/
19:09 <vorlon> carry over
19:09 <mdeslaur> and "vorlon to reply to seeded snap upload permissions question on list "
19:09 <vorlon> fwiw there are some developments that suggest we might get some more work done on it soon, as firefox is moving to a snap
19:10 <mdeslaur> ok
19:10 <mdeslaur> "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:10 <vorlon> so I suspecct I will have fewer excuses for it not getting my attention
19:10 <mdeslaur> he's not here, so let's carry that one over
19:10 <cyphermox> vorlon: it's long carried over, will that move as well, pushed by firefox (rebuildability) ?
19:11 <vorlon> cyphermox: I think so
19:11 <cyphermox> ack
19:11 <mdeslaur> "rbasak to follow up regarding security-team's advice on the flatpak TB request "
19:11 <rbasak> I did request the security team's input
19:11 <rbasak> Not had a reply
19:12 <mdeslaur> hrm, I think seth discussed it, but I don't think he officially answered...he's on vacation this week, so let's wait
19:12 <mdeslaur> "Work on getting a set of requirements for Ubuntu packages that enable third party software repositiories by default - related to a ML entry "
19:13 <vorlon> was this a group action?
19:13 <vorlon> I hadn't seen any mailing list replies after my belated one
19:14 <vorlon> not sure if I killed the mood by pointing out he's better off repackaging as a snap than waiting for a flatpak policy?
19:14 <rbasak> IIRC, at a previous meeting we concluded that we (the TB) could come with a set of requirements and communicate it back
19:14 <rbasak> And we started working on that on the pad
19:14 <vorlon> ah right
19:15 <mdeslaur> I think vorlon captured the main criteria that really is the first step, which is "one thing we have been consistent about in
19:15 <mdeslaur> the past when enabling additional repositories by default in flavors has
19:15 <mdeslaur> been maintaining Canonical as a single root of trust"
19:16 <rbasak> I've found the log about MATE/Boutique when we're ready
19:16 <rbasak> I think it'd be helpful to enumerate the requirements still
19:16 <cyphermox> I will have an AOB item later
19:16 <mdeslaur> I don't think there's any reason to work on more criteria if that first one can't be met by DisplayCal
19:18 <rbasak> Maybe, as a compromise, we could summarise the other points raised, but make it clear that they aren't ratified? To provide an idea of what might be required, but to save us the effort of continuing if DisplayCal isn't going to meet them anyway.
19:18 <mdeslaur> I'd be ok with that
19:19 <mdeslaur> cyphermox, vorlon: thoughts?
19:21 <cyphermox> well I agree on preparing a set of requirements ahead of time even if they're not firmed up
19:21 <cyphermox> basically, getting the discussion rolling
19:21 <rbasak> https://pad.ubuntu.com/third-party-repository-requirements is what we have right now
19:21 <cyphermox> yup
19:21 <rbasak> I think a couple of those requirements aren't currently met for snaps
19:22 <rbasak> "Proposed requirement: the package is maintained by someone with Ubuntu developer membership" - not a requirement for chromium snap maintenance I think?
19:22 <rbasak> and "behaviour will remain "stable" for the lifetime of an Ubuntu release. It is not to be on a "rolling release" from the users perspective" contradicts a statement at https://wiki.ubuntu.com/UbuntuSeededSnaps
19:25 <mdeslaur> which statement does that contradict?
19:27 <cyphermox> behavior remaining stable; typically that meant no new features for debs
19:27 <rbasak> The Snap Store ecosystem empowers snap publishers to make their own  decisions about how and whether to backport security fixes to stable  releases vs. updating the package in the channel to a new upstream  version.  We accept this model as well for installed-by-default snaps,  with the understanding that the publisher of each of these snaps is  expected to deliver a good experience to their users."
19:28 <mdeslaur> that same page also says "Including software in the default install of Ubuntu implies a certain commitment to handle upgrades cleanly and to provide continuity of behavior across updates within the stable release."
19:28 <rbasak> FWIW, that page isn't ratified either
19:28 <rbasak> (AIUI)
19:29 <rbasak> It would be nice IMHO to get this all properly squared off.
19:29 <rbasak> More important now that community members might feel that they don't have agency in the project by being measured differently for what they want to achieve.
19:30 <rbasak> (with a real world request, rather than a hypothetical)
19:31 <vorlon> rbasak: "maintained by someone with Ubuntu developer membership" - yes, I don't think that had come up in those specific terms in the past when talking about snaps; we had talked about ensuring there was a path for the community to take over, but that where upstreams were maintaining app packages they should have autonomy
19:32 <mdeslaur> my thought there was that the package would be maintained by someone who has a vested interest in Ubuntu...if someone is maintaining a snap or a flatpak and doesn't care about testing it on Ubuntu, I don't see how we could possibly use it
19:32 <vorlon> likewise, regarding "stability": the vision here was that we enable easy and secure delivery of the upstream experience, even where that differs from traditional Ubuntu SRU standards
19:32 <mdeslaur> requiring developer membership seemed like an appropriate requirement to me
19:33 <mdeslaur> so I think it's going to take a while to come up with requirements we all agree with...meanwhile, we have someone waiting for DisplayCal
19:34 <vorlon> mdeslaur: if this is an upstream development team who maintains the package collectively, based on the view that snaps or flatpaks are a way to deliver their software to the entire Linux ecosystem without having to deal with individual distributions (which is basically the sales pitch for both of these packaging formats), what would be the expectation here? Ubuntu developer membership for each
19:34 <vorlon> member of the upstream team?
19:35 <mdeslaur> I don't know
19:35 <vorlon> ok
19:35 <mdeslaur> I don't think requiring ubuntu membership is reasonable for an upstream
19:35 <mdeslaur> but then again, I don't think having upstreams deliver their software directly to users is reasonable either, so what do I know :)
19:36 <mdeslaur> I just don't want us to seed something that the packager is going to respond "I don't care about ubuntu" to any issue that comes up
19:38 <rbasak> That seems reasonable.
19:39 <mdeslaur> In this particular case, unless I'm mistaken, the person requesting that DisplayCal be seeded isn't the packager, so how do we make sure the packager there is even interested in making sure Ubuntu is a first-class citizen
19:39 <rbasak> To make progress, I wonder if we can split the proposed requirements into a few categories.
19:39 <rbasak> Some we might agree unanimously
19:40 <vorlon> well, from my perspective flathub as a whole is a non-starter, so then what
19:40 <rbasak> Some I think contradict UbuntuSeededSnaps, and so I think are either invalid or need adjusting or UbuntuSeededSnaps, so whichever way cannot be ratified by us right now
19:40 <rbasak> Some I think we don't necessarily agree on ourselves
19:40 <cyphermox> why does it need to be seeded in the first place? what does it solve that can't work by someone installing it on their own if it's available?
19:41 <rbasak> vorlon: I don't think that we can use your statement as-is. Is it worth going through five whys, or not?
19:41 <rbasak> cyphermox: I think Eickmeyer's position is that it's important that it's there on Ubuntu Studio by dfeault
19:41 <vorlon> rbasak: which statement? the one on the mailing list?
19:41 <mdeslaur> I think one of the categories can be "Default repositories"
19:42 <rbasak> vorlon: "from my perspective flathub as a whole is a non-starter"
19:42 <vorlon> rbasak: because it's an additional root of trust
19:42 <rbasak> mdeslaur: I think that's a second dimension
19:42 <Eickmeyer> rbasak: It would be nice (recently had an inquery about it), and I'm running into roadblox with making a snap.
19:42 <Eickmeyer> *roadblocks
19:42 <rbasak> vorlon: oh, OK. So you have a separate requirement there I think. "Canonical must be the root of trust"
19:42 <rbasak> I'll add that.
19:43 <rbasak> Though it sort of overlaps with "must be built on infrastructure we trust"
19:43 <rbasak> Let me label them
19:43 <cyphermox> rbasak: I guess, but seeded packages/snap are basically a showcase of what's nice, or things that are absolutely required for systems to work. DisplayCAL is nice, but it's not necessarily useful to the vast majority of users (ie. it's good for graphics, it's not really useful if you're trying to make sound effects, music, etc.)
19:43 <mdeslaur> root of trust of distribution isn't the same as where it was built
19:44 <mdeslaur> those are two separate things, but related
19:45 <rbasak> cyphermox: I think that's for the flavor leads to decide though. It's not really for the TB. But what we need to do is enable (by setting the expectations and requirements) flavors to be able to seed what they think is appropriate.
19:45 <vorlon> rbasak: +1
19:45 <cyphermox> rbasak: oh, for sure, but I mean if you're trying to decide seeding in general vs. the case
19:45 <vorlon> (that it's the flavor leads' decision)
19:45 <mdeslaur> I agree with rbasak, not our decision
19:46 <cyphermox> and if the publisher doesn't appear to care about Ubuntu, why should Ubuntu care about the publisher?
19:46 <cyphermox> I'm not saying otherwise, I liked displaycal :P
19:46 <rbasak> I think this is a pretty nuanced question.
19:46 <rbasak> For example we ship calibre as a deb, contrary to upstream's desire there.
19:46 <vorlon> cyphermox: I'm not sure the point you're making regaring caring
19:47 <cyphermox> but calibre has Ubuntu developers preparing the package
19:47 <rbasak> We presumably think it's OK because it's permitted by the licensing and we're in control of its distribution when users consume it from us
19:47 <cyphermox> vorlon: I'm trying to paint the picture of having a committed maintainer for something
19:48 <mdeslaur> The scenario we don,t want is to seed something and for it to stop working because the packager doesn't care about Ubuntu
19:48 <cyphermox> yep
19:48 <rbasak> So what I'm saying is that it meets proposed requirement B.
19:48 <rbasak> But some snaps also meet proposed requirement B, and if a DisplayCal flatpak can be made to meet that requirement too, then that might be OK.
19:48 <cyphermox> yes
19:48 <rbasak> This might mean that it can't be shipped via Flathub
19:49 <rbasak> But I don't want to dictate that. I want to specify what we need, which I think is better stated in B
19:49 <mdeslaur> requirement B is the fail-safe, I want a requirement where the developer is involved and agrees that their package is going to be seeded
19:49 <rbasak> mdeslaur: but we don't do that with any other deb package in the archive
19:50 <rbasak> (eg. calibre)
19:50 <mdeslaur> sure we do, the ubuntu developers group
19:50 <mdeslaur> the debs in the archive are there because ubuntu developers agree that they should be
19:51 <rbasak> OK, so if Ubuntu Studio "fork" the Flatpak package, and ship it still as a Flatpak but from somewhere else, and agree that this fork is going to be seeded, would you be happy with that?
19:51 <mdeslaur> oh sorry, I just noticed I said "developer" when I meant "packager"
19:52 <cyphermox> how do you ensure the builds happen on trusted infrastructure?
19:52 <mdeslaur> If the ubuntu studio team is taking over packaging, then yes, I'd be ok with that
19:52 <mdeslaur> (assuming we had a canonical-controlled flatpak repo and build system)
19:52 <rbasak> mdeslaur: define "taking over". We don't do that for packages we autosync from Debian
19:52 <cyphermox> fork
19:53 <rbasak> cyphermox: builds happening on trusted infrastructure is requirement F
19:53 <cyphermox> rbasak: yes, I know
19:53 <mdeslaur> rbasak: we "take over" packages we sync from debian
19:53 <mdeslaur> rbasak: debian no longer maintains the packages in ubuntu
19:53 <rbasak> I think that's a technicality
19:53 <cyphermox> rbasak: I was basically saying the same as mdeslaur, "assuming canonical-controlled flatpak repo and build system")
19:54 <vorlon> rbasak: fork and ship elsewhere> in principle yes, but that means getting a separate flatpak store signed by Canonical, which realistically isn't going to happen for one package, so what's the point in the end?
19:54 <rbasak> What matters is that someone is committed to be able to intervene on behalf of users, without users needing to take action themselves.
19:54 <rbasak> Which is requirement B, and not a separate thing
19:54 <rbasak> vorlon: I'm just saying that between B and F I think we have this subthread covered
19:54 <vorlon> it's good to know what our principles are, but at some point we're spending times on unrealistic generalized hypotheticals
19:54 <mdeslaur> so if the packager won't fix an ubuntu-specific bug, we override the repo?
19:55 <rbasak> mdeslaur: I propose that it be a requirement that this is something the Ubuntu project be in a position to do
19:55 <mdeslaur> I have a hard-stop in 5 minutes, unfortunately
19:55 <rbasak> Whether it happens or not is a separate matter
19:56 <mdeslaur> I don't think that's enough. I think it's important that the publisher agrees that their package is seeded in Ubuntu.
19:56 <rbasak> AFAICT, Ubuntu Studio would effectively be the "publisher", and so that requirement is met by default.
19:57 <rbasak> There is no technical difference between that, and a fork.
19:57 <vorlon> can we agree next steps?
19:57 <rbasak> Because if requirement B is met, Ubuntu Studio can take over at any time, just like any deb package in universe.
19:57 <mdeslaur> ok, I don't see us resolving this any time soon, each of these points is going to require discussion.
19:57 <vorlon> it's a good discussion, but we're obviously not converging in 3 minutes
19:57 <mdeslaur> the only thing I think we can agree to is requirement H
19:57 <vorlon> (and there was an AOB item?)
19:57 <cyphermox> yes, it's actually quite simple
19:58 <mdeslaur> unless someone objects to H
19:58 <rbasak> No objection, but I think H needs a clearer definition
19:58 <rbasak> (and therefore I'm not sure about it pending that definition)
19:58 <cyphermox> could we possibly put all the different threads of discussion in bugs or something so it's easier to get back state on everything here, and see progress between meetings, rather than having to re-read ML threads, find links again from IRC logs, etc.?
19:59 <cyphermox> it's an idea, not necessarily the exact solution
19:59 <mdeslaur> ok, so we can't respond to the DisplayCAL issue today then.
19:59 <rbasak> I was hoping people would use the pad for discussion
19:59 <cyphermox> not just this particular discussion
19:59 <mdeslaur> so let's continue working on the pad
19:59 <rbasak> (though FWIW the pad is awful and doesn't let me punctuate)
19:59 <vorlon> :)
20:00 <rbasak> I'd like to give others a task please. If you don't support a particular proposed requirement, please comment and explain why, to help start the discussion there
20:00 <vorlon> +1
20:00 <cyphermox> aye
20:00 <mdeslaur> everyone must spend some time in the pad this week
20:01 <mdeslaur> ok, let's move on
20:01 <mdeslaur> [topic] Mailing list archive
20:02 <mdeslaur> there's the sunset backports thread, but it looks like some folks stepped up
20:02 <mdeslaur> (I think that's what I read this week)
20:02 <rbasak> I don't think any action is needed on that right now. It seems to be proceeding well without TB intervention and nobody has requested TB intervention to the current course of action AFAICT.
20:02 <mdeslaur> ok
20:03 <mdeslaur> there's rbasak's post about inconsistent password prompts in update-manager
20:03 <mdeslaur> perhaps that should be a bug assigned to the security team?
20:03 <rbasak> I did get the owner of ~ubuntu-backports changed to ~techboard. I assume that's uncontroversial
20:03 <rbasak> Is it a bug?
20:03 <rbasak> I was asking the question
20:03 <mdeslaur> it's not a bug, that's the way it was designed
20:04 <mdeslaur> but perhaps it should be revisited now that there are a lot more kernel updates
20:04 <rbasak> I mean: is it something we need to change?
20:04 <mdeslaur> when it was done that way, there were fewer kernel updates, so most updates never asked for a password
20:04 <mdeslaur> I do agree that it's weird and should probably be changed
20:05 <mdeslaur> or at least discussed again
20:05 <rbasak> OK I can happily file a bug then
20:05 <mdeslaur> IIRC, the original design was a compromise between the security team and the design team
20:06 <mdeslaur> and there were technical limitations that prevented it from being smarter
20:06 <mdeslaur> but perhaps it can be fixed or rethought
20:06 <mdeslaur> I don't see anything else on the mailing list
20:07 <mdeslaur> [topic] Community bugs
20:07 <mdeslaur> none
20:07 <mdeslaur> [topic] AOB
20:07 <mdeslaur> cyphermox: wake up
20:07 <cyphermox> ""could we possibly put all the different threads of discussion in bugs or something so it's easier to get back state on everything here, and see progress between meetings, rather than having to re-read ML threads, find links again from IRC logs, etc.?""
20:07 <cyphermox> for action items and such
20:08 <rbasak> That sounds like a lot of admin. Are you volunteering? :)
20:08 <cyphermox> not really, but it would be good to have things in a central location
20:08 <rbasak> IOW, I have no objection to tracking things in bugs, but wouldn't that just be another place you need to read to catch up?
20:08 <cyphermox> and the wiki agenda has this lack of context
20:08 <mdeslaur> I thought the agenda was the central location
20:08 <rbasak> Maybe discourse posts?
20:09 <cyphermox> that may work too
20:09 <rbasak> More editable, wiki posts are possible, etc.
20:09 <mdeslaur> feel free to create discourse posts and link them in the agenda
20:09 <vorlon> I don't see the point of discourse instead of bug reports
20:09 * mdeslaur needs to remember where the discourse is
20:10 <rbasak> cyphermox: honestly, I'm not sure I really understand what you're asking me to do.
20:10 <rbasak> If you want to do something to help track things better, then I have no objection. But I assume you want me to then do something differently? What?
20:11 <mdeslaur> I really need to leave now, so let's finish this up and cyphermox can let us know what he wants?
20:11 <cyphermox> well, to me either we keep clearer action items so we remember from one time to the other what something was about, or people spend time to update them done as soon as they are, which I feel bugs would make quick -- if it's inprogress it's a carry over, otehrwise it's maybe done, etc.
20:11 <mdeslaur> [topic] Next chair
20:11 <mdeslaur> next chair cyphermox, backup rbasak
20:12 <cyphermox> yup
20:12 <mdeslaur> cyphermox: did you have another AOB, or was that what you were referring to earlier?
20:12 <cyphermox> no, that's what I was referring to
20:12 <mdeslaur> ok, cool
20:12 <mdeslaur> #endmeeting