Request to merge enterprise4 Kleopatra into trunk before KDE 4.1

[Marc Mutz]

Hei,

First of all: yes, there are new features, and lots of new strings. Read on, 
though.

Kleopatra is still being actively developed as part of the upcoming gpg4win 
v2.0 (www.gpg4win.org). Because of the (overly long, IMHO) feature and string 
freeze, some of the scheduled features and lots of usability improvements 
(all of which involve string changes, naturally) had to be done in 
enterprise4 branch.

There are two facts to consider here:
1. Kleopatra/trunk is effectively unmaintained, and unusable.
   In a perfect world, we would have the resources to backport non-feature,
   non-string fixes, and to argue the case of every string change that we need
   to do. Sadly, we plain don't have the resources.
   Because of branch-off point was rather arbitrary, the Kleopatra that is in
   trunk is effectively unusable. I define unusable as "the customer rejected
   that state even for piloting" :)
2. Kleopatra/e4 is actively maintained, and externally QA'ed by at least three
   different stakeholders with high interest in stability and usability
   (Intevation, g10 code, customer). It isn't ready yet, though, and
   there /will/ be new strings and changes to existing strings up to beginning
   of July. But, it's usable (ie. it's being accepted for piloting by the
   customer).

Given these two facts, and the rather long time before KDE 4.1.0 final, I 
would like to request merging back _all_ of Kleopatra from e4 to trunk, 
probably towards end of June.

For KDE-Windows, there's a third thing to consider:
3. Kleopatra/e4 doesn't need gpgme-qt anymore.
   Kleo/e4 has been ported to use gpgme multithreaded, which gets rid of the
   kludge of having gpgme(-qt) link against Qt for event loop integration.
   This was a major pain for the kde-windows packagers, and this step was
   taken after consultation with a few of them on LinuxTag 2008.
   Truth be told, we're still fighting with problems related to this, e.g.
   keylistings hang on Unix (probably a gpg/sm/gpgme bug) quite often, but
   we're in the process of solving them together with g10 code. This also
   affects KMail.

This is the main reason I don't ask for merging now and continuing development 
in trunk.

For the translators, I should mention that in addition to new strings from 
kleopatra.po, there is a big update to Kleopatra's handbook in the pipeline, 
including screenshots.

To summarize: If you agree to the merge, users will get a much more smooth, 
stable, and feature-complete Kleopatra, and a handbook that isn't hopelessly 
out of date. They might, however, depend on the latest gpgme and gnupg. If 
there are relevant bugfixes in there, that holds even for Unix. On OS X and 
esp. on Windows, the very latest version will be required in any case, but 
that's not surprising, as they're supported for the first time.

The alternative is to disable Kleopatra in KDE 4.1, since I won't accept bug 
reports against an unusable prerelease version. But even though Kleopatra as 
an application isn't the most high-profile application in KDEPIM :), trunk 
libkleo would still force kde-windows to continue to deal with gpgme-qt.

So, as a third alternative, we could merge gpgme++ (which is BIC, but not part 
of KDE, in fact, there's talk to host it inside gpgme svn), qgpgme and 
libkleo to get rid of gpgme-qt, and not merge Kleopatra  (which means 
disabling it in trunk). This includes the dependency chain from the first 
alternative.

Opinions?

Thanks,
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080614/65455188/attachment.pgp