[Kde-pim] Re: kdepimlibs and kdateedit

David Jarvie djarvie at kde.org
Tue Nov 30 10:52:35 CET 2010

On Tue, November 30, 2010 9:31 am, 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.
>> 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.
> 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
> released.

There is some existing API which is omitted from the proposed new code,
which would require rework in KAlarm unless it's reinstated. I feel that
it is really too late for this type of adjustment, immediately before a
release - KAlarm may not be the only application which will be adversely

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

I think this is a case for sticking to the normal rules. There is no real
necessity to make these changes before the release - it's primarily a
tidying up exercise, not a vital new piece of functionality. The code
should still work if it is committed after 4.6, at which point it should
have had time for proper review.

David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm

More information about the release-team mailing list