subject:"Re\: The case for a kdelibs 4.8"

Aaron J. Seigo wrote:
 the features that got into the 4.7 branch to date have been things that
 were already worked on before the Frameworks decision was made. it's was
 an odd cas were features had been worked on while 4.7 was frozen with the
 expectation of a 4.8 ... and that left us with the choice of having a 4.8
 release which we didn't want for those few features, leaving those
 features out and screwing up the planning of the applications depending on
 those changes or fudging a little bit.

Not all those features are merged in yet, see e.g. my Plasma PackageKit GSoC 
work.

 note that some of the more actively changing and developed code in kdelibs
 have moved to separate git repositories already to make this issue moot
 for them (kactivities, nepomuk)

That is also a nightmare to packagers. Especially kactivities is a big 
problem because kde-workspace 4.7 (not 4.8!) is now reported to rely on a 
new kactivities which is not in kdelibs 4.7. That makes no sense whatsoever.

Kevin Kofler

Re: Re: The case for a kdelibs 4.8

Martin Gräßlin wrote:
 One of the main reasons for the rebranding was to realize that KDE is
 not one product, but a community that produces multiple products among
 them a desktop environment (Plasma). What you just try to tell us is that
 the complete rebranding is nonsense and we should go back to talking just
 about KDE for everything bringing the users back to assuming they need
 Plasma in order to use KMail.

That's what some of us have been trying to tell you for months…

Kevin Kofler

Re: The case for a kdelibs 4.8

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

Re: The case for a kdelibs 4.8

PS:

Aaron J. Seigo wrote:
 the choice that packagers have is to actually work with us instead of
 against us.

We would very much love to work with you. In fact, this is why I submitted 
my patches to KDE ReviewBoard before even getting them into Rawhide. I 
really WANT these to be upstream. Fedora doesn't like carrying downstream 
patches as a general principle.

However, working with you is only possible if you are also interested in 
working with us, which implies listening to our needs, concerns and wishes. 
By closing down the branch where our current development is necessarily 
focused on since that's what we will be shipping in the near future, you're 
already starting down the wrong road.

For those Plasma PackageKit features, sure, they're not strictly required, 
which is why we got away without them until now. But to our users, they mean 
that installing a widget through download new widgets… will actually 
install the required dependencies, so the widget they downloaded will 
actually WORK. What, to us developers, is a feature, actually fixes a bug 
from a user's perspective. We, the distributions, interact directly with 
users, and so are receptive to their needs, concerns and wishes, and tend to 
base ours on them.

And finally, I strongly doubt that my features are the only post-4.7 kdelibs 
features running into the freeze. (In fact, what's now going on with 
kactivities and nepomuk proves quite the opposite.)

Kevin Kofler

Re: The case for a kdelibs 4.8

PPS:

I wrote:
 However, working with you is only possible if you are also interested in
 working with us, which implies listening to our needs, concerns and
 wishes. By closing down the branch where our current development is
 necessarily focused on since that's what we will be shipping in the near
 future, you're already starting down the wrong road.

For a prime example of what happens if you close down the version 
distributions are actually shipping in favor of long-term development, just 
look at GRUB 1. Fedora's GRUB 0.97 package is now at patch level 75! And it 
has its own git repository, i.e. essentially a fork (grub-fedora on 
git.kernel.org, it's now down because all of git.kernel.org is currently 
down).

GRUB 2 is now finally becoming production-ready, and Fedora will be 
switching to it in Fedora 16, but it was nowhere near that state when 
upstream discontinued GRUB 1. GRUB 0.97 was released on May 8, 2005 (and 
IIRC that was only a bugfix release and they stopped accepting new features 
even earlier). Distributions have been forced to ship patched versions for 
over 6 years. (GRUB 0.97 as released doesn't support many needed features, 
e.g. ext4.) As a result, it has become a morass of all-different forked 
versions. You can't tell a priori what any given GRUB 0.97 package 
actually supports.

Sure, focusing on the long term to some extent is needed, but we 
distributors need something we can ship NOW, not months or years from now.

Kevin Kofler

Re: The case for a kdelibs 4.8

2011-10-01 Thread Thiago Macieira

On Saturday, 1 de October de 2011 12:58:01 Kevin Kofler wrote:
 (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.)

Between the 4.0 and 5.0 release, it will have been 7 years. I think it's long 
enough.

KDE could take Qt 4.8, fork it and continue developing it. Any show of hands?

As for the announcing of the plans, there were no plans to do Qt 5 until there 
were plans. Once there were plans, they were announced.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.

Re: The case for a kdelibs 4.8

2011-10-01 Thread Scott Kitterman

