Howdy, what would you be after from fd.o? repo, web? etc...

Hi,

if possible we would like to host all project activities on fd.o:

- web so we can migrate the desktop neutral information from its current 
location on KDE's web server and as a download location for release tar balls.
we already have a domain akonadi-project.org, currently pointing to the KDE 
location, in case this makes any difference for you

- an "Akonadi" product in the bugtracking system with a "Server" component (so 
we have the option of adding components for desktop independent client 
implementations, e.g. Java)

- a developer mailinglist, e.g. akonadi-devel, which should also receive the 
bugtracker notifications

- git repository

regarding the repository we do have a question on account creation: since, if 
I understand correctly, accounts are managed by the site wrangler team, how 
long does it usually take to get contributors approved? (we are kind of 
spoiled by how quick KDE's sysadmins handle this :))

fd.o admins: Ping?

This project deserves to either be hosted or be told why it won't be. Even if the hosting can't be set up instantly (e.g. due to sysadmin time/energy right now), a definitive answer should be provided in such a case as this. Three months is too long to be waiting for an answer IMHO.

Thanks in advance ...

(I'm dealing with this now, have talked to Aaron.)

4 months later... ping fd.o admin?

closing as WONTFIX at least for the moment, based on an irc discussion with cornelius schumacher:
  * akonadi does not have wide adoption outside kde at the moment, and discussions with various people a while ago revealed a number of concerns about it
  * lack of at least a proof-of-concept non-c++ implementation is a bit of an issue
  * the main concern raised was the breadth of akonadi's scope; it's possible that a hypothetical cross-desktop solution would end up being a subset of akonadi and used by both akonadi and other desktop projects

the akonadi guys are going to go and talk to the others and try to work out how to go forward, and then we'll see how it goes.  so, closing without prejudice based on mutual agreement.

sorry it's taken so long; that's entirely my fault.

Just for the record: I think most of the concerns are based on misunderstandings about what Akonadi is and does. Its intention, design and implementation are cross-desktop from the beginning and it doesn't have any KDE dependencies. But it's appreciated that freedesktop.org takes concerns seriously, so as Akonadi hosting itself is not a problem at the moment, I agree that it's better to close the request for now.

(In reply to comment #6)
> closing as WONTFIX at least for the moment, based on an irc discussion with
> cornelius schumacher:
>   * akonadi does not have wide adoption outside kde at the moment, and
> discussions with various people a while ago revealed a number of concerns about
> it

now that we're using this as a criterion (certainly weren't in the past =), a clear definition of what "wide enough adoption to count" means. personally, i  believe the only place adoption rates should matter is when being considered for standardization, when using the fd.o namespace in e.g. DBus interfaces, etc.

>   * lack of at least a proof-of-concept non-c++ implementation is a bit of an
> issue

this is a non-issue. you interact with it out of process using protocols (IMAP, D-Bus), so you can write in C or Java or Ruby or Python or whatever language and use akonadi just fine.

>   * the main concern raised was the breadth of akonadi's scope; it's possible
> that a hypothetical cross-desktop solution would end up being a subset of
> akonadi and used by both akonadi and other desktop projects

is this a request for the definition of an "akonadi core"?

> the akonadi guys are going to go and talk to the others and try to work out how
> to go forward, and then we'll see how it goes.  so, closing without prejudice
> based on mutual agreement.

cool ...

To avoid misconceptions about Akonadi for those who were not part of the
discussion and are only reading this comments we'd like to responde to the 
items presented above.

> * akonadi does not have wide adoption outside kde at the moment, and
> discussions with various people a while ago revealed a number of
> concerns about it

As for the adoption, we had assumed that part of freedesktop.org's goals
was to make cross-desktop solutions to common problems more known outside
the original conception, e.g. GStreamer moving from GNOME infrastructure
to here in order to avoid mistakingly being assumed to contain GNOME
dependencies.

As for the "various concerns", you find us quite surprised and puzzled.
If there had been a number of concerns voiced by several people, surely
those concerns would have been communicated with us.
Concerns not known to us can obviously not be addressed or even less
resolved.

>  * lack of at least a proof-of-concept non-c++ implementation is a
> bit of an issue

Nothing at http://www.freedesktop.org/wiki/MissionStatement hints that system 
or session daemons, being language neutral by virtue of communication through 
open protocols, would be required to have a non-c++ implementation.

As for the client library, the KDE based one will obviously be hosted at KDE 
since it is part of the KDE application framework.
We have actively tried to get one at least started based on a C/GLib stack, 
e.g. by reserving a Google Summer of Code slot allocated to KDE for that 
task. Unfortunately no student applied for this project.
However we continue to explore options for making alternative client library 
implementations happen.

>  * the main concern raised was the breadth of akonadi's scope; it's
> possible that a hypothetical cross-desktop solution would end up
> being a subset of akonadi and used by both akonadi and other desktop
> projects

Most likely a misunderstanding of the project or its goals.
Akonadi's main purpose is to be a cache for PIM data, like a web proxy between 
end user application and actual data source.

Therefore the shared component which we assumed would best be hosted at a 
shared site would have been the Akonadi Server, the process managing the 
cache and Akonadi Control, the process knowing where to find helper processes 
and how to start them.