[Kolab-devel] how to deal with kdepimlibs patches

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-06-08 19:00, Christian Mollekopf wrote:
> On Friday 08 June 2012 13.10:46 Jeroen van Meeuwen wrote:
>> Normally, a ticket is created upstream for inclusion of a fix or
>> enhancement.
>>
>
> 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)?

It doesn't really matter whether such ticket is in Bugzilla or in 
Review Board, really, though admittedly mixing things up this would 
create two TODO lists for upstream developers - and thus possibly some 
confusion on what's what (versions, milestones, urgency, severity, 
etc.).

That said, Bugzilla is obviously not for code review ;-)

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

It's one thing that deserves work, I agree.

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

Well, we have to remember the target reference platform for Kolab 3.0 
is Enterprise Linux 6. It's quite the conundrum, I know.

As such, we cannot simply depend on the latest (un)stable KDE (PIM) 
libraries. Obviously, the development work MUST happen on KDE's master 
branches, but given the nature of EL6 (and other stable platforms as 
well!), we have to consider we may need to apply development work (the 
enhancements and fixes needed for Kolab 3.x) to some or the other stable 
release of our KDE dependencies.

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