On Saturday, October 01, 2011 08:27:02 AM Martin Gräßlin wrote:
 On Saturday 01 October 2011 00:12:05 Arne Babenhauserheide wrote:
  Am Freitag, 30. September 2011, 10:07:27 schrieb Aaron J. Seigo:
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. 
  I hope I am not the first to note that this sounds really horrible.
  
  Take this message:
  KDE releases 4.8: Platform and Workspaces got some spectacular
  changes,
  
  while applications received much polish.
  
  In a blog, this becomes
  
  YAY! KDE releases 4.8!
  
  Take your example. It becomes:
  Plasma 4.8 released!
  
  Well, where is KDE in that? Suddenly the community it is all about
  becomes a sidenote.
  And a newspaper will likely only see “hm, some stuff our readers won’t
  understand” instead of “new version of the tools from KDE!”
  
  There is a reason why Apple releases MacOSX 10.8 and not “Xcode 4.1,
  Apple Mach 1.3, Quartz 4.7, …”
 
 One of the main reasons for the rebranding was to realize that KDE is not
 one product, but a community that produces multiple products among them a
 desktop environment (Plasma). What you just try to tell us is that the
 complete rebranding is nonsense and we should go back to talking just about
 KDE for everything bringing the users back to assuming they need Plasma in
 order to use KMail.
 
 I really like the fact that finally we have a release where it will be clear
 that KDE is the community and not one large product. All those who did not
 get it yet, might finally understand it if we write a really good release
 announcement.

I understand it and I think it's great.  At the same time, I think this idea 
that from a development perspective it's OK to mix and match and release any 
piece of the SC at any given time is technical nonsense.  As long as we leave 
the marketing to the marketeers and the developers don't get distracted by it, 
then I think it's fine.

I think users ought to be able to run KMail (to pick your example) on any 
desktop environment and have it work well.  I completely agree with this idea, 
but I don't agree with the idea to throw away the coordinated development 
schedule and release process.

Scott K

Re: The case for a kdelibs 4.8

On Thursday, September 29, 2011 18:11:12 Kevin Kofler wrote:
 Wait and see the chaos that will come up when users open their Help/About in
 Konqueror and it tells them that they're using Konqueror 4.8.0 under KDE
 4.7.6. (And yes, it still says only KDE in 4.6.5, I haven't checked 4.7
 or 4.8 for whether that's fixed there.)

it says KDE Development Platform x.y.z.

  The rule so far has always been that the kdelibs
  version must be the same as the KDE SC version.
 
  There is no rule – at most a common practise

 A common practice which had been enforced by minimum required kdelibs
 versions in CMakeLists.txt.

for, e.g. kde-workspace, that minimum version for kdelibs is 4.7. it may be
even lower for other modules (many apps probably compile with rather older
kdelibs than that). this really isn't an argument for or against a 4.8 ..

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

Re: The case for a kdelibs 4.8

On Thursday, September 29, 2011 23:57:53 Scott Kitterman wrote:
 I don't like the fact that KDE developers decided to ignore their own policy
 on maintenance updates.  I think it breaks your contract with your
 downstreams.  In the case of what's been done so far, it doesn't have an
 impact on us.  The changes were in before our release and are technically

the features that got into the 4.7 branch to date have been things that were 
already worked on before the Frameworks decision was made. it's was an odd cas 
were features had been worked on while 4.7 was frozen with the expectation of 
a 4.8 ... and that left us with the choice of having a 4.8 release which we 
didn't want for those few features, leaving those features out and screwing up 
the planning of the applications depending on those changes or fudging a 
little bit.

it was a compromise choice made to mimize downside. as with all such 
compromises, it isn't perfect (ergo the label of 'compromise'), but after 
looking at the issues and looking at different scenarios we decided this was 
the best option available to us compared to the others.

note that some of the more actively changing and developed code in kdelibs 
have moved to separate git repositories already to make this issue moot for 
them (kactivities, nepomuk)

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

Re: The case for a kdelibs 4.8

On Thursday, September 29, 2011 23:57:56 Kevin Kofler wrote:
 https://git.reviewboard.kde.org/r/102175/
 https://git.reviewboard.kde.org/r/102291/
 https://git.reviewboard.kde.org/r/102350/

none of these are critical feature additions. they elevate the usability of 
libplasma and are valuable, but we've lived just fine without these features 
to date.

if we were working on and releasing a 4.8 version of kdelibs, our users would 
have to wait for these features until 4.8 was released (e.g. in january) and 
distributions made packages available to their users (often much later than 
that). 

instead, they'll have to wait until frameworks is ready. and this code can, 
and should, go into libplasma in the frameworks branch today.

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

Re: The case for a kdelibs 4.8

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

Re: The case for a kdelibs 4.8

2011-09-30 Thread Heinz Wiesinger

On Thursday 29 September 2011 14:01:50 Kevin Kofler wrote:
 Hi,
 
 as you probably already know, a decision was recently made that kdelibs 4.7
 would be the last 4.x release series of kdelibs, and work would be ongoing
 in the 5.0 (frameworks) and 4.7 (KDE/4.7) branches only. I think this is a
 huge mistake, for several reasons (the TL/DR crowd can stop right here,
 but if you want to know why, please read on!)
 [..]

From what I remember from the desktop summit the picture you draw here is 
quite an exaggeration of what is actually happening.

kdelibs 4.7 is meant to be frozen for new features, but not for bugfixes. 
Bugfix releases of kdelibs-4.7 happenend and I'm sure will continue on 
happening. As for the versioning I don't see why one of those bugfix releases 
couldn't be rebranded as 4.8.0 if that makes things easier (that was even 
briefly mentioned at the release team BoF). It does not solve feature 
backports of course.

