On Sun, 27 Jan 2019 at 10:27, Debarshi Ray <rishi...@lostca.se> wrote:
> The tl;dr here is that a lot of people care about political arguments > but nobody shows up to bear the burden of dealing with the code. > "Political" in the sense that you're not maintaining a leaf node in the dependency graph, that can come and go, but a service that has repercussions on other projects. The issue is not that Documents is going away; the problem is that Documents is, by design, heavily dependent on a session service, and that it can't be easily moved from that to its own implementation. Again, not a huge deal; sure, Documents is actually useful to navigate through the Google Drive contents—the Drive web UX has become shockingly bad over the years, unsurprisingly since its a fate that befalls every Google application—but we can live without it, and it seems it's a niche usage to begin with. But… 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. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com]
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
