[Kde-pim] Releasing KHolidays as a Framework

[Volker Krause]

On Tuesday 01 September 2015 19:56:54 John Layt wrote:
> On 1 September 2015 at 09:24, Volker Krause <vkrause at kde.org> wrote:
> > Yes, please! Help with porting the calendaring side away from
> > kdelibs4support is desperately needed.
> 
> Working on kcalcore at the moment, kholidays was a break from that
> when the going got tough :-) Most of the stuff I've ported has been
> fairly straightforward and will be easily automated (details on the
> Frameworks porting wiki), the tricky part is figuring out the
> VTIMEZONE support when it has transition rules included rather than a
> tz name. Support for it is a way off in Qt, so I need to figure out a
> hack in the interim (*). Of course, even once done that branch
> probably can't be merged until all the other PIM libraries and apps
> have KDateTime removed too. I guess I'll need to do a branch on every
> repo just for that? Keeping everything in sync will be a nightmare...

Thanks John, that's great news!

Just an idea: While the clean and minimally disruptive porting approach would 
indeed be branches, I think considering the special KDateTime case we could 
probably also live with temporary breakage. E.g. kcalcore is ported and we 
have clear and reasonably complete instructions on how to port its users, we 
could merge that at an agreed point in time and then for a few days all 
together focus on KDateTime porting. Certainly a lot more disruptive and 
risky, but then we would be done with this once and for all. IOW, quick and 
painful for everyone vs. long and painful for John. 

Anything in between those two extremes is of course also possible, like 
porting some of the particularly challenging KDateTime users in a branch, and 
do the rest together in master.

regards,
Volker

> (*) Current evil plan: seeing as the QDateTime instances returned
> represent the occurrence moment-in-time and are unlikely to ever be
> used as the seed to calculate other dates (big assumption!), then they
> can use a simple offset from UTC QTimeZone internally, with the actual
> offset calculated in the occurrence calculator from an internal copy
> of the VTIMEZONE. Well, that's what I'll be trying this week anyway...
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20150902/7bbea954/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/