The KDE Frameworks 5.0 development is not meant to take forever. In fact I 
think it's meant to be finished around early 2012, which would leave us with a 
frozen kdelibs for one KDE SC release, maximum two. It's also not a huge *we 
will break everything! Kittens will die!* release, but basically just a 
restructuration of the code, with little to no adjustments necessary for 
applications. (that was how it was marketed, anyway).
The way I understood it was that there could very well be a KDE SC 4.9 release 
shipping a 4.9 workspace on top of 5.0 frameworks.

As for the version numbers, I don't really see the problem. As long as the 
integrity of the KDE SC releases remains, different version numbers in its 
components are not really /that/ important. I do see how it could help though.

Grs,
Heinz


signature.asc
Description: This is a digitally signed message part.

Re: The case for a kdelibs 4.8 (fwd)

2011-09-30 Thread Eric Hameleers

Forwarding my answer to kde-core-devel in order to give us packagers 
a voice outside our own closed mailing list.


Cheers, Eric

--
Eric Hameleers al...@slackware.com
Jabber: al...@jabber.xs4all.nl

-- Forwarded message --
Date: Thu, 29 Sep 2011 10:37:20 -0700 (PDT)
From: Eric Hameleers al...@slackware.com
To: Wulf C. Krueger philant...@exherbo.org
Cc: kde-packa...@kde.org
Subject: Re: The case for a kdelibs 4.8

On Thu, 29 Sep 2011, Wulf C. Krueger wrote:


On 29.09.2011 14:01, Kevin Kofler wrote:
[Lots of excellent explanations deleted]

So I am urging you to reconsider your decision and reopen master for those
people willing to work on 4.8. It's not too late yet, there's a month left
until the soft feature freeze for KDE SC 4.8.


I totally agree with Kevin. This would lead to another packaging
nightmare and would be confusing to users as well.


Kevin's plea has my fullest and strongest support.

Cheers, Eric

--
Eric Hameleers al...@slackware.com
Jabber: al...@jabber.xs4all.nl
___
Kde-packager mailing list
kde-packa...@kde.org
https://mail.kde.org/mailman/listinfo/kde-packager

Re: The case for a kdelibs 4.8

2011-09-30 Thread Kevin Krammer

On Thursday, 2011-09-29, Rolf Eike Beer wrote:

 The reason to stop master was (as far as I understand) to make the
 frameworks branch easily to maintain. If someone is working on 4.8
 (bugfixing, features) all this has to be ported to frameworks, too. So you
 develop a moving target on a moving target.

What about a more stricter than usual policy for additions to 4.8?
Like every new feature wanted in 4.8 has to go through reviewboard for 4.8 and 
frameworks 5.

That way the developer doing the feature work for 4.8 will also take care of 
the forward porting task.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.

Re: The case for a kdelibs 4.8

2011-09-30 Thread todd rme

On Fri, Sep 30, 2011 at 10:07 AM, Aaron J. Seigo ase...@kde.org wrote:
 On Thursday, September 29, 2011 14:01:50 Kevin Kofler wrote:
 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.

I am not saying this is the best solution, I am just putting out as a
possible compromise.  Would it be possible to just call kdelibs 4.7.8
or whatever it ends up being kdelibs 4.8, without adding any
significant new features?  I know you can, by KDE policy, add new
features at a x.x release, but is there any requirement that you have
to?  I know there are numerous other issues involved so this may be a
terrible idea.

-Todd

Re: The case for a kdelibs 4.8

2011-09-30 Thread David Faure

On Thursday 29 September 2011 20:01:00 Kevin Kofler wrote:
 But one of my points is that we need features too, not just bugfixes.
 Continuing 4.7.x releases solves the problem of bugfixes just fine, but
 entirely fails to address the issue of features.

But who is (or would be) working on features in kdecore | kdeui | kio | kfile?

Feel free to prove me wrong, but with most kdelibs developers working on 
either bugfixing or frameworks, I don't see who's left to work on features in 
kdelibs.

I agree that e.g. plasma and nepomuk might be in a different situation though.

Maybe with a proper git merge support for kdelibs master we could re-evaluate 
the decision to freeze it, it's less work than having to cherry-pick every fix 
into 3 branches.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

