| Summary: | Project infrastructure for desktop PIM service Akonadi | ||
|---|---|---|---|
| Product: | freedesktop.org | Reporter: | Kevin Krammer <kevin.krammer> |
| Component: | Project Creation Requests | Assignee: | fd.o Admin Massive <sitewranglers> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | dgollub, lemma, mail, marcus, rdieter, tomalbers, toscano.pino, tuju |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Kevin Krammer
2008-04-25 10:18:46 UTC
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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.