Re: how to deal with kdepimlibs patches

On Friday 08 June 2012 7:10:46 AM Jeroen van Meeuwen (Kolab Systems) 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".
> 
> > 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).
> 

How about posting the patches to reviewboard.kde.org?
Then we (kdepim folks) can review them and provide feedback too.




-- 
Allen Winter | [email protected] | Software Engineer
KDAB (USA), LLC, a KDAB Group company
Tel. USA +1-866-777-KDAB(5322), Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions