[Kolab-devel] how to deal with kdepimlibs patches

[Christian Mollekopf]

On Friday 08 June 2012 08.42:59 Allen Winter wrote:
> 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.

Of course I will continue to do that, don't worry =)
But since master is frozen for the time being, and we have the general problem 
of having to wait for the next kde release if we heavily rely on kdepimlibs 
libraries, I thought I'd ask for an opinion.

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/a54cd231/attachment.sig>