Re: GNOME Online Accounts 3.34 won't have documents support
Hey Michael, On Sun, Jan 27, 2019 at 08:29:32PM -0500, Michael Terry wrote: > I meant (1) keeping GNOME's API key valid, (2) maintaining > libgdata, (3) maintaining the GVFS google backend (which only > supports using GOA keys -- an app can't give it its own keys), > and (4) maintaining the GOA google backend. Ok. Did anybody tell you that you need to contribute N patches a year to libgdata, gnome-online-accounts and gvfs every year or you are out? Honest question. You're surely welcome to help, but I don't think it's ever been mandatory. That'd be crazy. The only thing I remember is trying to figure out why Deja Dup's API calls were sometimes erroring out. Maybe somebody else gave you some misinformation? I apologize if that's been the case. > If GNOME lets their API key be revoked, all of the above will be > dropped on the floor. Libgdata might live on independently, but > GNOME wouldn't have a reason to put it into releases any more. > > ... > > (I assume you meant that deja-dup doesn't have much to worry about > in the main context of this thread about Documents support etc being > dropped from GNOME. And you're correct there. But Michael's comment > about GNOME losing it's Google key in three weeks does have me spooked.) As the primary maintainer of GNOME's Google API keys for the last seven years, and the author of libgdata's Google Drive support, and a co-author of the GVfs backend, I can assure you that GNOME won't just "let their API key be revoked". :) My understanding is that Google is still going through their list of emails and sending out the notifications. I got my copy of their email only yesterday. Michael Catanzaro and Philip Withnall got theirs some days before that. I'd have had a better understanding of things by now, but I am currently busy with desktop-devel-list duty. Having to deal with the service providers is a part of life when we are using their services. For various unknown reasons, GNOME's Facebook API key had been flagged multiple times over the past six or seven years. GNOME was twice temporarily banned by Facebook, which was lifted once we answered their questions and explained a few details. It's possible that these were temporary restrictions placed by some bot and not a human. Twice we had to ask Google to increase GNOME's quota for two of their API subsets. It needed an explanation of what GNOME is, how many users we have, how we handle caching, etc. and Google gave us what we had asked for. Once we had to switch our Google key because a bug in evolution-data-server had polluted the older key: https://debarshiray.wordpress.com/2016/12/15/new-gnome-api-key-for-google-services/ I don't know how this present situation will be resolved, but we'll see. In the worse case, if Google does think that we are not meeting their standards, then Deja Dup wouldn't be able to circumvent that with a separate key on a sustained basis. If, hypothetically, Deja Dup is the cause for GNOME loosing its access, then Google sooner or later will catch up and shut it down one way or another. Cheers, Rishi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Folks, I don't have anything technical to add to this discussion, so as someone just following along with the thread I think we should take our emotions down a couple notches. Calling each other out, playing the blame game, and dredging up stuff from the past is not going to help us come up with a clear path forward. We're all friends and colleagues, let's not forget that first and foremost. :-) On Sun, Jan 27, 2019 at 10:26 PM Debarshi Ray wrote: > Jeremy, > > You already attempted to slander me once before in this thread: > > https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00027.html > > It's been one week since I produced evidence against that: > > https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00035.html > > You had enough time to clarify your original statement or recant it. I > no longer consider anything you say to be in good faith. > > On Wed, Jan 23, 2019 at 03:21:57PM -0500, Jeremy Bicha wrote: > > But you're talking about removing even more online accounts providers > > even though apps that support them have not yet implemented a > > replacement. > > Nice reversal of cause and effect there. Good job. > > The decision to retire GNOME Documents was the reason the integration > point was dropped from GOA. > > > Interestingly, Ubuntu Online Accounts was ahead of its time here. What > > it offers in Ubuntu 16.04 LTS sort of foreshadows how this could work. > > Oh, yeah, Ubuntu Online Accounts - the purveyor of shady downstream > patches against applications (read: Shotwell) that replace upstream > branding and reward with crashes. > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Thu, Jan 24, 2019 at 01:29:54PM +, Matthew Paul Thomas via desktop-devel-list wrote: > * For some reason that isn???t clear to me, GOA cares what you use each > account for, rather than merely recording which apps the user has > granted access to each account. Because that's how Google, Facebook, and Microsoft's services work. The program needs to explicitly say exactly which subset of services it's going to use, and the user needs to sign off on that. The technical term is "OAuth2 scope". > Why was there such a thing as > ???Documents support??? in GOA in the first place? This suggests that if > Facebook or Google or Microsoft announced and released a new chat > app XYZ tomorrow, which integrated with their usual account > system, it couldn???t use your Facebook or Google or Microsoft account > stored in GOA, because GOA wouldn???t include ???XYZ support???. You cannot just go and use the chat API or services just because the user had added a Facebook or Google or Microsoft account. It will very likely fail to authenticate; or your program will get banned by the service provider. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Jeremy, You already attempted to slander me once before in this thread: https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00027.html It's been one week since I produced evidence against that: https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00035.html You had enough time to clarify your original statement or recant it. I no longer consider anything you say to be in good faith. On Wed, Jan 23, 2019 at 03:21:57PM -0500, Jeremy Bicha wrote: > But you're talking about removing even more online accounts providers > even though apps that support them have not yet implemented a > replacement. Nice reversal of cause and effect there. Good job. The decision to retire GNOME Documents was the reason the integration point was dropped from GOA. > Interestingly, Ubuntu Online Accounts was ahead of its time here. What > it offers in Ubuntu 16.04 LTS sort of foreshadows how this could work. Oh, yeah, Ubuntu Online Accounts - the purveyor of shady downstream patches against applications (read: Shotwell) that replace upstream branding and reward with crashes. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 1:04 PM Debarshi Ray wrote: > On Sun, Jan 27, 2019 at 11:24:00AM -0800, philip.chime...@gmail.com wrote: > > 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 mean like the time when GJS broke GNOME Documents? > Sorry, I don't know what particular event you're referring to. Sometimes GJS breaks things. When that happens, I spend actually quite a lot of my maintainer time 1) writing about the breakage, so that app developers are aware, and 2) writing about a migration plan, so that app developers know what to do. GJS is even different from GOA because, as pointed out earlier in the thread, GOA is not part of a Flatpak runtime but is still used by Flatpak apps. A migration plan could be the type of solution that addresses both problems. Or some way to get a workalike service into existing Flatpak runtimes so that apps on, for example, 3.24, don't break. Nonetheless, I'm sure I make mistakes where GJS breaks things that I don't communicate well enough. Are you seriously suggesting that because I committed some mistake, you should insist on the right to make the same mistake with eyes wide open? > 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. > > Ah, "those app developers"? And who might those be? > > You better produce solid proof of a single case where "those app > developers" were screwed over by GOA, or withdraw that comment. > Literally just a few messages before mine in the thread, we heard about deja-dup. I also fell into the same trap at work while considering the technology to use in a particular application, but luckily (?) we ended up not using GOA for unrelated reasons. For what it's worth, I don't appreciate the ad-hominem attack here. I intended to *help* you by trying to break the cycle of people ignoring your problem and yelling at you about theirs, and vice versa, but if you prefer to continue yelling then suit yourself. Philip C ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 6:32 PM, Nathan Graule via desktop-devel-list wrote: Given what I've read about the Google policy (and I don't know how much of that was added with the Jan. 15 revision), but it seems like the very concept of GOA as a centralized account repository goes against Google rules. Google wants to know by whom the OAuth key will be used, and how. Under an open system where any third-party can implement access to GOA, GNOME cannot be able to tell Google about the use of the key (which is part of what they're asking in their request, as the ansible issue presents <#2>). Therefore GOA *needs* to change somewhat. At the very least, it cannot let third-party applications use the GNOME OAuth key to access Google APIs. Question: the GNOME key is necessarily public, since it's open source and we don't have secret sauce in the build system. GNOME can't stop random apps from using it. Right? The g-o-a README says this is allowed: https://gitlab.gnome.org/GNOME/gnome-online-accounts/blob/bf77325d847d2878159e8ba2677768b2fe6386a6/README#L58 So there's no way we can ever stop random applications from using the GNOME key and pretending to be us, right? It just works because nobody has decided to abuse it yet? Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 7:29 PM, Michael Terry wrote: You say deja-dup has nothing to worry about. But I very much have to solve the problem of many of my users losing access to their backups (through my app at least) in three weeks. Will not inspire confidence. Again, my fault I guess for using GOA in the first place. There are multiple deadlines: """For projects that require action, you must submit apps for verification before Feb 15th, 2019. If you don't, access for new users will be disabled on February 22nd, 2019, and existing grants for consumer accounts will be revoked on March 31st, 2019.""" Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 8:29 PM Michael Terry wrote: > (I assume you meant that deja-dup doesn't have much to worry about in the > main context of this thread about Documents support etc being dropped from > GNOME. And you're correct there. But Michael's comment about GNOME losing > it's Google key in three weeks does have me spooked.) I have someone who I think can help. If not, I will find someone at Google who can either delay it or help us with it. The whole thing is related to GDPR. I'm hoping that we can get this resolved. Cheers, sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019, at 16:16, Debarshi Ray wrote: > "maintain GNOME's Google support" is bit misleading here. I'll try to > explain. > > "GNOME's Google support" is libgdata and the GNOME API key. Using > libgdata is independent of using GOA, and that's where the > overwhelming bulk of effort goes - keeping up with API changes and so > on. As for the API key, we often have a hard time because we don't > fall into one of the big buckets called: web application, iOS app, > Android app, etc.. Since the Linux desktop is such a small portion of > the user base, we always run into weird rough edges that don't affect > the more popular platforms that much. > > The one genuine case where you might have to do some work is when a > bug in Deja Dup adversely affects the GNOME API key. Say, for example, > if there's a bug in the code that DoSes the Google servers or causes > data loss or something catastrophic like that. > > But other than that I don't know what "maintain GNOME's Google > support" would mean. I meant (1) keeping GNOME's API key valid, (2) maintaining libgdata, (3) maintaining the GVFS google backend (which only supports using GOA keys -- an app can't give it its own keys), and (4) maintaining the GOA google backend. If GNOME lets their API key be revoked, all of the above will be dropped on the floor. Libgdata might live on independently, but GNOME wouldn't have a reason to put it into releases any more. You say deja-dup has nothing to worry about. But I very much have to solve the problem of many of my users losing access to their backups (through my app at least) in three weeks. Will not inspire confidence. Again, my fault I guess for using GOA in the first place. (I assume you meant that deja-dup doesn't have much to worry about in the main context of this thread about Documents support etc being dropped from GNOME. And you're correct there. But Michael's comment about GNOME losing it's Google key in three weeks does have me spooked.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Given what I've read about the Google policy (and I don't know how much of that was added with the Jan. 15 revision), but it seems like the very concept of GOA as a centralized account repository goes against Google rules. Google wants to know by whom the OAuth key will be used, and how. Under an open system where any third-party can implement access to GOA, GNOME cannot be able to tell Google about the use of the key (which is part of what they're asking in their request, as the ansible issue presents <#2>). Therefore GOA *needs* to change somewhat. At the very least, it cannot let third-party applications use the GNOME OAuth key to access Google APIs. This would be fine, however I don't think having a conceptual exception for Google is particularly good. I see two ways to approach a hypothetical re-design of GOA. A first way would be to put GOA as the authentication backend of the system itself (considering core apps as part of the system), and close access to third-party. This effectively is a regression on usability since having a centralized authentication system does make life (ever so slightly) easier for both users and developpers. A second way would be one pretty much inspired from Android. In Android, apps that want access to the users' Google account simply contact the backend with an authentication request. Since Android phones are almost always linked to a Google account, the user only sees an OAuth confirmation prompt (the prompt outlining which services will be granted access to the app) which links the application's key to the account. In GOA, this could work in a similar way: If a Google account is already present, GOA presents an OAuth confirmation dialog that grants access to the application. At any point, GOA doesn't know about which apps have been granted, because in the case of OAuth applications the role of access control is left to the account. For non-OAuth applications, the logging in and access control is left to GOA (a simple enable/disable access to this app should be sufficent, the same way it works for location and notificatio access), but the workflow is the same. In the second case, on top of having a more flexible GOA, it would provide real value to users and developers by having GOA continue being an open service that both reduces boilerplate and provides a centralized place to manage accounts. The downside is that this implementation is going to need work and maintainship, which might be lacking*. This is what the first option answers directly: it strips down GOA so that maintaining it is less work. Those are my 2cc on GOA as a whole, as I do see real value in keeping it there. Nathan * Yes, I realize I'm saying this while I'm all talk and no walk. However I am not confident in my ability to be part in such a complex project, even less writing code for it. I am however happy to help whenever and wherever I can. Le dim. 27 janv. 2019 à 23:27, Sriram Ramkrishna a écrit : On Sun, Jan 27, 2019 at 2:24 PM Philip Chimento via desktop-devel-list wrote: 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. A blog post was written and put out there because there was confusion/issues with 3rd party folks wanting to integrate with GOA. I'm not sure what more is required? As a project we tend to only communicate when there is a fire. Which given our lack of general resources is not surprising. I'm sure people want to better given appropriate resources. I want to add one comment: someone on the thread said: "we are a small niche market". No.. we're a growing niche market. I can assure you of that. This market is supporting several companies who market pre-installed machines with Linux based desktop and are thriving. It might be slow, but conversions are happening. Given we are losing google services, gnome-documents seems to lose a lot of what would make it useful - managing cloud based documents. The fact that we are losing this is much more alarming to me than this discussion over single sign on. Tens of thousands of people will no longer be able to use google files through nautilus seems like a big deal to me in three weeks and should in fact be communicated immediately as an existential community issue. GOA will figure itself out one way or another if we care about the issue. I wish people would ask me if they need help getting people to help. It's one of the things that engagement people are supposed to help with rather than throwing your hands up in the air and say we don't have resources. They are out there. You just have to attract them. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 2:24 PM Philip Chimento via desktop-devel-list wrote: > 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. A blog post was written and put out there because there was confusion/issues with 3rd party folks wanting to integrate with GOA. I'm not sure what more is required? As a project we tend to only communicate when there is a fire. Which given our lack of general resources is not surprising. I'm sure people want to better given appropriate resources. I want to add one comment: someone on the thread said: "we are a small niche market". No.. we're a growing niche market. I can assure you of that. This market is supporting several companies who market pre-installed machines with Linux based desktop and are thriving. It might be slow, but conversions are happening. Given we are losing google services, gnome-documents seems to lose a lot of what would make it useful - managing cloud based documents. The fact that we are losing this is much more alarming to me than this discussion over single sign on. Tens of thousands of people will no longer be able to use google files through nautilus seems like a big deal to me in three weeks and should in fact be communicated immediately as an existential community issue. GOA will figure itself out one way or another if we care about the issue. I wish people would ask me if they need help getting people to help. It's one of the things that engagement people are supposed to help with rather than throwing your hands up in the air and say we don't have resources. They are out there. You just have to attract them. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 11:37:31AM +, Emmanuele Bassi wrote: > On Sun, 27 Jan 2019 at 09:24, Debarshi Ray wrote: > > > On Thu, Jan 24, 2019 at 11:00:58AM +0100, Bastien Nocera wrote: > > > I don't think that feature requests should be treated on the same level > > > as existing, merged, features > > > > I can't change my theme, I can't change my fonts, no minimize button, > > no wallpaper options, my laptop insists on suspending ... > > > > Can I have those back? > > > > Install Tweaks. And you can install a web browser, nautilus and evince; but, hey, guess what? You already have those! > See, that's kind of the difference between removing infrastructure and > removing UI for it. > > Even if you're removing infrastructure, we do have mechanisms and policies > for transitioning between the initial and final points: versioned > interfaces, soname bumps, new dependencies, deprecations. Oh, you mean like GTK dropping geometry support and breaking GNOME Terminal one day: https://bugzilla.gnome.org/show_bug.cgi?id=760944 I wonder what mechanisms or policies were in play there. I do know that some brave souls scurried to workaround that in GNOME Terminal. I'll let the reader guess how many people use GNOME Documents versus those who use GNOME Terminal or care about themes or fonts or minimize buttons or wallpapers or suspend? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 02:48:12PM -0500, Michael Terry wrote: > On Wed, Jan 23, 2019, at 21:39, Michael Gratton wrote: > > If GOA Mail is going to be removed from Fedora can there at least be a > > method to programatically determine what is supported and what isn't, > > so Geary can avoid launching the control center when people want to add > > an account on Fedora? > > A minor technical side note here. You actually might be able to > programatically determine that: libgoa-backend will tell you what > providers exist and what features they support. Yes, that's correct. That doesn't mean this thread has anything to do with email, regardless of how much bullshit is being peddled on this thread. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
TL;DR: I don't think Deja Dup has anything to worry about. I was pleasantly surprised to know that Deja Dup even uses GOA. Having backups integrated more closely in the OS seems like a good thing to me. I'd encourage you to bring up the story of backups with the GNOME Design Team. On Sun, Jan 27, 2019 at 01:57:49PM -0500, Michael Terry wrote: > I totally understand the difficulty GNOME is in here, and I'm > not expecting you folks to do work that you don't have the time for. > I don't have the time to maintain GNOME's Google support either, so > no shade thrown by me. But it sure is a bummer. And a lesson to me > about relying on GNOME's platform. "maintain GNOME's Google support" is bit misleading here. I'll try to explain. "GNOME's Google support" is libgdata and the GNOME API key. Using libgdata is independent of using GOA, and that's where the overwhelming bulk of effort goes - keeping up with API changes and so on. As for the API key, we often have a hard time because we don't fall into one of the big buckets called: web application, iOS app, Android app, etc.. Since the Linux desktop is such a small portion of the user base, we always run into weird rough edges that don't affect the more popular platforms that much. The one genuine case where you might have to do some work is when a bug in Deja Dup adversely affects the GNOME API key. Say, for example, if there's a bug in the code that DoSes the Google servers or causes data loss or something catastrophic like that. But other than that I don't know what "maintain GNOME's Google support" would mean. Of course, you are always free to use your own API key and drop the GOA support too. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 11:24:00AM -0800, philip.chime...@gmail.com wrote: > 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 mean like the time when GJS broke GNOME Documents? > 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. Ah, "those app developers"? And who might those be? You better produce solid proof of a single case where "those app developers" were screwed over by GOA, or withdraw that comment. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, Jan 23, 2019, at 21:39, Michael Gratton wrote: > If GOA Mail is going to be removed from Fedora can there at least be a > method to programatically determine what is supported and what isn't, > so Geary can avoid launching the control center when people want to add > an account on Fedora? A minor technical side note here. You actually might be able to programatically determine that: libgoa-backend will tell you what providers exist and what features they support. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
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 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
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019, at 11:14, mcatanz...@gnome.org wrote: > Err... well this seems like as good a time as any to mention it: Philip > and I both noticed emails from Google warning that they'll shut us down > unless we do a huge amount of work in a very short amount of time. > Neither of us plan to work on this. My only use of the Google > integration is for Safe Browsing, which doesn't use > gnome-online-accounts at all and which I'm just hoping won't be > affected. > > If anyone wants to help, see > https://gitlab.gnome.org/Infrastructure/ansible/issues/2. We have three > weeks left. Ooof. A while back I excitedly integrated GOA support for Google Drive into the deja-dup backup program, using the gvfs backend to handle the actual file access. I totally understand the difficulty GNOME is in here, and I'm not expecting you folks to do work that you don't have the time for. I don't have the time to maintain GNOME's Google support either, so no shade thrown by me. But it sure is a bummer. And a lesson to me about relying on GNOME's platform. So it seems that for apps like mine which had supported Google accounts through GOA, the next steps would be to register their own OAuth developer account with Google and write their own custom access backend to replace the generic gvfs one? Ideally within the next three weeks and then backporting the change for all existing stable releases in the wild before users hit errors from the GNOME key being revoked. I understand the party line in this thread to be that I should have already been doing that and never should have used GNOME's code in the first place. Fair enough. I misunderstood GNOME's stance on that. Maybe libgoa should have you define -DGOA_API_YES_I_AM_A_CORE_GNOME_APP to help prevent this misunderstanding in the future. Well, thank you to the folks that did work on Google integration. I appreciate it, and the feature was good while it lasted. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019 at 4:27 AM, Debarshi Ray wrote: It so happens that we have half a dozen notifications from Facebook and Google about our uses of their APIs at varying degrees of seriousness. They are still on my todo list. Thankfully, Philip Withnall and Michael Catanzaro are on top of the Google part, but only barely. I am worried that most of our Facebook integration has stopped working. Err... well this seems like as good a time as any to mention it: Philip and I both noticed emails from Google warning that they'll shut us down unless we do a huge amount of work in a very short amount of time. Neither of us plan to work on this. My only use of the Google integration is for Safe Browsing, which doesn't use gnome-online-accounts at all and which I'm just hoping won't be affected. If anyone wants to help, see https://gitlab.gnome.org/Infrastructure/ansible/issues/2. We have three weeks left. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, 27 Jan 2019 at 10:27, Debarshi Ray 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
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, 27 Jan 2019 at 09:24, Debarshi Ray wrote: > On Thu, Jan 24, 2019 at 11:00:58AM +0100, Bastien Nocera wrote: > > I don't think that feature requests should be treated on the same level > > as existing, merged, features > > I can't change my theme, I can't change my fonts, no minimize button, > no wallpaper options, my laptop insists on suspending ... > > Can I have those back? > Install Tweaks. See, that's kind of the difference between removing infrastructure and removing UI for it. Even if you're removing infrastructure, we do have mechanisms and policies for transitioning between the initial and final points: versioned interfaces, soname bumps, new dependencies, deprecations. What I've been asking is to come up with a process that lets us move an application from core to third party, so that we can communicate this appropriately to users and app developers alike. Because today is Documents, and tomorrow is Music, and the day after that is Photos. I understand that you're pissed because it seems we're doing backseat driving on your maintainer role, but you're doing something that affects the whole of the project, and that might happen again, so it's better to have a process in place the first time—otherwise it *will* happen again and we won't have a process at all. 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
Re: GNOME Online Accounts 3.34 won't have documents support
On Mon, Jan 21, 2019 at 02:03:18PM +, Debarshi Ray wrote: > It's true that GNOME Documents was conceived as a way to seamlessly > access all files local and remote. In that sense, the Online Accounts > integration is crucial for it. > > However, it has turned out to be more complicated than that. I also > don't know how excited the GNOME designers are about GNOME Documents > today. Oh, and GTK4 happened. GNOME Documents is doomed to stay GTK3 until LibreOffice gets ported. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Thu, Jan 24, 2019 at 10:56:49AM +0100, Bastien Nocera wrote: > You dropped maintainership of gnome-documents, we're now dropping it > from core GNOME, and by removing the Documents integration from GOA, > you're crippling the application, whoever the new maintainer ends up > being. No, wrong. I dropped maintainership of GNOME Documents when it was clear that we are better off refocusing our efforts elsewhere. I started a follow-up thread with Michael, Allan, Jakub and Cosimo to formalize our thoughts on this subject before pulling the plug. And I still don't see anybody willing to do the heavy-lifting to tackle those issues (already mentioned elsewhere in this thread) head on. So what you are saying may sound true in theory, but in practice, doesn't make any sense. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Hey Emmanuele, (I am summarizing a few other sub-threads here.) On Wed, Jan 23, 2019 at 06:45:50PM +, Emmanuele Bassi wrote: > On Wed, 23 Jan 2019 at 18:36, Debarshi Ray wrote: > > What isn't possible is to mix and match API keys with account types at > > run-time. That doesn't seem trivial to implement - neither from a code > > nor a design perspective. Possible, sure; trivial, no. > > I didn't say "trivial", but I didn't expect this to be hard. You, of > course, know better than me how hard it would be, so I'll defer to your > assessment. 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. While we have lots of arguments about where the Google or Facebook logo should come from, and which switch should go where, etc. nobody is interested in implementing the Google or Facebook SDKs or keeping up with changes as the provider evolves their services. Nobody. I bet there are less than 10 people who know what libzapojit is. ;) So, unless the number of people working on our SDKs (ie. libgdata, libgfbgraph, etc.) increase dramatically, all these grand plans that people put forward are meaningless. We would spent a ton of design and coding effort into building the perfect single sign-on framework, but you won't be able to use Google Drive because the over-the-wire communication would be broken. This is why, from my point of view, it's better to have a simpler, more straightforward GOA, because then we can invest whatever little resources we have to keep our SDKs alive. People here are up in arms about Google Drive support. Strangely enough, I was the one who kept it alive by rewriting libgdata, and wrote the GVfs backend for it. Eventually I dumped it all on Ondrej Holy, and I am sure he now feels as if the sky is falling on his head. It so happens that we have half a dozen notifications from Facebook and Google about our uses of their APIs at varying degrees of seriousness. They are still on my todo list. Thankfully, Philip Withnall and Michael Catanzaro are on top of the Google part, but only barely. I am worried that most of our Facebook integration has stopped working. Secondly, applications like Empathy, Evolution, Geary and Shotwell were never interested in betting the farm on GNOME and GOA. Some just didn't want to use GOA - plain and simple. For example, I recall talking to Jim Nelson from Yorba during GUADEC 2012, and he said that Yorba really cared about presenting their own brand identity when interacting with Flickr using Shotwell. It would have been terribly rude if a GNOME distributor decided to downstream patch Shotwell to make it use GOA and replaced the Yorba brand with something else. This is what Ubuntu did, by the way, for their own Ubuntu Online Accounts stuff. Jim was bitter about how the patches introduced crashes, etc. etc.. Others like Evolution cared a lot about working well on XFCE or GNOME forks like the Unity-based Ubuntu, which didn't have GOA. Whatever, the specific story was, they had their own separate account management anyway. Now in 2019, Geary has GOA support, but that's neither because they chose to be GNOME Mail nor because I encouraged them. I helped answer questions, that's all. See: https://bugzilla.gnome.org/show_bug.cgi?id=714876 https://bugzilla.gnome.org/show_bug.cgi?id=746705 Maybe it will be GNOME Mail now? I don't know. Also, this thread has nothing to do with email or Geary or whatever. It's about a weakly maintained application that nobody used, and one which we chose to retire to refocus our efforts elsewhere. 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. Cheers, Rishi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Thu, Jan 24, 2019 at 11:00:58AM +0100, Bastien Nocera wrote: > I don't think that feature requests should be treated on the same level > as existing, merged, features I can't change my theme, I can't change my fonts, no minimize button, no wallpaper options, my laptop insists on suspending ... Can I have those back? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Thu, Jan 24, 2019 at 01:38:57PM +1100, Michael Gratton wrote: > On Thu, 24 Jan, 2019 at 5:52 AM, Debarshi Ray > wrote: > > On Wed, Jan 23, 2019 at 04:03:41PM +0100, Bastien Nocera wrote: > >> On Wed, 2019-01-23 at 14:33 +, Allan Day wrote: > That's not > >> what's happening here. Until very recently, Debarshi was > the > >> Documents maintainer, and he's obviously been fully involved. It is > >> what is happening in GNOME Online Accounts in general. Pocket is > >> disabled in Fedora 29, and there's a good chance that the mail > >> configuration bits will be disabled in Fedora 30. > > Grep for "Future of Pocket in GNOME" from 24th August 2018 in your > > inbox. > > Was there a similar announcement for the Mail component that I missed? > Debarshi you knew I landed support for this in Geary master earlier > this year, a head-up would have been appreciated. > > If GOA Mail is going to be removed from Fedora can there at least be a > method to programatically determine what is supported and what isn't, > so Geary can avoid launching the control center when people want to add > an account on Fedora? This is a GNOME mailing list and it was a thread about documents. I didn't say anything about Fedora or email. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
