From kde-pim Thu Aug 26 09:25:09 2004 From: David Faure Date: Thu, 26 Aug 2004 09:25:09 +0000 To: kde-pim Subject: [Kde-pim] kdepim meeting minutes (akademy) Message-Id: <200408261125.10453.faure () kde ! org> X-MARC-Message: https://marc.info/?l=kde-pim&m=109351225402353 kdepim meeting minutes Ludwigsburg, 25/08/2004 Michael Brade Reinhold Kainhofer Juergen Nagel Ingo Kloecker Bo Thorsen Till Adam Andreas Gungl Marc Mutz Volker Krause Bernhard Reiter Cornelius Schumacher David Faure Bram Schoenmakers Giovanni Venturi Lutz Rogowski Tobias Koenig Daniel Molkentin Jan Muehlig (openusability.org) * Next kdepim release If there is a kde-3.4 release, releasing kdepim-3.4 at the same time would be easier. Otherwise we need kde-i18n-3.3.x to contain the translations for kdepim-3.3 *and* kdepim-3.4. So it's doable, but requires some more work. In any case, there are (or will be soon) enough new features for a kdepim-3.4 release beginning of next year. The goals of that release: - Polishing (the term "usability release" was used several times) Focusing on "smoothing the rough edges". - non-blocking (and imap) filtering in kmail - kolab2 support proko2 can be merged into HEAD easily, will be done before the next release. Annotations and kmail changes can be merged first; xml-storage resource later. Schedule: - 6 months, i.e. Q1 2005. Policies: - It was decided to switch to kdelibs-3.3: It gives us the ability to use kspell2. It allows us to remove some code duplication (classes copied to kdepim). kdelibs-3.2 compat made things easier for developers, but now kdelibs-3.3 requirement makes things easier for developers (which would otherwise have to keep kdelibs-3.2 around and keep forking the kdelibs classes into libkdepim). A kdelibs-3.3 requirement makes things easier for everyone this time around. The proko2 project doesn't have a problem with this since it's based on kdepim-3.3-branch. Version: - 3.4 Meanwhile we will of course keep fixing the bugs in the kdepim-3.3-branch. The question was raised whether it would be ok to change some i18n messages and add a few features there, for instance to be able to have 3.3.1 released with full kolab2 support. But this is generally a problem for translators. Joke: how to get kde-3.3.1 out faster? Simple: find a security bug :-) * Library "consolidation": - libkdepim and libkdenetwork's roles are unclear. The following was decided upon: libkdenetwork/kmime -> libkmime libkdenetwork/kpgp -> libkpgp the rest of libkdenetwork (some shared classes) moves to libkdepim libkpimexchange should be moved to the exchange resource after getting rid of the old exchange plugin libical should be moved into libkcal, since only libkcal uses it. * Licensing Policy for new code in kdepim: kdelibs compatible or GPL+Qt exception. The idea is to help with a native windows port; but any library being used that is GPL (like gpgme, mimelib etc.) makes it impossible. Marc Mutz is looking into solutions (asking gpgme people for a qt exception; writing libkmime2 at some point...) Discussion about GPL libs in kdelibs. Marc Mutz wants to be able to make the future libkmime GPL and yet put it in kdelibs; the kdgantt cross-module duplication (because it's GPL) is a problem too. Maybe kdelibs could allow some GPL libraries (and have a --disable-gpl switch for proprietary development), or we could have another module than kdelibs with libraries in it, less general purpose and less strict wrt licensing. To be discussed with the rest of the KDE project. * Kolab documentation Kolab user documentation should be available in the docbook ("online help") documentation. KDAB is currently working on that, Matt Douhan is apparently doing some of that too, this will need coordination. * Kolab-related PR for kontact Shouldn't be done before fully useable, because people's expectations are high. Different scalability solution than other groupware solutions. * Groupware servers Weekend meetings for opengroupware integration. Who is interested in participating? Cornelius and Tobias. Exchange integration will be helped by the opengroupware integration (same protocol). Being able to test exchange servers would be good for fixing the last exchange-resource bugs. Maybe someone could give test accounts to kdepim developers? We have to be careful about our public statements on which groupware servers are supported. Business users expect that a "supported server" means fully supported, i.e. all features. For things like our current support of the exchange server, better say "partially supported". * Porting to other platforms We are ok with companies porting kdepim to windows, but we don't have the resources to support it ourselves. The cygwin solution is almost completely useable for end users (on a modern machine); the problem is mostly the installation. The cygwin solution also makes it easier for us to support since it's closer to the unix environment. * Usability Interaction with openusability.org. 4 developers among the ones being present did read the usability report. Feedback on the helpfulness of the reports: the report has the right level of detail, are pragmatic and to the point. Some things have to be discussed, when the implementation is made difficult by the current design, maybe compromises can be made, or other solutions found. The format of the reports (PDF, partly in german) makes it difficult to discuss things, it would be better to also post plain text to a new common mailing-list, to discuss things there. Interaction is needed very early in the process, to make the user workflow as good as possible. Usability people can send mockups, design ideas, etc. But this requires much discussion and doesn't allow "implementing it this week" (RAD). Another solution is testing several implemented solutions, but this is difficult for usability people (it takes a long time to setup test environment). Best solution is commenting on e.g. qt designer mockups and screenshots sent by developers, but when testing is required the problem remains. Kurt Pfeifle proposed in his talk to offer people an online server with up-to-date cvs using NX. Another solution is knoppix CDs, which make it easy for usability people to test things (without even needing to install linux). Snapshot RPMS for a given distribution (e.g. SuSE) are also a solution. Which mailing-list? kde-usability-devel? or a new list, e.g. kdepim-usability? Bugzilla... has usability problems too. Makes it difficult to work with many screenshots (multiple mails sent, can't interleave images and text, etc.). But well, it's still the best way to report small issues; bigger issues can be discussed on the list. For communication between openusability.org and kdepim developers, a new mailing-list was created, kdepim-usability. -- David Faure, faure@kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ kde-pim mailing list kde-pim@mail.kde.org https://mail.kde.org/mailman/listinfo/kde-pim kde-pim home page at http://pim.kde.org/