PIM/Meetings/GCDS 2009: Difference between revisions
m 8 revisions imported |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
== Meeting / BoF == | == Meeting / BoF == | ||
TBA | General planning meeting: 08th July, 18:00 at the beach. | ||
Smaller meetings about the technical details during the following days, details TBA. | |||
== Agenda == | == Agenda == | ||
| Line 9: | Line 10: | ||
Please add your stuff here: | Please add your stuff here: | ||
* Review and merge PostgreSQL patches for Akonadi | * Review and merge PostgreSQL and Sqlite patches for the Akonadi server | ||
* Discuss KNode port to new message view | * Discuss KNode port to new message view | ||
* Review (also API review) and discuss the state of the various GSoC projects | * Review (also API review) and discuss the state of the various GSoC projects | ||
| Line 19: | Line 20: | ||
* Evaluate state of KContactManager to replace KAddressBook | * Evaluate state of KContactManager to replace KAddressBook | ||
* Branch planning regarding KMail and KOrganizer porting | * Branch planning regarding KMail and KOrganizer porting | ||
* Find a solution for the single-file resource (ical, mbox, etc) bugs with file watching detecting their own changes | |||
== Meeting Notes == | |||
=== Plan for 4.4 === | |||
* Replace KAddressBook with KContactManager and rename that back to KAddressBook (to be done soonish) | |||
* Merge all work back from akonadi-ports branch soonish, with the following two exceptions | |||
** KMail: Porting should happen in the akonadi-ports branch until it's done, which will likely be for 4.5 | |||
** KOrganizer: Similar to KMail, as long as we are doing intrusive changes in there it should stay in the branch. | |||
* Frank will take care of merging the Akregator port | |||
* The filtering framework will continue to be developed in playground until it's done | |||
* The mail transport agent will be merged into trunk soonish, after review of the corresponding changes in kdepimlibs. | |||
* Migration was discussed. The question was on how the dimap cache could be imported, but no clear solution yet. | |||
=== KMail migration === | |||
* How do we deal with mixed mbox/maildir folders? | |||
** Best approach so far: convert to full maildir and import flags from the old KMail index files | |||
* Do we want to import existing DIMAP caches? | |||
** Tricky, as only the resource is allowed to set RIDs | |||
** OTOH we do not want to have legacy import code in the resource | |||
=== Notifications === | |||
* Get rid of the in-application progress reporting | |||
* Instead use the same stuff KIO uses, which allows a similar level of details and interaction, if not more. | |||
Latest revision as of 13:01, 11 March 2016
Meet the Akonadi and KDE PIM team at GCDS/Akademy 2009 :)
Meeting / BoF
General planning meeting: 08th July, 18:00 at the beach. Smaller meetings about the technical details during the following days, details TBA.
Agenda
Please add your stuff here:
- Review and merge PostgreSQL and Sqlite patches for the Akonadi server
- Discuss KNode port to new message view
- Review (also API review) and discuss the state of the various GSoC projects
- Filtering System
- Akonadi-based mail sending
- Outboxinterface
- ResourceBase::Transport (merge?)
- SyncML
- Evaluate state of KContactManager to replace KAddressBook
- Branch planning regarding KMail and KOrganizer porting
- Find a solution for the single-file resource (ical, mbox, etc) bugs with file watching detecting their own changes
Meeting Notes
Plan for 4.4
- Replace KAddressBook with KContactManager and rename that back to KAddressBook (to be done soonish)
- Merge all work back from akonadi-ports branch soonish, with the following two exceptions
- KMail: Porting should happen in the akonadi-ports branch until it's done, which will likely be for 4.5
- KOrganizer: Similar to KMail, as long as we are doing intrusive changes in there it should stay in the branch.
- Frank will take care of merging the Akregator port
- The filtering framework will continue to be developed in playground until it's done
- The mail transport agent will be merged into trunk soonish, after review of the corresponding changes in kdepimlibs.
- Migration was discussed. The question was on how the dimap cache could be imported, but no clear solution yet.
KMail migration
- How do we deal with mixed mbox/maildir folders?
- Best approach so far: convert to full maildir and import flags from the old KMail index files
- Do we want to import existing DIMAP caches?
- Tricky, as only the resource is allowed to set RIDs
- OTOH we do not want to have legacy import code in the resource
Notifications
- Get rid of the in-application progress reporting
- Instead use the same stuff KIO uses, which allows a similar level of details and interaction, if not more.