Re: The case for a kdelibs 4.8

2011-09-30 Thread Markus Slopianka

On Donnerstag 29 September 2011 18:11:12 Kevin Kofler wrote:

 Wait and see the chaos that will come up when users open their Help/About
 in Konqueror and it tells them that they're using Konqueror 4.8.0 under
 KDE 4.7.6. (And yes, it still says only KDE in 4.6.5, I haven't checked
 4.7 or 4.8 for whether that's fixed there.)

True but only in one line ans the explanation that the Dev Platform is meant, 
is written 
in About KDE.
That said, I'm toying with ideas about a complete redesign of the About window 
for KF5. 
When/If I come up with a somewhat presentable mock-up, I'll post it and 
hopefully a 
programmer implements something based on that.
A completely new About window will also fix legacy issues like that string.


  and strangely shipping Kontact 4.4.11 with SC 4.5+ was also not confusing
  to most users.
 
 Actually, that was (and still is) quite confusing to many users. Look at
 the mailing lists and forums.

I really don't think it was the majority and the Kontact case is user-visible 
software 
unlike Frameworks/Platform which normal users usually do not care about.
MS Office 2003 also ran on Windows 2000 and the majority of users had no 
problems 
understanding that. ;-)

And we better continue to educate our users that Platform version and Workspace 
version 
does not need to match.
I have yet to see any ideas for KDE Plasma Desktop 5.0 which means that maybe
KPD 4.9 in summer 2012 will require KF 5.0. So unless someone completely 
rewrites KPD for 
the summer release (maybe basing it on Plasma Active) and therefore justifying 
a major 
version jump to 5.0, as a promo person I'd rather educate our users now before 
we see 
people (at worst: reviewers) complaining that KDE 5 looks just like KDE 4.8.

(As a side note I also think that KDE Applications should completely lose their 
version 
number and get date-based versioning because any application can get major new 
features at 
any time – see Dolphin 2.0 in SC 4.8.)


 Fedora 15 actually has KDE SC 4.6.x, not 4.7.

Just a few days ago someone on your mailing list claimed otherwise but 
whatever... that's 
not the main topic here.

Re: The case for a kdelibs 4.8

2011-09-30 Thread Scott Kitterman

On Friday, September 30, 2011 04:15:51 PM Markus Slopianka wrote:
 (As a side note I also think that KDE Applications should completely lose
 their version  number and get date-based versioning because any application
 can get major new features at any time – see Dolphin 2.0 in SC 4.8.)

Today, for Kubuntu, we work very hard to package all of the KDE SC because we 
think it's an important value to deliver this upstream set of packages as a 
complete set to our users (IIRC, except for bindings we accomplished that for 
4.7 even with all the package splits).

If there is no more integrated release of a KDE SC, then we really don't need 
to worry about that and so we'll probably focus more just on stuff we use (I 
know the Debian KDE packagers are already planning this due to all the package 
splits).

So I expect that one side effect of doing away with the traditional KDE release 
process will be less KDE software packaged in distributions.

Scott K

Re: The case for a kdelibs 4.8

2011-09-30 Thread Alexander Neundorf

On Thursday 29 September 2011, Andras Mantia wrote:
 On Thursday, September 29, 2011 21:43:34 Stefan Majewsky wrote:
  Without judging on the other arguments which look very reasonable to
  me...
  On Thu, Sep 29, 2011 at 2:01 PM, Kevin Kofler kevin.kof...@chello.at
 
 wrote:
   2. It will be confusing to our users, and even to some packagers, to
   have a KDE SC 4.8 on kdelibs 4.7. [...]
  
  ...what exactly stops you from advertising kdelibs 4.7.x as version
  4.8? (And I mean advertise, so only the user-visible parts, not
  version numbers in .so files or whatever.)
 
 Now that would add a lot of confusion.

Can the version number of kdelibs 4.7.x simply be increased to 4.8 when 4.8 is 
branched ?
It would have only bugfixes, but it seems it would make life simpler for some 
people.

Alex

Re: Re: The case for a kdelibs 4.8

2011-09-30 Thread Albert Astals Cid

A Dijous, 29 de setembre de 2011, Scott Kitterman vàreu escriure:
 On Thursday, September 29, 2011 11:47:22 PM Albert Astals Cid wrote:
  A Dijous, 29 de setembre de 2011, Scott Kitterman vàreu escriure:
   On Thursday, September 29, 2011 08:01:00 PM Kevin Kofler wrote:
On Thursday 29 September 2011, Heinz Wiesinger wrote:
 From what I remember from the desktop summit the picture you
 draw
 here
 is
 quite an exaggeration of what is actually happening.
 
 kdelibs 4.7 is meant to be frozen for new features, but not
 for
 bugfixes.
 Bugfix releases of kdelibs-4.7 happenend and I'm sure will
 continue
 on
 happening. As for the versioning I don't see why one of
 those
 bugfix
 releases couldn't be rebranded as 4.8.0 if that makes things
 easier
 (that
 was even briefly mentioned at the release team BoF). It does
 not
 solve
 feature backports of course.

