The case for a kdelibs 4.8

[Aaron J. Seigo]

On Thursday, September 29, 2011 14:01:50 Kevin Kofler wrote:
> 1. This puts kdelibs 4 into maintenance mode even before KDE Frameworks 5 is
> anywhere near a release, let alone versions of the workspace and
> applications actually using it. As a result, we will fail to deliver new
> features to our end users for months if not years. 

we will deliver no new features in kdelibs, yes. but certainly we will be 
shipping new features in applications (including the workspaces) using those 
libraries. so our users will indeed be getting new features and we will indeed 
be improving the software our users get.

bug fixes and performance improvements also continue, and those are things 
that our users really do care about as well. features are valuable, but they 
aren't the only thing of value. as 4.7 is still being actively maintained, 
even kdelibs is very much still being improved from a user's POV.

> And no, kdelibs features
> do not only target developers: Some application or workspace features
> require kdelibs changes, or in some cases, even consist of kdelibs changes
> only, e.g. my Plasma PackageKit integration work is entirely in kdelibs
> (libplasma).

many application and workspace features do not require changes in kdelibs. 
though, as you note, some do. there are already many improvements in 
libplasma2 that the workspaces will only get to take advantage of when 
frameworks is released. in the meantime, we're still rolling out new features 
and even whole new shells (the Contour work and plasma-device shell, for 
instance) using the 4.7.x platform libraries.

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

> 2. It will be confusing to our users, and even to some packagers, to have a
> KDE SC 4.8 on kdelibs 4.7. The rule so far has always been that the kdelibs
> version must be the same as the KDE SC version. 

that's not a rule anymore, and hasn't been for a while now.

other than the packaging specfile changes that seem to be required in the 
Fedora packages, i'm not sure what the real world confusion would be. when we 
release apps and workspace 4.8, we'll also do a platform 4.7.x release. the 
release communication will not say "SC 4.8" it will say "Platform 4.7, Plasma 
Workspaces 4.8 and application updates" (or something along those lines). that 
was not just a marketing ploy, but an attempt to align our public 
communication with the realities that already existed in KDE development.

> backported to the compatibility libraries as well. For example, when we
> switched our default spell checker in Fedora from aspell to hunspell in
> Fedora 9 (i.e. 4.0 era), I had to add support for hunspell to kdelibs3, or
> our users would have had to install 2 spell checkers to use KDE apps! (Even
> several apps in the default KDE installation hadn't been ported to kdelibs4
> yet in Fedora 9.) That change never got upstreamed because kdelibs3 is no
> longer maintained, yet it would have been useful to many distributions.

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.

> 4. The core developers, for whose convenience this change was made, are not
> the only ones working or willing to work on kdelibs. 

it wasn't convenience, which sort of makes it sound like we weren't trying 
hard enough ;), but necessity. the necessity is driven by resource constraints 
and the need for changes in kdelibs that require changes to the ABI (and which 
will happen anyways with Qt5)

> The main reason that
> was given for dropping kdelibs 4.8 is that this means one less branch to
> worry about for the people working on kdelibs, but the people who'd work on
> 4.8 and 5.0 are NOT the same people!

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 understand that the developers who
> are pushing forward towards the new "frameworks" are not interested in 4.8,

but we're very interested in kdelibs. that's the important thing.

> but you should understand that many other KDE contributors are not
> interested at all in 5.0 at this time. 

understandable. these developers are probably more interested in one of two 
things:

* applications, and want to rely on new library features in making these 
applications

* the instant gratification of "i want this feature now", which trumps 
thinking about the long term needs of kdelibs

neither of those things is "wrong". they also aren't in kdelibs best 
interests. as such, they should be reevaluated since what is in kdelibs best 
interests are in the best interests of that which builds on them.

> I, for one, will start caring about
> 5.0 the day some application (be it a Plasma workspace or a regular
> application) using it will enter Rawhide (Fedora's trunk), and I guess
> other distro folks are feeling the same. 

some people need to care about 5.0 otherwise it never happens. those who don't 
care until it is out (and that's valid, of course) will need to focus on the 
4.7 branch of kdelibs until then.

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

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

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

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

having read and (at least tried my best to :) understand your concerns, i 
don't believe any of the supporting points you raised are of the sort that 
leads to the conclusion that we should re-open 4.x kdelibs for feature 
development.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110930/799bed50/attachment.sig>