On Sun, Jan 27, 2019 at 4:13 AM Emmanuele Bassi via desktop-devel-list < desktop-devel-list@gnome.org> wrote:
> On Sun, 27 Jan 2019 at 10:27, Debarshi Ray <rishi...@lostca.se> wrote: > > GNOME has various core applications that depend on the same mechanism. We > actually made a point of integrating with remote services, because > apparently that's a thing. We don't really have a policy for moving > applications from second/third party to core, but if that policy existed, > "integrating with the Online Accounts platform" would be on it. For > applications that migrate from second/third parties to core, that would be > an additional feature; for first party application, we would *only* have > that kind of integration. > > The "political" issue I'm trying to raise is that not only we lack the > "how do we move an app into core" policy, but we also lack the "how do we > move an app out of core" one, especially when it comes to services > integration. Second/third party apps that integrate with web services can > be moved out of core by ripping the GOA integration, and falling back to > their own—if they still have it. First party applications that never had > anything else don't have that fallback path in place. > > Again: maybe Documents isn't used. Maybe Photos, Music, and whatever else > aren't used either. Who knows, we don't have metrics, right? > > Nevertheless, removing platform functionality without an adequate process > for it is problematic in many ways, a shockingly small amount of which are > technical: > > - we told people to use Flatpak for core applications; Flatpak doesn't > really like it when session services change, because session services are > part of the system API that cannot be sandboxed. Sure, GOA is almost an > outlier, but we have a bunch of services that are more than cavalier in > attitude when it comes to changing their features; how do we deal with that > happening? > - we do have a user base, and we need to communicate changes effectively > so that we don't spend cycles constantly defending our decisions; that > stuff is exhausting. > - we have a software development platform, and we'd like for app > developers to use it; we need to have processes in place to communicate our > expectations with second/third parties. > - we have a set of potential core applications and not enough people > writing them; if our platform isn't stable enough for first parties, if our > expectations about what can happen to it aren't communicated well enough > *amongst ourselves* then we can pack our bags, and go home, because we're > done. > > So, yes: we have to deal with "political" issues, here, because we are a > complex project with maintainers that have the right/tendency to do > whatever they want. > > I do think that GNOME is better served caring about a small subset of >> providers and services - those that we are serious about supporting, >> and have (or will have) high quality applications offering the user >> facing features. We should evolve the design and code in whichever >> direction that takes us. >> >> What we shouldn't do is get into architecture astronauting and >> political arguments about getting everybody's favourite logo into the >> Online Accounts panel. >> > > I hope you realise that my objections in this thread are not about > astronauting things, outside of a side note about I always found GOA a > missed opportunity to build our platform; I'm more concerned about the lack > of process that seems to plague GNOME (from time immemorial, I might add) > and the fact that every time this is brought up, people scream "stop > energy" or "architecture astronauting" or "maintainer rights" or "what > would YOU do", instead of understanding that GNOME is a complex project and > the only way we can make it work is to communicate plainly and honestly > what people need to know in order to be a part of it. > > By all means: work on making GOA smaller and more maintainable. If the > process to achieve that goal is that we should archive applications, then > it's absolutely fine to say so, write it down on the wiki, and point people > to it. What should *not* happen is telling people that apps will be dropped > from the release, and that's all there is to it, because that sets up the > wrong expectations that you can still build the application, distribute it, > or use it, and it'll work the same way—it just won't be part of the GNOME > release (which nobody is using anyway, because nobody here uses GNOME from > the release tarballs). What should *not* happen is asking people to > integrate their apps with GOA as part of making them feel more "GNOME-y" > without also telling them that we reserve the right to change GOA's > offerings because of our chronic resource shortage, or because our designs > change. > +1 Emmanuele hits the nail on the head here as far as I'm concerned. I think maybe it will be useful to recognize explicitly that there are two seemingly irreconcilable problems. 1. It's not possible to continue GOA in its present form due to lack of volunteer power, services changing API, and concerns with third-party apps being able to misbehave under the GNOME banner. 2. It's not possible to discontinue support for services X, Y, and Z from GOA, and yank the rug out from under apps that expected (even if that expectation was wrong) it to be part of a stable platform. You *cannot* argue for only one of these problems and ignore the other one (as many people have been doing in this thread.) The task is to find a solution to both problems. A solution to only one or the other will just cause more problems. PS. Yes, count me among the completely surprised that GOA is not an API that apps should use. It was not communicated anywhere close to the level it needed to be. That's on GNOME, not on those app developers. This is why it's our problem. Best, Philip C
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list