[Kolab-devel] how to deal with kdepimlibs patches

[Christian Mollekopf]

On Friday 08 June 2012 13.10:46 Jeroen van Meeuwen wrote:
> 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".
> 

Generally we're using reviewboard (git.reviewboard.kde.org) to get patches 
included instead of creating a bug. Of course there may be a bug related to 
the patch as well, but that is where the actual patch gets discussed.

Would you like to see a bug being opened as well additonally (for kolab 
related issues)?
I think the bugtracker is not really that actively used, and to me it looks 
mostly like a collection of user problems, meaning it's a bit a PITA to use as 
a developer (that's my perception anyways), which is why I also didn't really 
use it so far.

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

That would be cool.

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

Ok, I can very well imagine that.

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

Not sure anyone would notice with the number of bugs ;-)

Anyways, I don't see any problem in getting the patches in (that has always 
worked smoothly so far). It's more if we depend on the latest stable 
kdepimlibs, meaning if there is a problem I can only:
* #ifdef new fixes for the ones compiling from source, and the rest is out of 
luck
* Apply workarounds until the proper fix is released
* copy complete parts temporarily into libkolab so I can fix them

or if we generally say, with libkolab we depend on the latest kdepimlibs 
master, so unless master is frozen, I can just fix things in kdepimlibs and 
then use the fix directly in libkolab.

The more we start to actively use kdepimlibs, The more I expect to do work on 
kdepimlibs code, so I'm very much for depending on master =). Maybe once the 
dust settles we can change that to depending on the latest stable kdepimlibs.

The question is just if and how we can get a kdepimlibs snapshot to production 
systems.

Thanks for your input,

Christian

> Kind regards,
> 
> Jeroen van Meeuwen
-------------- 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/a128c982/attachment.sig>