PIM/Meetings/GCDS 2009: Difference between revisions

From KDE Community Wiki
< PIM‎ | Meetings
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.