Emmanuele Bassi <ebassi gmail com> wrote:
...
>> This approach isn't new, and you can read more detail here:
>> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
>>
>
> I know the rationale. I never particularly agreed with it, because it felt like an ex post rationalisation about not having third party modules, and getting people to commit functionality upstream. ...
I don't think that was the reason. At least, it's not what's been on
my mind, and I don't remember others putting that view forward.
"It felt like".
The main factor has always been about how we handle identity. If we
give online accounts access to 3rd party apps, we're giving them
access to the GNOME keys. They appear as "GNOME" to online providers
and their access is bundled up with our own. As a result, we lose the
ability to ensure that the GNOME keys are being used in accordance
with providers' terms and conditions.
This is because we never specified a way to get third party keys stored inside GOA as part of a process to get third party modules to it.
>From a design perspective that's never been something we've wanted to
do, both from a branding and identity perspective, as well as from a
"oh shit we can't access Google any more, because some random app did
something they didn't like".
We can communicate that a key has been revoked by a service in the same way we communicate that the user needs to re-authenticate themselves.
> What I'm objecting to is the wishy-washy approach of telling people: "Sure, you can keep working on Documents, it's just not going to be installed any more" without telling the whole story.
>
> If Documents is removed, then all the Documents integration within GNOME is also removed, which means that the project *in its current incarnation* should just be archived. People should be encouraged to fork it, if they find it useful, and implement that integration inside Documents itself. This gives the proper context and communicates the proper expectations to people willing to maintain the Documents code base.
If you think something can be done better, just suggest how it can be
done better.
I believe I just did that: make the consequences of picking up Documents—or any other core application we decide to drop because the design is fuzzy, or the resources are too few to make a design work—explicit. Do not say: "we are simply dropping Documents from the release", or "we are removing Documents integration from GOA because we're dropping Documents"; instead, explain what that means for somebody picking up a former-core application. An even more explicit action is: archive the Git repository after removing Documents from the release, and tell people to fork it and rename it.
Create a process for moving apps from "core" to "external".
Ciao,
Emmanuele.