But one of my points is that we need features too, not just
bugfixes.
Continuing 4.7.x releases solves the problem of bugfixes just
fine,
but
entirely fails to address the issue of features.
   
   Even worse, features have already creeped into the 4.7 branch
   because
   they are needed and there's no 4.8 branch, so this isn't a
   theorectical
   point.
  
  Why is that bad, that is what was agreed when the freeze took place.
 
 Agreed on by who?

Read this list Plan to transition to KDE Frameworks.

Albert

Re: Re: The case for a kdelibs 4.8

2011-09-30 Thread Albert Astals Cid

A Divendres, 30 de setembre de 2011, Aaron J. Seigo vàreu escriure:
 On Thursday, September 29, 2011 23:57:56 Kevin Kofler wrote:
  https://git.reviewboard.kde.org/r/102175/
  https://git.reviewboard.kde.org/r/102291/
  https://git.reviewboard.kde.org/r/102350/
 
 none of these are critical feature additions. they elevate the usability of
 libplasma and are valuable, but we've lived just fine without these features
 to date.
 
 if we were working on and releasing a 4.8 version of kdelibs, our users
 would have to wait for these features until 4.8 was released (e.g. in
 january) and distributions made packages available to their users (often
 much later than that).
 
 instead, they'll have to wait until frameworks is ready. and this code can,
 and should, go into libplasma in the frameworks branch today.

I sincerely think you are being unfair here. The stuff you needed was merged 
in, and probably was more invasive than those features. You justify yourself 
in that it was developed before we knew 4.8 was not going to be there. I'd 
say that can easily qualify for Kevin too.

Albert

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

Re: Re: The case for a kdelibs 4.8

2011-09-30 Thread Albert Astals Cid

A Divendres, 30 de setembre de 2011, Alexander Neundorf vàreu escriure:
 On Thursday 29 September 2011, Andras Mantia wrote:
  On Thursday, September 29, 2011 21:43:34 Stefan Majewsky wrote:
   Without judging on the other arguments which look very reasonable to
   me...
   On Thu, Sep 29, 2011 at 2:01 PM, Kevin Kofler
   kevin.kof...@chello.at
  
  wrote:
2. It will be confusing to our users, and even to some
packagers, to
have a KDE SC 4.8 on kdelibs 4.7. [...]
   
   ...what exactly stops you from advertising kdelibs 4.7.x as version
   4.8? (And I mean advertise, so only the user-visible parts, not
   version numbers in .so files or whatever.)
  
  Now that would add a lot of confusion.
 
 Can the version number of kdelibs 4.7.x simply be increased to 4.8 when 4.8
 is branched ?
 It would have only bugfixes, but it seems it would make life simpler for
 some people.

As I already said in this thread, that is Dirk's plan as he stated in the 
Release Team BoF in Berlin.

Albert

 
 Alex

Re: The case for a kdelibs 4.8

2011-09-30 Thread Arne Babenhauserheide

Am Freitag, 30. September 2011, 10:07:27 schrieb Aaron J. Seigo:
  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.

I hope I am not the first to note that this sounds really horrible.

Take this message:

KDE releases 4.8: Platform and Workspaces got some spectacular changes,
while applications received much polish.

In a blog, this becomes

YAY! KDE releases 4.8!

Take your example. It becomes:

Plasma 4.8 released!

Well, where is KDE in that? Suddenly the community it is all about becomes a
sidenote.
And a newspaper will likely only see “hm, some stuff our readers won’t
understand” instead of “new version of the tools from KDE!”

There is a reason why Apple releases MacOSX 10.8 and not “Xcode 4.1, Apple
Mach 1.3, Quartz 4.7, …”

Technically it is cool to have a kmail 5.8 which depends on frameworks =5.1,
but as a User I am interested in the changes KDE did for 5.8: All the changes,
to Frameworks as well as to the Workspaces and the Applications. If I then
decide to not use the testing frameworks, it makes me happy when an
application only needs an earlier version. But do you actually think that most
people can follow the info-input of having different version numbers in a
release - and really remember the news? Due to 3 hours daily travel time, 40h
work per week and wife and son, I won’t be able to do that in the near future,
so there are likely many more people who can’t.

Best wishes,
Arne
--
singing a part of the history of free software:

- http://infinite-hands.draketo.de



signature.asc
Description: This is a digitally signed message part.

Re: The case for a kdelibs 4.8

2011-09-29 Thread Rolf Eike Beer

 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. Please keep the life cycle of your
 software for distributors and end users in mind when you decide your
 schedules, not just the convenience of a few core developers.

