Re: how to deal with kdepimlibs patches

On 2012-06-08 12:39, Christian Mollekopf wrote:
> Hey Jeroen,
>
> I was wondering how we can deal with kdepimlibs patches, which are 
> required
> for libkolab.
>

Normally, a ticket is created upstream for inclusion of a fix or 
enhancement.

This ticket would allow for discussion, review, and (hopefully), 
finally, acceptance, with a version the patch is against and a milestone 
for inclusion (and sometimes also the odd backport to current version 
request).

Along with such ticket is usually a ticket- or topic-branch (if the 
changes are somewhat intrusive or not likely to make it into a 
mainstream branch right-away), and usually such branch is upstream (when 
the developer is also an upstream developer).

I think it's fair enough to say our milestone is ASAP, i.e. 4.9. I 
think it's fair to start with master, in the sense that anything in 
development (including bugfixes etc.) should first end up in the next 
version, and optionally be backported to one or more "current" versions, 
as opposed to enhancing  or fixing one or more "current" versions and 
attempting to forward-port to master.

After all, it's easier to say to a consumer "wait for the next 
version", than it is to tell a consumer "stick with this 'current' 
version forever".

> 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).
>

:(

I'll include the topic of pragmatic source code management in my "KDE 
Releases That Just Work(TM)" session at Akademy this year.

> 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.
>

This has notoriously been very problematic. Ensuring patches end up 
upstream is to developers what documentation is to sysadmins; once the 
actual underlying task is done it tends to fade to the background 
because something new and more urgent will pop up on one's radar.

In my opinion, it is going to happen upstream or it isn't going to 
happen at all.

The question of course is how, and it seems that with their freezes, 
KDE upstream is saying something more along the lines of "not yet". I 
think that's not entirely fair and perhaps even a prohibitively 
expensive "rule" they impose on themselves (and for which I see little 
reason).

In either case, a path forward with this seems to be to hammer them 
with tickets (and thus show that we care, and are actively making things 
happen).

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08