[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