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
signature.asc
Description: This is a digitally signed message part.
