On Thu, Jul 11, 2019 at 2:37 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Thu, 2019-07-11 at 13:14 -0400, Neal Gompa wrote: > > On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes <hughsient@xxxxxxxxx> wrote: > > > On Thu, 11 Jul 2019 at 14:52, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > My understanding of the situation was that Canonical is working on a > > > > separate experience tailored for Ubuntu because they have extra needs, > > > > but all of it was built on GNOME Software in the first place. > > > > > > No, it's also a new codebase: https://github.com/ubuntu/snap-store -- > > > it's confusing as the name "Snap Store" is also the name of the > > > debadged-gnome-software version too. > > > > > > > My opinion on this is that because we don't ship the plugin or snapd > > > > by default on any variant of Fedora, we don't really run counter to > > > > the rules. > > > > > > So in the same way, we could have a checkbox for "Flathub support" in > > > the gnome-software addons page? I don't think that would wash with > > > legal as we would be "facilitating" access to patent encumbered > > > software. I don't think the "by default" arguments protects us like > > > that. > > > > > > > Would it make sense for Zygmunt and Maciek (CC'd to this email) to be > > > > added as CC contacts on Bugzilla, so they can address snap plugin > > > > issues when they arise? > > > > > > No, as they're not the ones committing fixes to gnome-software. > > > Watching a bugzilla ticket doesn't equate to being responsible for > > > bugs. The snap plugin self tests are failing in CI, and we can't even > > > update to a newer gnome-software in rawhide as the version of > > > snapd-glib is too old. Usually when that happens either me or Kalev > > > have to hunt down the new tarballs, add any new BRs, scratch build, > > > build, submit as an update etc and that's just not fair. > > > > > > > For what it's worth, Robert Ancell also has an RHBZ account and can be > > added as a CC if needed. That said, Maciek and Zygmunt are the folks > > at Canonical generally responsible for ensuring the non-Ubuntu > > experience is as good as it can be. They are the people I work with > > for Fedora considerations upstream most of the time. They are both > > knowledgeable and capable of working on that side if needed. > > > > I was unaware you've been needing new releases of snapd-glib more > > frequently. I've mainly been updating them whenever I get a bug report > > or when I notice a new version is available. If you need me to be more > > aggressive on updating snapd-glib, I could have done that. > > > > > > I'm just generally confused about this, and somewhat blindsided... > > > > > > I was informed of the Canonical decision a few weeks ago, and it too > > > took me by surprise. I guess winning the war comes at a cost, and this > > > camel has a broken back. > > > > > > > I wish someone had looped *me* into these conversations, as one of the > > > > snap support maintainers in Fedora, I'm relying on these things to > > > > provide a good experience for Fedora users of snaps... > > > > > > I was asked not to distribute details about the conversations until > > > they had made a public statement, which still hasn't been done. I'm > > > not comfortable with the situation at all either but we have to do > > > something. > > > > > Practically speaking, Neal, can you not just create the 'gnome- > software-snap' package Richard suggested, and maintain that? Is there > any problem with doing so? Technically speaking, I can. However, GNOME Software provides no ABI guarantees for plugins, which is why all of them are in-tree. If an update occurs even within stable releases, I would expect it to have a chance to break. I considered this approach when I introduced snapd to EPEL7, but discarded it for this reason. If forced to, I'll do that, but I'd really rather avoid having to go down that path. And if GNOME Software removes the plugin, that makes it even harder on me. But again, if forced, I guess I'll do something to try to provide a good experience for Fedora Workstation users. I don't know what I'll do, but I'll try to figure something out. -- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx