[Kde-pim] Re: kdepimlibs and kdateedit
ervin at kde.org
Tue Nov 30 11:18:39 CET 2010
On Tuesday 30 November 2010 10:31:45 Tom Albers wrote:
> ----- Original Message -----
> > Well, having this duplicated code everywhere for even more months
> > (look at
> > lxr.kde.org to see what I mean) is enough to make me want this bugger
> > ASAP.
> It's not months, in a month or so trunk is open again.
Well, my point was that to effectively start removing the duplicated code will
require KDateEdit to be in a released kdelibs (as most of the duplicates are
in PIM and Extragear which depends only on released kdelibs). So removing the
duplicated code of all the apps involved will only start *after* 4.7 release
if KDateEdit is not part of 4.6.
> > Agreed, unfortunate timing, but I had to make sure I could recollect
> > from the
> > different forks (and I probably missed some).
> So, you are suggesting introducing a new class to kdelibs after beta 1 has
> been released which will immediately be used by half a dozen applications
> within KDE SC and Extragear. Introducing an important new class and only
> letting it get half the testing it should have sounds bad to me.
It's actually tested for the most part as for the core features it's the exact
same code than what's present in most of the current forked versions.
> That also increases the chance of being stuck with an API which is not
> optimal for all the apps and which we can not change because it is already
Yep, hence why I tried to keep it minimal.
> > My concern is that if we give it six more months we'll be at the same
> > point
> > for 4.7 (since PIM and Extragear tend to use only released kdelibs).
> In a month trunk is open and you can fix them all, no six months there.
> Only some ifdefs for extragear apps probably, but you would need those now
> as well probably, right?
Well not, right now they depend on their own copy of KPIM::KDateEdit and they
could switch to the shared KDateEdit once it's in a release kdelibs.
> > I'm
> > definitely not interested in doing this work again, it's already been
> > painful
> > enough
> If you are going to blackmail me with 'now or never', by all means commit.
> I've no intention in upsetting you or destroying this valueable work. I
> only want optimal KDE releases.
Sorry if the wording turned out unfortunate it wasn't my intent there. It was
more about a reality check:
a) I can't devote much time to it on a regular basis (it's rather low on my
priority list), and I think I'm not the only one with that problem since I
hear this "let's move KDateEdit to kdelibs since *at least* 4.3";
b) Until it's in kdelibs people will keep doing stuff in their own corner, so
the work I did so far will need to be done again for missing features and so
on, David's mail actually illustrate that well... The feature he refers to
wasn't there when I started. :-/
But OK, looks like I missed the window by a couple of weeks, so let's make it
for a "later release".
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20101130/2e5859d8/attachment.sig
More information about the release-team