[Kolab-devel] how to deal with kdepimlibs patches

Christian Mollekopf mollekopf at kolabsys.com
Fri Jun 8 12:39:23 CEST 2012


Hey Jeroen,

I was wondering how we can deal with kdepimlibs patches, which are required 
for libkolab.
E.g. I improved the notes format in kdepimlibs, so kontact preserves all 
information of kolabnotes (i.e. the lastModified date or attachments are 
otherwise lost), which will only be available with kde 4.9.

Now I have also a patch for the imaplibrary, to allow for proxy authentication 
(for the format upgrade tool), which I can't even get into master because it's 
frozen during the release period (yes, that sucks), and will only be released 
with 4.10 (unless backported).

So I'm wondering if we should have our own clone of the repo as staging area, 
based on which we develop libkolab and friends. At least now, where a lot is 
changing, we can't wait for half a year to get our patches released. Normally, 
when master is not frozen, when can of course get patches in, but it still 
takes a while for the review process and such.

So an own clone would make us much more agile, but of course we would need to 
make sure all patches go eventually upstream.

The other issue with that is of course that libkolab  depends on a version of 
kdepimlibs >= master, but in the long run I suppose we need that flexibility if 
we want to work with kdepimlibs code.

I would see the kdepimlibs clone as intermediate step until we can split up 
kdepimlibs anyways.

What do you think?

Cheers,
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120608/a1138a65/attachment.sig>


More information about the devel mailing list