Given that it is now proven and tested code, who stops you committing it
into KDE/3.5 branch?

 4. The core developers, for whose convenience this change was made, are
 not the only ones working or willing to work on kdelibs. 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! I understand that the
 developers who are pushing forward towards the new frameworks are not
 interested in 4.8, but you should understand that many other KDE
 contributors are not interested at all in 5.0 at this time. 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.
 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. Do you really
 want to encourage wild patching by distributions, adding or backporting a
 patchwork (pun intended) of features? 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 reason to stop master was (as far as I understand) to make the
frameworks branch easily to maintain. If someone is working on 4.8
(bugfixing, features) all this has to be ported to frameworks, too. So you
develop a moving target on a moving target.

Not that I do not understand your point (I'm not sure if I have an opinion
on this yet), just to get a common understanding about the reasons.

I would have wished more than once if we could have done a new release on
an older branch, e.g. a KDE 4.6.6 where the KLineEdits in Konqueror would
be fixed. Some sort of long-term branch, or at least one maintenance
release more when the .0 or .1 is out. You only get severe end user
testing on the new major release when the .0 is out, so those who don't
want to break their system will stay on the older branch, which has bugs
long fixed in the new one. Some sort of chicken and egg problem, of
course, but it would be helpful for those people to get an additional
release with bugfixes after the next .0 is out. This could be e.g. in the
middle between .0 and .1 to not have the release workload for 2 releases
at once. And: yes, I know, this is even more work for the release team.
Poor Dirk.

Eike

Re: The case for a kdelibs 4.8

2011-09-29 Thread Markus Slopianka

On Donnerstag 29 September 2011 14:01:50 Kevin Kofler wrote:

2. It will be confusing to our users, and even to some packagers, to have a
KDE SC 4.8 on kdelibs 4.7.

Since almost exactly 2 years we (esp. the promo team) are communicating that
Platform/Frameworks, Applications and Workspaces are three separate products
that just
happen to be shipped on the same date.

