[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    [Kde-pim] kdepim meeting minutes (akademy)
From:       David Faure <faure () kde ! org>
Date:       2004-08-26 9:25:09
Message-ID: 200408261125.10453.faure () kde ! org
[Download RAW message or body]

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/


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic