The case for a kdelibs 4.8

[Kevin Kofler]

Aaron J. Seigo wrote:
> so some features will indeed have to wait .. and that's not a horrible
> thing because it means that frameworks will get more developer attention
> and the attention it is getting already will not be slowed even further by
> having to deal with bringing over features from 4.7.x into the re-arranged
> libraries in frameworks.

So you're arguing that by doing this, you FORCE developers to work on 5.0? 
Well, I'm sorry, but you cannot really force volunteer developers to do 
anything. I don't believe that actively preventing us from working on the 
branch we want to work on is going to solve any problem.

> the result will be that the time between now and 5.0 libs being available
> will be shortened, which is exactly what we, as application developers,
> need.

I also strongly doubt that yet another binary-incompatible break is what 
application developers really want or need. Some applications are still not 
ported to the KDE Platform 4.

(And I know that Qt is also breaking the ABI. That's something I also can't 
agree with, especially considering that Qt 4 was advertised as "the big ABI 
break which will make new ABI breaks unnecessary for a very long time" and 
we've been continuously told that "there are no plans whatsoever for a Qt 5 
any time soon", almost up to the day before the Qt 5 announcement. But I 
realize that this is out of KDE's control.)

> there is apparently a fundamental misunderstanding here: KDE Platform 4.7
> is being maintained. but "only" maintained. if such a spell checker thing
> happened right now, we could enable that in the 4.7 branch. many of us are
> still committing bug fixes and other improvements to that branch, which
> are then merged regularly into the frameworks branch.
> 
> what we aren't doing it focussing new feature development efforts in the
> 4.7 branch. that is happening in frameworks instead, but 4.7 is still very
> much maintained. as such, there should be zero reason for downstream
> packaging efforts to require patching bugfixes into their builds
> themselves.

Back when the Hunspell patches for kdelibs 3.5 and for the K3Spell 
compatibility API were discussed, the Sonnet maintainer argued that adding 
support for a new spell checker is a feature, not a bugfix, and to be 
honest, I think he's right.

> which begs the very good question: why aren't they? they should be the
> same people. we need the 5.0 release, and that will happen faster if we
> don't split our resources. remember how long the 4.0 development took, in
> part because we kept equivocating between more 3.x releases and getting on
> with 4.0?

I really don't buy that doing 3.x releases is what made 4.0 take so long. I 
think 4.0 took so long because 4.0 was just a gigantic change.

Having 3.5 made the long wait for 4.x bearable, and I think we should have 
done at least a 3.6 (of the whole SC), too (before 4.0). And probably a 
kdelibs 3.7 (after 4.0, maybe even after 4.1 or 4.2, those releases aren't 
needed every 6 months) for all those applications not ported yet at that 
time, to improve integration into KDE Platform 4 (e.g. a style which looks 
as much like Oxygen as technically possible would have been helpful, or a 
backport of the Oxygen icon theme to the old icon names) and backport 
features where possible without breaking compatibility.

>> OTOH, I'm very much interested in
>> working on 4.8, and in fact I already did (see my Plasma PackageKit GSoC
>> work), but my patches are now stuck in reviewboard and cannot be
>> committed due to the deep freeze.
> 
> they can be committed to the frameworks branch. in my eyes, those patches
> are not 4.x efforts at all, but things that belong in frameworks.

I have to strongly disagree with that. I developed those for 4.x and 4.x 
only. Of course I don't want that feature to get lost with the move to 5.x, 
so I will forward-port it, but I don't see why this should not be available 
in 4.x, just because it was developed a couple months after your arbitrary 
cutoff date (the 4.7 feature freeze) which was not announced (as the final 
cutoff for kdelibs 4.x, as opposed to just 4.7, features) in advance.

Refusing the change in 4.x is also going to make me LESS motivated to do the 
forward-port for frameworks.

>> Do you really want to encourage wild patching by
>> distributions, adding or backporting a patchwork (pun intended) of
>> features?
> 
> of course not. and imho collaborative packaging efforts would mean not
> threatening upstream development in this way.

We aren't threatening anybody by offering features to our users.

>> I remember Aaron Seigo complaining on his blog about the feature
>> backports done by distributions in 4.0, 4.1 and 4.2 era, but if you
>> aren't going to allow any new features upstream, you will be leaving us
>> no choice.
> 
> the choice that packagers have is to actually work with us instead of
> against us. the idea that "it sucked when we did it before, and now we're
> going to do it again!" is a little twisted. :)
> 
> the features you offered as needing to be in kdelibs are not so critical
> or fundamental that Bad Things will hapen if they aren't available right
> away. if we are more conservative about the value assessments we make on
> these features, it becomes apparent that those features can indeed wait,
> just as they already have for some 3 years now.

Those features are already in Rawhide for Fedora 17 and there's no way I 
will drop them from there. I'm more likely to also backport them to Fedora 
16 (coming soon) and maybe even 15 (the current stable release).

>> 5. We have a master branch which is unused.
> 
> this isn't a reason for or orgainst a 4.8 release, and there is good
> development reasons for that decision. yes, it has been a source of
> confusion for those who build from git sources who didn't follow the
> frameworks decision and so got caught out by not changing their kdelibs
> repo to the 4.7 branch. that seems to be fixing itself and people learn
> about these changes.

But why should people HAVE to learn that? What kdelibs is doing is different 
from what 99% of the projects using git are doing.

        Kevin Kofler