One of the reasons why the rebranding still didn't get to everybody is that
some
distributions (mostly Fedora!) still spread the wrong message about some “KDE
4.7” to its
users. (see eg.
https://fedoraproject.org/wiki/SIGs/KDE/KDE47Packaging#KDE_4.7_Packaging )

Users of other distributions do not have such problems and strangely shipping
Kontact 4.4.11 with SC 4.5+ was also not confusing to most users.

The rule so far has always been that the kdelibs
version must be the same as the KDE SC version.

There is no rule – at most a common practise and that was broken as well after
Fedora 15
has packages for SC 4.7 with Kontact 4.4.

Changing this will also break all our Fedora KDE SC specfiles

Then fix your specfiles. AFAIK Fedora is also the last big distribution that
still has
monolithic packages like kdemultimedia, kdenetwork, and so on.
Take the opportunity to fix that as well.

openSUSE doesn't seem to have problems packaging 4.8 already:
https://build.opensuse.org/project/show?project=KDE%3AUnstable%3ASC

And what will kde4-config --kdeversion output? The version of kdelibs?
Of course. What else? Want to see the Plasma version, enter plasma-desktop
--version
If you want the version of Dolphin, enter dolphin --version and so on.

Users are going to be confused: Hey, I installed KDE SC 4.8, why does it
say 4.7?

Then you refer them to Wikipedia which holds that info since quite some time:
https://secure.wikimedia.org/wikipedia/en/wiki/KDE_Software_Compilation_4#KDE_Plasma_Workspaces_and_Applications_4.8

you will break Fedora packages even further.
Then – again – fix Fedora.

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!

Do you hereby declare that Red Hat will provide resources to create KDE
Platform 4.8 and
an cherrypick useful developments from the frameworks branch to Platform 4.8?

Re: The case for a kdelibs 4.8

Rolf Eike Beer wrote:

(re the support for spellchecking with hunspell)
 Given that it is now proven and tested code, who stops you committing it
 into KDE/3.5 branch?

What for? There are no plans to do a 3.5.11 or 3.6.0 release, ever, and the 
one major distribution known to sometimes ship release branch snapshots from 
after the last release of the branch (Debian) just dropped the KDE 3 libs 
from their distribution (a decision I also don't agree with, FWIW, but 
that's off topic here). In addition, that patch is not exactly a bugfix…

The 2 patches against 3.5.10 (one for KSpell and one for KSpell2) can be 
found in Fedora dist-git, and also in KDE Bugzilla. If you think they should 
be in the 3.5 branch, feel free to commit them. But AFAIK, we aren't really 
expected to commit anything to the 3.5 branch anymore, even though AFAIK 
there's no official freeze like the one being enforced on master.

By the way, I also have a patch for K3Spell in the KDE 4 libs. We also ship 
that patch in Fedora. It's basically the same as the KSpell patch for the 
KDE 3 libs, and attached to the same bugs.kde.org report. But I don't know 
whether anything actually still uses K3Spell. (The reason I didn't commit 
that was because the Sonnet maintainer wasn't happy with the idea of adding 
a new feature to that compatibility API, even though it's needed for 
integration. And of course now I couldn't commit it anymore even if I wanted 
because kdelibs master is frozen, which brings us back to the topic…)

 The reason to stop master was (as far as I understand) to make the
 frameworks branch easily to maintain. If someone is working on 4.8
 (bugfixing, features) all this has to be ported to frameworks, too. So you
 develop a moving target on a moving target.

You'd just have to do regular merges from master instead of regular merges 
from KDE/4.7. It wouldn't change much apart from being more consistent with 
common best practices for SCM use.

 I would have wished more than once if we could have done a new release on
 an older branch, e.g. a KDE 4.6.6 where the KLineEdits in Konqueror would
 be fixed. Some sort of long-term branch, or at least one maintenance
 release more when the .0 or .1 is out. You only get severe end user
 testing on the new major release when the .0 is out, so those who don't
 want to break their system will stay on the older branch, which has bugs
 long fixed in the new one. Some sort of chicken and egg problem, of
 course, but it would be helpful for those people to get an additional
 release with bugfixes after the next .0 is out. This could be e.g. in the
 middle between .0 and .1 to not have the release workload for 2 releases
 at once. And: yes, I know, this is even more work for the release team.
 Poor Dirk.

That also makes a lot of sense (so +1 to this suggestion), but it is a 
different issue from the one at hand.

Kevin Kofler

Re: The case for a kdelibs 4.8

2011-09-29 Thread Scott Kitterman

On Thursday, September 29, 2011 03:27:58 PM Markus Slopianka wrote:
 On Donnerstag 29 September 2011 14:01:50 Kevin Kofler wrote:
  2. It will be confusing to our users, and even to some packagers, to
  have a KDE SC 4.8 on kdelibs 4.7.
 
 Since almost exactly 2 years we (esp. the promo team) are communicating that
 Platform/Frameworks, Applications and Workspaces are three separate
 products that just happen to be shipped on the same date.
 
 One of the reasons why the rebranding still didn't get to everybody is that
 some distributions (mostly Fedora!) still spread the wrong message about
 some “KDE 4.7” to its users. (see eg.
 https://fedoraproject.org/wiki/SIGs/KDE/KDE47Packaging#KDE_4.7_Packaging )
 
 Users of other distributions do not have such problems and strangely
 shipping Kontact 4.4.11 with SC 4.5+ was also not confusing to most users.

We did this in Kubuntu and it was confusing.  It was also technically 
challenging.  Speaking as someone investing a lot of time in trying to do a 
high quality job of distributing KDE to end users: Please.  Never, ever, do 
this to us again.

I get what you want to communicate, but it's more complicated that that.  The 
integrated release process of KDE has value.  Just happen to be shipped on 
the same date isn't true.  Marketing materials saying this are exactly that.  
Marketing materials.

I agree with the goal of trying to make it easier to use pieces of KDE in 
different contexts, but the integrated delivery process that marketing wants to 
dispense with has real technical value that I hope KDE will not discard.

The transition from kdepim 4.4 - 4.6/4.7 was a special case.  I hope it stays 
that way.  While there wasn't another way to do what had to be done in that 
case, it should not server as a general success story others should model 
themselves after.

Re: The case for a kdelibs 4.8

Markus Slopianka wrote:

 On Donnerstag 29 September 2011 14:01:50 Kevin Kofler wrote:
 
 2. It will be confusing to our users, and even to some packagers, to have
 a KDE SC 4.8 on kdelibs 4.7.
 
 Since almost exactly 2 years we (esp. the promo team) are communicating
 that Platform/Frameworks, Applications and Workspaces are three separate
 products that just happen to be shipped on the same date.

But now you're changing exactly that last part, or at least what will be 
released will no longer have a common and consistent version number.

And in any case, even if this particular argument doesn't convince you, that 
does not invalidate all the other reasons why there should be a kdelibs 4.8.

 One of the reasons why the rebranding still didn't get to everybody is
 that some distributions (mostly Fedora!) still spread the wrong message
 about some “KDE 4.7” to its users. (see eg.
 https://fedoraproject.org/wiki/SIGs/KDE/KDE47Packaging#KDE_4.7_Packaging )

This is not a page targeted at our users at all, it's an internal KDE SIG 
TODO list. We sometimes use shorthand when we discuss things, it is obvious 
to us that what's really meant here is the KDE SC. But I changed it to KDE 
SC 4.7 Packaging to make you happy.

And no, we cannot use a more specific term than KDE SC here, because this 
is really about packaging all the stuff that happens to be shipped on the 
same date, with a 4.7.n version number, by the KDE Project. The modules are 
released together, so they get packaged together.

 Users of other distributions do not have such problems

Wait and see the chaos that will come up when users open their Help/About in 
Konqueror and it tells them that they're using Konqueror 4.8.0 under KDE 
4.7.6. (And yes, it still says only KDE in 4.6.5, I haven't checked 4.7 
or 4.8 for whether that's fixed there.)

 and strangely shipping Kontact 4.4.11 with SC 4.5+ was also not confusing
 to most users.

Actually, that was (and still is) quite confusing to many users. Look at the 
mailing lists and forums.

I think this was a mistake that shouldn't be repeated. What should have been 
happened when the Akonadi stuff was found not ready would have been a:
svn rm branches/KDE/4.5/kdepim
svn cp branches/KDE/4.4/kdepim branches/KDE/4.5/kdepim
(and likewise for kdepim-runtime. And yes, SVN was still used at that time), 
i.e. mass-revert the unfinished stuff and do 4.5 releases of what works. 
(But the updated KAddressBook from 4.5 should have been used. The 4.4 one 
was already Akonadi-based and unfinished, and we ended up stuck with that 
temporary solution for over a year. It was a mistake to put that into 4.4 in 
the first place, but with that done, it should have been updated. 
Renumbering the releases to 4.5 instead of continuing with 4.4.x would have 
allowed inserting such a new feature.)

 The rule so far has always been that the kdelibs
 version must be the same as the KDE SC version.
 
 There is no rule – at most a common practise

A common practice which had been enforced by minimum required kdelibs 
versions in CMakeLists.txt.

 and that was broken as well after Fedora 15 has packages for SC 4.7 with
 Kontact 4.4.

Fedora 15 actually has KDE SC 4.6.x, not 4.7.

The upcoming Fedora 16 has KDE SC 4.7.x including kdepim 4.7.x, so the 
version numbers are finally consistent again.

 Changing this will also break all our Fedora KDE SC specfiles
 
 Then fix your specfiles. AFAIK Fedora is also the last big distribution
 that still has monolithic packages like kdemultimedia, kdenetwork, and so
 on. Take the opportunity to fix that as well.

If you had actually read that KDE47Packaging page you linked to and not just 
the title, you'd know that we're actually shipping some modules split in the 
upcoming Fedora 16. Not only are the modules released as split tarballs now 
all also packaged in split form, but we also split e.g. kdeutils into 
subpackages.

 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!
 
 Do you hereby declare that Red Hat will provide resources to create KDE
 Platform 4.8 and an cherrypick useful developments from the frameworks
 branch to Platform 4.8?

I cannot declare that because I don't work for Red Hat (let alone in some 
management position). I'm just a community packager for Fedora. Ask Red Hat 
directly.

Kevin Kofler

Re: The case for a kdelibs 4.8

Scott Kitterman wrote:
 We did this in Kubuntu and it was confusing.  It was also technically
 challenging.  Speaking as someone investing a lot of time in trying to do
 a high quality job of distributing KDE to end users: Please.  Never, ever,
 do this to us again.

+1

 The transition from kdepim 4.4 - 4.6/4.7 was a special case.  I hope it
 stays that way.  While there wasn't another way to do what had to be done
 in that case

Actually, there would have been another way: revert the Akonadi merge by 
copying the 4.4 branch of kdepim to 4.5 and release that as kdepim 4.5. As I 
wrote in the other mail, that would also have allowed updating KAddressBook 
(which was already Akonadi-based in 4.4) to the much improved version from 
the 4.5 branch (while discarding all the other, unstable changes from 4.5). 
And it would have prevented the version number confusion, the chaos with 
translations etc.

But IMHO the best solution would have been to postpone all this Akonadi 
stuff to 5.0 right from the start (especially considering that 5.0 is 
seriously being worked on now, to the point of stopping kdelibs 4.x 
releases). The original plan was for 4.0, that train was missed. 4.5/4.6/4.7 
is way too late in the 4.x cycle for that kind of major change, it belongs 
into a major release.

We (the KDE community) are now in the paradoxical situation where we won't 
ship even small uninvasive features in kdelibs, yet we happily replaced the 
PIM apps, which handle data many users consider essential, with what was 
essentially a rewrite. Yet both those apparently contradictory decisions are 
symptoms of the same problem: We really need to get used to working with 3 
branches: next major feature release, next minor feature release and bugfix 
release. It is needed in some cases. It would have been needed for kdepim 
(next major feature release = KMail 2 etc. for 5.0, next minor feature 
release = small, incremental improvements for 4.n+1) and it's needed now for 
kdelibs. Each time we try to save a branch, the conflicting requirements of 
doing long-term refactoring vs. delivering new features to our users lead us 
straight to a disaster.

 it should not server as a general success story others should model
 themselves after.

Big +1 to that!

Kevin Kofler

Re: The case for a kdelibs 4.8