Jump to content

KDE PIM/Meetings/Osnabrueck 10: Difference between revisions

From KDE Community Wiki
← Older edit
Greve (talk | contribs)
9 edits
Bernhard (talk | contribs)
24 edits
 
(68 intermediate revisions by 12 users not shown)
Line 1: Line 1:
The annual [[KDE_PIM/Meetings|KDE PIM Meeting]] Osnabrück 10 is currently in a planning state. It will take place on  '''10.2.2012 - 12.2.2012''' at the [http://www.intevation.de/ Intevation] offices in Osnabrück. Participation is open please enter yourself to: https://sprints.kde.org/sprint/68
The annual [[KDE_PIM/Meetings|KDE PIM Meeting]] Osnabrück 10 took place from 10.2.2012 to 12.2.2012 at the [http://www.intevation.de/ Intevation] offices in Osnabrück. See the dot story [http://dot.kde.org/2012/02/17/kde-pim-sprint-10-accomplished KDE PIM Sprint 10: ACCOMPLISHED!] for a report about the sprint.


Accomodation and Travel will be organized on the [https://sprints.kde.org/sprint/68 Sprint page]
== Topics ==


=== Projects ===


== Topics ==
''Projects we'll work on in small groups, mostly coding or creating other concrete results.''
 
=== Misc ===


* Nepomuk integration in KMail (and possibly other PIM applications) in respect to the feeder rewrite.
* Nepomuk integration in KMail (and possibly other PIM applications) in respect to the feeder rewrite.
* Groupwise calendar resource for Akonadi
* Groupwise calendar resource for Akonadi
* Akonadi importer for Polka
* Akonadi importer for Polka
* Zanshin
* Porting KTimeTracker away from KResources
* KMail migration
* Wiki
* KAlarm Akonadi resource
* Stabilizing Akonadi IMAP resource
* Writing: Explaining Akonadi
* Writing: Report on status of Akonadi
* Document Kolab's use of Akonadi
* Java library to access Kolab IMAP
* GSoC 2012
* Revive the Akoandi part table optimization branch (Volker: I need SQL help for this)
* Retrieval during transaction safety issue in the Akonadi server
=== Discussions ===


=== Marketing ===
''Discussions about topics, which are relevant to all or a sub group of people. Please state audience and desired result of the discussion.''


Akonadi and as a consequence KMail and the other PIM applications still have a pretty bad reputation. People perceive it as slow, using too much memory, or generally unstable. We should identify what are real problems and what is myth and come up with a plan how to address both.
==== Future Development ====


Basically, there are two issues:
'''Audience:''' all, '''Desired Results:''' Plan regarding future 4.x releases and port to KF5
*Akonadi is perceived to be useless
*Akonadi is perceived to be unstable, buggy, slow


Both can be addressed by some decent articles and improvements to the website(s). The recent 'what did we fix in KMail' was great way of addressing the second point and we need to start writing about concrete examples of what will be possible (and esp about what is already done) asap to address the first issue.
* Update on the KF5 efforts
** First release of KF5, i.e 5.0, after release of Qt 5.1 which means 2013
** KDE SC 4.9 and 4.10 will happen
* What changes do we want to do in e.g. kdepimlibs, kdepim, etc., for KF5?
** Port everything away from Qt3Support, KDE3Support, KResources, old KCal
** Drop applications we cannot port
** Where: in master
** When: until 4.10
* What does KF5 mean for KDE PIM? When are we going to port to KF5?
** Switch to KF5 at Osnabrück 11
 
==== Marketing ====
 
'''Audience:''' all, '''Desired Results:''' Input on timeline, facts on good things on Akonadi, agreement on communication, group hug
 
We have three user groups for Kontact:
* pim developers
* kde 'family' (fellow devs, community members, power users/fans)
* wider community
Upon experiencing a serious bug, a PIM developer would (attempt to) fix it; a family member would restart Akonadi (work around the bug) and send in a bug report; while an user from the wider community would switch to Thunderbird.
 
=====What is the issue?=====
We're not ready yet for the wider community; but since 4.7 we are for our "family". We need them to test and help out! Unfortunately, we lost them because after 3 years of "we're almost done, it will get better", KDEPIM 4.7 was disappointing, especially the .0.
 
What we did was '''not wrong''' - OK, it took us a while to get Akonadi to this point, longer than we thought. But 4.7.0 was not released that early - we're only 6 months further and the vast majority of the issues is fixed. This is Free Software - release early, release often.
 
It was our '''communication''' during the 3 years before which was a bit too optimistic and which made people leave when 4.7, our "first" release, was seen as "again a disappointment". You know your marketeers, we are sometimes a tad too enthusiastic. I humbly apologize for that...
 
But that is history. Now the challenge is: get our KDE friends back.
 
=====How do we win our friends back?=====
We thought about saying sorry. But that just makes us all feel bad and invites a blame game. So let's '''just move on''': we're all unhappy with the last 3 years but the good news is that we're on the way back to '''awesomeness'''. This is what we have to communicate now! Part of that is to distance us from what happened. As the terms Akonadi and Nepomuk are quite tainted, we think it's best to start to avoid them. So:
 
# '''Get rid of the old:''' change our communication about Akonadi and Nepomuk. For end users, they are irrelevant and their names are tainted. We need to start talking about Kontact (Desktop) with Kontact Mail, Kontact Calendar etc. Akonadi and Nepomuk are implementation details - we just have the new Kontact PIM backend and the Kontact UI's.
# '''And welcome the new:''' make clear to our community that we're on the way up now and that we need their help to find existing issues. This requires some 'proof' of what's been done and where we are and of course continued repetition of that message (status updates).
# '''Tell the big story to show things have changed''': The bold task of refactoring the solution is now fully completed. We started from a mixture of single applications, each with GUI and data handling aspects, pressed into a thin shell. The aim was to create an groupware software product that is more integrated, but technically als more modular with the technical border drawn at the right places. Now it all came to gether for the first time we have an integrated Kontact experience. Technical there is a non-gui pim backend and several graphical views on it. TODO: Add graphic to show this transition.
 
=====Tasks=====
# Change the wiki pages to reflect 1 - Done
# Communicate 1 to the marketing team. (we won't do a big announcement or anything, just mention it in the sprint report & start using it) Jos
# Find a good time to do 2 - in 1-2 weeks (ask for help with cleaning up bug list, not sending bugs yet)
# Gather the needed information for 2 (list of bugs fixed/improvements over last months/year/etc, maybe comparison to other solutions etc) (Sunday task)
# Start to address some myths and write 'pull' article(s)/blog(s) about the real, refactored Kontact
# Write an article for 2 (Jos, in progress)
# ...
# Profit!
 
==== libkolabxml ====
 
'''Audience:''' people interested in Kolab, '''Desired results:''' Decide about exposed payload formats
 
State & implementation of the new XSD based Kolab library, see
* http://kolab.org/pipermail/kolab-format/2011-December/001568.html
* http://kolab.org/pipermail/kolab-format/2011-December/001569.html
including:
* Which payload format could/should be exposed through ASAP for Server Side Akonadi clients?
 
==== Server Side Akonadi ====
 
'''Audience:''' people interested in Kolab, '''Desired results:''' design decisions


=== Server Side Akonadi ===
See http://wiki.kolab.org/User:Greve/ServerSideAkonadi
See http://wiki.kolab.org/User:Greve/ServerSideAkonadi


=== KDE PIM on Mobile ===
Points to discuss:
* Dependencies, in particular kcalcore, kabc
* Formats, see above
* D-Bus related concerns for server architecture
 
==== KDE PIM on Mobile ====
 
'''Audience:''' mobile people, '''Desired result:''' Plan for future developments


How is Kontact and other parts of KDE PIM doing on the N9, on Android, on other mobile platforms?
How is Kontact and other parts of KDE PIM doing on the N9, on Android, on other mobile platforms?
What are our goals for future development, is the current variety of target platforms and features sustainable? Who is working on it?
===== Distribution =====


Kontact Touch should be available through the community app store, rather than hand-b0rked installation, see
Kontact Touch should be available through the community app store, rather than hand-b0rked installation, see


http://apps.formeego.org/applications/
* http://apps.formeego.org/applications/
http://www.slideshare.net/jukkaeklund/fosdem2012-community-apps-repository/
* http://www.slideshare.net/jukkaeklund/fosdem2012-community-apps-repository/
http://bergie.iki.fi/blog/application_quality_assurance_in_linux_distributions/
* http://bergie.iki.fi/blog/application_quality_assurance_in_linux_distributions/


How to make that happen?
How to make that happen?
==== Akonadi bugs ====
'''Audience:''' Akonadi developers, '''Desired results:''' Update list of bugs
Getting input on a number of Akonadi bugs
==== Resource scheduler ====
'''Audience:''' Akonadi developers, '''Desired results:''' Design for resource scheduler
* ResourceBase scheduler is designed for the simple, common case of serial access resources.
* IMAP wants to run tasks in parallel, so that'll need a different scheduler
* IMAP also wants a specialized 2-phase sync
* Custom scheduler and custom sync would mean by-passing most of ResourceBase
* David will implement a ResourceBase base-class that provides the resource interface but not a built-in scheduler and syncer
* IMAP will be re-based to that new base class and get a custom scheduler and syncer
==== Maildir flags ====
<s>'''Audience:''' KMail developers, '''Desired result:''' Decide how to handle maildir flags
Discussing handling of maildir flags</s>
Andras: Maildir should write out correctly the message flags into the file name since 4.7.2.
==== Storing calendar colors for Kolab calendars ====
'''Audience:''' Korganizer people / people interested in Kolab, '''Desired result:''' Implementation (plan) for storage of calendar colors according to KEP 12.
See [http://wiki.kolab.org/KEP:12 KEP 12: Color configuration storage for resources and categories] for the specification.
==== Porting KTimeTracker away from KResources ====
<s>'''Audience:''' Calendaring people, '''Desired result:''' Port KTimeTracker away from KResources</s>
KTimeTracker won't be ported to Akonadi because it only uses ical storage as an implementation detail. The ical file isn't exposed to the user.
<s>Sérgio is currently porting KTimeTracker from KResources to KCalCore.</s> DONE
==== Saving searches & results in cross-client scenarios ====
'''Audience:''' people interested in Kolab, '''Desired result:''' Design parameters for system that would work for Akonadi as well as server side clients, e.g. Roundcube & Co.
This is a subject that has been started as a discussion in the Kolab community, but never been fully thought through or finalized as a design. For input, see  [http://wiki.kolab.org/User:Greve/Drafts/KEP:15 KEP 15: Saved searches and sharing searches across all clients]
==== Contact Aggregation ====
'''Audience:''' People interested in contact management and/or Nepomuk, '''Desired result:''' Coordination with KTP team
* conf call with KTP team to coordinate current efforts '''Sun 13:00'''
* plan on integrating that into kdepim mainline
=== Presentations ===
''Presentations of things interesting to the KDE PIM community. Please state targeted audience.''
* Bachelor thesis: REST interface for Kolab (Thomas Koch) ('''Audience:''' people interested in Kolab)
* Server side Akonadi (Georg Greve) ('''Audience:''' people interested in Akonadi and Kolab)
* libkolabxml (Christian Mollekopf) ('''Audience:''' people interested in Kolab)
* Plasma workspace integration (Kevin Krammer) ('''Audience:''' people interested in KDE desktop)


== Agenda ==
== Agenda ==
Line 41: Line 184:
=== Friday ===
=== Friday ===


Arrival and start to meet and work
16:00 Start meeting, fill agenda, get organized
 
~19:30 Dinner at Chow's Garden (Japaneese / Asian Food)


=== Saturday ===
=== Saturday ===
10:00 Review first batch of work, get organized
10:30-12:00 Presentations, discussions targeted at whole group
13:30 Group photo
14:00 [http://wiki.stoppacta-protest.info/DE:Demo:Osnabrück Stopp-ACTA Demo]
17:00 Review second batch of work, get organized
17:30-18:30 Presentations, discussions targeted at whole group
20:00 Dinner at Arabesque (Arabian Food http://www.arabesque-osnabrueck.de/)


=== Sunday ===
=== Sunday ===


10:00 Review third batch of work, get organized
10:30-11:30 Presentations, discussions targeted at whole group
13:00 Conf call with KTP team
14:00 Close meeting, collect next steps
== Meeting Notes ==
=== Collection Colors ===
Store in Akonadi::EntityDisplayAttribute, propagate to/from mailbox annotation in Kolab resource. Christian will implement it.
=== IMAP 5 ===
Input from both our needs in the IMAP resource and our changes to IMAP for ASAP are relevant for the IMAP 5 efforts. Some specific points mentioned were:
* remove concept of currently selected mailbox
* ability to receive change set since last sync
* change notifications for more than a single mailbox
Georg will find time for Kevin O. and Volker to participate in the process.
=== KAlarm and Akonadi ===
A major bug in KAlarm whereby it failed to create default Akonadi resources on first initialisation and therefore became unusable, has finally been fixed. It turned out to be due to a combination of bugs in KAlarm and in Akonadi. This would have been very difficult to fix without face to face discussion and debugging. Thanks to Volker for his help.
=== ktimetracker ===
Sergio and Thorsten agree that ktimetracker should be ported from KResources to KCalCore.
Sergio ported ktimetracker from KResources to KCalCore.
=== Part Table Optimization ===
SQL upgrade code done (thanks to Bernhard Herzog), however the process takes ~10 minutes to complete.
Various options on how to communicate that to users have been discussed. A notification UI process (ie. a simplified Qt-only kdialog shipped with Akonadi) will be launched by the Akonadi server for this. Volker will implement it.
Other still pending tasks:
* Test database schema upgrade with SQLite
=== Akonadi Git Resource ===
Sergio fixed remaining important bugs and moved the project to playground.
=== Desktop-wide progress/status notification for agents ===
Use KNotification from inside AgentBase/ResourceBase for progress and error/warning signals. Other options discussed included a kded module or akonaditray, but they add to much infrastructure complexity for no real gain.


== Blogs ==


== Date Finding Table (for reference)==
* [http://ervin.ipsquad.net/2012/02/12/kde-pim-sprint/ Osnabrück KDE PIM Sprint 2012] (Kevin Ottens)
* [http://blogs.kde.org/node/4535 A very productive KDEPIM meeting in Osnabrück] (David Faure)
* [http://blog.cornelius-schumacher.de/2012/02/releasing-polka-09.html Releasing Polka 0.9] (Cornelius Schumacher)
* [http://www.staerk.de/thorsten/Osnabrueck_2012 Thorsten's]


'''Legend:''' <br />
== Organization ==
X: available <br />
- (or empty): not available <br />
?: available but troublesome <br />


{| class="wikitable" border="1"
See the [[KDE_PIM/Meetings/Osnabrueck_10/Organization|Osnabrück 10 organization]] page for organizational details.
|+ Available on
|-
! Name
! 6.-8.1
! 13.-15.1
! 20.-22.1
! 27.-29.1
! 10.-12.2
! 17.-19.2
! 24.-26.2
! 3.-4.3
|- <!-- Comments are there only for copy and paste conveniance -->
| Andre Heinecke
| ? <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Georg Greve
| ? <!--6-8.1-->
| - <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Björn Ricks
| ? <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| - <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Sérgio Martins
| ?? <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Christian Mollekopf
| - <!--6-8.1-->
| - <!--13-15.1-->
| - <!--20-22.1-->
| - <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|-
| Kevin Ottens
| - <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| - <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| - <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Bernhard Reiter
| X <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| ? <!--17-19.2-->
| ?? <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Guy Maurel
| - <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| [[ThorstenStaerk]]
| X <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Christoph Wickert
| X <!--6-8.1-->
| - <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| - <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| David Jarvie
| - <!--6-8.1-->
| - <!--13-15.1-->
| - <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| - <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Till Adam
| - <!--6-8.1-->
| - <!--13-15.1-->
| X <!--20-22.1-->
| - <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| David Faure
| X <!--6-8.1-->
| X <!--13-15.1-->
| - <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Volker Krause
| X <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Thomas McGuire
| - <!--6-8.1-->
| - <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Cornelius Schumacher
| X <!--6-8.1-->
| ? <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Andras Mantia
| ? <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| - <!--24-26.2-->
| - <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Stephen Kelly
| - <!--6-8.1-->
| X <!--13-15.1-->
| - <!--20-22.1-->
| - <!--27-29.1-->
| X <!--10-12.2-->
| - <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Torgny Nyblom
| - <!--6-8.1-->
| - <!--13-15.1-->
| - <!--20-22.1-->
| - <!--27-29.1-->
| - <!--10-12.2-->
| - <!--17-19.2-->
| - <!--24-26.2-->
| - <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Camila Ayres
| X <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Jos Poortvliet
| X <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| ? <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Jeroen van Meeuwen
| - <!--6-8.1-->
| - <!--13-15.1-->
| X <!--20-22.1-->
| X <!--27-29.1-->
| X <!--10-12.2-->
| X <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|- <!-- Comments are there only for copy and paste conveniance -->
| Ingo Klöcker
| X <!--6-8.1-->
| X <!--13-15.1-->
| X <!--20-22.1-->
| - <!--27-29.1-->
| X <!--10-12.2-->
| - <!--17-19.2-->
| X <!--24-26.2-->
| X <!--3.-4.3-->
|-
|}

Latest revision as of 14:50, 6 March 2012

The annual KDE PIM Meeting Osnabrück 10 took place from 10.2.2012 to 12.2.2012 at the Intevation offices in Osnabrück. See the dot story KDE PIM Sprint 10: ACCOMPLISHED! for a report about the sprint.

Topics

Projects

Projects we'll work on in small groups, mostly coding or creating other concrete results.

  • Nepomuk integration in KMail (and possibly other PIM applications) in respect to the feeder rewrite.
  • Groupwise calendar resource for Akonadi
  • Akonadi importer for Polka
  • Zanshin
  • Porting KTimeTracker away from KResources
  • KMail migration
  • Wiki
  • KAlarm Akonadi resource
  • Stabilizing Akonadi IMAP resource
  • Writing: Explaining Akonadi
  • Writing: Report on status of Akonadi
  • Document Kolab's use of Akonadi
  • Java library to access Kolab IMAP
  • GSoC 2012
  • Revive the Akoandi part table optimization branch (Volker: I need SQL help for this)
  • Retrieval during transaction safety issue in the Akonadi server

Discussions

Discussions about topics, which are relevant to all or a sub group of people. Please state audience and desired result of the discussion.

Future Development

Audience: all, Desired Results: Plan regarding future 4.x releases and port to KF5

  • Update on the KF5 efforts
    • First release of KF5, i.e 5.0, after release of Qt 5.1 which means 2013
    • KDE SC 4.9 and 4.10 will happen
  • What changes do we want to do in e.g. kdepimlibs, kdepim, etc., for KF5?
    • Port everything away from Qt3Support, KDE3Support, KResources, old KCal
    • Drop applications we cannot port
    • Where: in master
    • When: until 4.10
  • What does KF5 mean for KDE PIM? When are we going to port to KF5?
    • Switch to KF5 at Osnabrück 11

Marketing

Audience: all, Desired Results: Input on timeline, facts on good things on Akonadi, agreement on communication, group hug

We have three user groups for Kontact:

  • pim developers
  • kde 'family' (fellow devs, community members, power users/fans)
  • wider community

Upon experiencing a serious bug, a PIM developer would (attempt to) fix it; a family member would restart Akonadi (work around the bug) and send in a bug report; while an user from the wider community would switch to Thunderbird.

What is the issue?

We're not ready yet for the wider community; but since 4.7 we are for our "family". We need them to test and help out! Unfortunately, we lost them because after 3 years of "we're almost done, it will get better", KDEPIM 4.7 was disappointing, especially the .0.

What we did was not wrong - OK, it took us a while to get Akonadi to this point, longer than we thought. But 4.7.0 was not released that early - we're only 6 months further and the vast majority of the issues is fixed. This is Free Software - release early, release often.

It was our communication during the 3 years before which was a bit too optimistic and which made people leave when 4.7, our "first" release, was seen as "again a disappointment". You know your marketeers, we are sometimes a tad too enthusiastic. I humbly apologize for that...

But that is history. Now the challenge is: get our KDE friends back.

How do we win our friends back?

We thought about saying sorry. But that just makes us all feel bad and invites a blame game. So let's just move on: we're all unhappy with the last 3 years but the good news is that we're on the way back to awesomeness. This is what we have to communicate now! Part of that is to distance us from what happened. As the terms Akonadi and Nepomuk are quite tainted, we think it's best to start to avoid them. So:

  1. Get rid of the old: change our communication about Akonadi and Nepomuk. For end users, they are irrelevant and their names are tainted. We need to start talking about Kontact (Desktop) with Kontact Mail, Kontact Calendar etc. Akonadi and Nepomuk are implementation details - we just have the new Kontact PIM backend and the Kontact UI's.
  2. And welcome the new: make clear to our community that we're on the way up now and that we need their help to find existing issues. This requires some 'proof' of what's been done and where we are and of course continued repetition of that message (status updates).
  3. Tell the big story to show things have changed: The bold task of refactoring the solution is now fully completed. We started from a mixture of single applications, each with GUI and data handling aspects, pressed into a thin shell. The aim was to create an groupware software product that is more integrated, but technically als more modular with the technical border drawn at the right places. Now it all came to gether for the first time we have an integrated Kontact experience. Technical there is a non-gui pim backend and several graphical views on it. TODO: Add graphic to show this transition.
Tasks
  1. Change the wiki pages to reflect 1 - Done
  2. Communicate 1 to the marketing team. (we won't do a big announcement or anything, just mention it in the sprint report & start using it) Jos
  3. Find a good time to do 2 - in 1-2 weeks (ask for help with cleaning up bug list, not sending bugs yet)
  4. Gather the needed information for 2 (list of bugs fixed/improvements over last months/year/etc, maybe comparison to other solutions etc) (Sunday task)
  5. Start to address some myths and write 'pull' article(s)/blog(s) about the real, refactored Kontact
  6. Write an article for 2 (Jos, in progress)
  7. ...
  8. Profit!

libkolabxml

Audience: people interested in Kolab, Desired results: Decide about exposed payload formats

State & implementation of the new XSD based Kolab library, see

including:

  • Which payload format could/should be exposed through ASAP for Server Side Akonadi clients?

Server Side Akonadi

Audience: people interested in Kolab, Desired results: design decisions

See http://wiki.kolab.org/User:Greve/ServerSideAkonadi

Points to discuss:

  • Dependencies, in particular kcalcore, kabc
  • Formats, see above
  • D-Bus related concerns for server architecture

KDE PIM on Mobile

Audience: mobile people, Desired result: Plan for future developments

How is Kontact and other parts of KDE PIM doing on the N9, on Android, on other mobile platforms?

What are our goals for future development, is the current variety of target platforms and features sustainable? Who is working on it?

Distribution

Kontact Touch should be available through the community app store, rather than hand-b0rked installation, see

How to make that happen?

Akonadi bugs

Audience: Akonadi developers, Desired results: Update list of bugs

Getting input on a number of Akonadi bugs

Resource scheduler

Audience: Akonadi developers, Desired results: Design for resource scheduler

  • ResourceBase scheduler is designed for the simple, common case of serial access resources.
  • IMAP wants to run tasks in parallel, so that'll need a different scheduler
  • IMAP also wants a specialized 2-phase sync
  • Custom scheduler and custom sync would mean by-passing most of ResourceBase
  • David will implement a ResourceBase base-class that provides the resource interface but not a built-in scheduler and syncer
  • IMAP will be re-based to that new base class and get a custom scheduler and syncer

Maildir flags

Audience: KMail developers, Desired result: Decide how to handle maildir flags

Discussing handling of maildir flags

Andras: Maildir should write out correctly the message flags into the file name since 4.7.2.

Storing calendar colors for Kolab calendars

Audience: Korganizer people / people interested in Kolab, Desired result: Implementation (plan) for storage of calendar colors according to KEP 12.

See KEP 12: Color configuration storage for resources and categories for the specification.


Porting KTimeTracker away from KResources

Audience: Calendaring people, Desired result: Port KTimeTracker away from KResources

KTimeTracker won't be ported to Akonadi because it only uses ical storage as an implementation detail. The ical file isn't exposed to the user.

Sérgio is currently porting KTimeTracker from KResources to KCalCore. DONE

Saving searches & results in cross-client scenarios

Audience: people interested in Kolab, Desired result: Design parameters for system that would work for Akonadi as well as server side clients, e.g. Roundcube & Co.

This is a subject that has been started as a discussion in the Kolab community, but never been fully thought through or finalized as a design. For input, see KEP 15: Saved searches and sharing searches across all clients

Contact Aggregation

Audience: People interested in contact management and/or Nepomuk, Desired result: Coordination with KTP team

  • conf call with KTP team to coordinate current efforts Sun 13:00
  • plan on integrating that into kdepim mainline

Presentations

Presentations of things interesting to the KDE PIM community. Please state targeted audience.

  • Bachelor thesis: REST interface for Kolab (Thomas Koch) (Audience: people interested in Kolab)
  • Server side Akonadi (Georg Greve) (Audience: people interested in Akonadi and Kolab)
  • libkolabxml (Christian Mollekopf) (Audience: people interested in Kolab)
  • Plasma workspace integration (Kevin Krammer) (Audience: people interested in KDE desktop)

Agenda

Friday

16:00 Start meeting, fill agenda, get organized

~19:30 Dinner at Chow's Garden (Japaneese / Asian Food)

Saturday

10:00 Review first batch of work, get organized

10:30-12:00 Presentations, discussions targeted at whole group

13:30 Group photo

14:00 Stopp-ACTA Demo

17:00 Review second batch of work, get organized

17:30-18:30 Presentations, discussions targeted at whole group

20:00 Dinner at Arabesque (Arabian Food http://www.arabesque-osnabrueck.de/)

Sunday

10:00 Review third batch of work, get organized

10:30-11:30 Presentations, discussions targeted at whole group

13:00 Conf call with KTP team

14:00 Close meeting, collect next steps

Meeting Notes

Collection Colors

Store in Akonadi::EntityDisplayAttribute, propagate to/from mailbox annotation in Kolab resource. Christian will implement it.

IMAP 5

Input from both our needs in the IMAP resource and our changes to IMAP for ASAP are relevant for the IMAP 5 efforts. Some specific points mentioned were:

  • remove concept of currently selected mailbox
  • ability to receive change set since last sync
  • change notifications for more than a single mailbox

Georg will find time for Kevin O. and Volker to participate in the process.

KAlarm and Akonadi

A major bug in KAlarm whereby it failed to create default Akonadi resources on first initialisation and therefore became unusable, has finally been fixed. It turned out to be due to a combination of bugs in KAlarm and in Akonadi. This would have been very difficult to fix without face to face discussion and debugging. Thanks to Volker for his help.

ktimetracker

Sergio and Thorsten agree that ktimetracker should be ported from KResources to KCalCore.

Sergio ported ktimetracker from KResources to KCalCore.

Part Table Optimization

SQL upgrade code done (thanks to Bernhard Herzog), however the process takes ~10 minutes to complete.

Various options on how to communicate that to users have been discussed. A notification UI process (ie. a simplified Qt-only kdialog shipped with Akonadi) will be launched by the Akonadi server for this. Volker will implement it.

Other still pending tasks:

  • Test database schema upgrade with SQLite

Akonadi Git Resource

Sergio fixed remaining important bugs and moved the project to playground.

Desktop-wide progress/status notification for agents

Use KNotification from inside AgentBase/ResourceBase for progress and error/warning signals. Other options discussed included a kded module or akonaditray, but they add to much infrastructure complexity for no real gain.

Blogs

Organization

See the Osnabrück 10 organization page for organizational details.

Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/Meetings/Osnabrueck_10&oldid=18502"