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

List:       kde-release-team
Subject:    Re: PROPOSAL: Merging Kleopatra Enterprise Branch into Trunk for 4.1
From:       Marc Mutz <mutz () kde ! org>
Date:       2008-06-16 22:57:24
Message-ID: 200806170057.44891.mutz () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]


On Tuesday 17 June 2008 00:14, Allen Winter wrote:
> On Monday 16 June 2008 11:17:34 Aaron J. Seigo wrote:
> > On Monday 16 June 2008, Allen Winter wrote:
> > > Dear Translators and Release Team,
> > >
> > > The kde-pim team would like to merge the Kleopatra enterprise branch
> > > from the Kolab Konsortium [1] into trunk for the upcoming 4.1 release.
> >
> > please excuse my ignorance: i know that kleopatra as about crypto and iir
> > certificates ... what concrete features does it bring?
>
> From the KDE3 handbook, "Kleopatra is the KDE tool for managing X.509
> certificates in the GpgSM keybox and for retrieving certificates from LDAP
> servers."
>
> > > We PIMsters really would love to have this in 4.1, as we have many
> > > users requiring excellent cryptographic support.  The code is
> > > externally QA'ed, so it is stable already. And we really need this for
> > > our Mac and Windows users.
> >
> > to ask the obvious devil's advocate question: what happens if this
> > doesn't make it into kde 4.1?
>
> I think Till or Marc can answer that best.

Playing God's Advocate (is that the opponent of the devil's advocate?): The 
death of pragmatic KDE in favor of a policy-stricken one.

No, seriously: Nothing would happen, except for disgruntled kde-windows 
packagers that have to deal with a cludge (gpgme depending on Qt, forcing 
them to compile it themselves for MSVC).

And disgruntled users that miss their Kleopatra. Because the alternative to 
merging is disabling it completely, or just the application, since what's in 
trunk is a prerelease, pre-alpha, random development snapshot.

If you need more information, please see my mail regarding this topic 
(attached).

> > i lean towards trusting the good judgement of th PIM team, i also lean
> > towards respecting te freezes ...... (that was useful input, huh? =/ )
>
> Regarding the feature freeze.. looking closer it seems that at least one of
> the two new features (openPGP support) was already in progress since before
> the feature freeze.  Not sure when the plugin for Konqueror and Dolphin was
> started.

It wasn't, and it will not be part of the merge.

> Mostly, this an issue of accepting the new strings.

Thanks,
Marc

["forwarded message" (message/rfc822)]


[Attachment #9 (multipart/signed)]


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

[Attachment #12 (application/pgp-signature)]

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[Attachment #14 (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


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