----- 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. > 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. Best, -- Tom Albers _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
