TheBlackCat wrote:That is against KDE policy. Features cannot be added during a x.x.x release, only during an x.x release. Similarly, backwards-incompatible API changes cannot be changed during a x.x release, only an x release.

With all due respect, I would hope that it's against KDE policy to severely break existing functionality in a x.x release. I don't see the restoration of address book functionality as a new feature, but rather as the undoing of a mistake that was committed into the 4.4 release.

With the state of Akonadi as it stands, I'm very worried about how much Kontact will break in the 4.5 release. This is the right time to clean things up so that 4.4 and 4.5 are stable before jumping headlong into Akonadi.

Thoughts?

Kumaran

@kumaran

You're having installation problems, not stability problems. For me, akonadi does the work it should without any issues.

Wow, that's an attitude: Removing functionality is allowed, fixing it not - it's a feature, remember? Stability problems do not exist, ist' just your installation/distribution/somebodyelseidontkow? Akonadi is stable? Nepomuk is stable?

I really don't see when KDE4 will actually become stable. Just tested KDE4.4.3 on debian, krunner crashes now and then. But don't tell me, I know, it's the packagers fault.

We have a lot of machines from which to gather test data. This happens on machines with a fresh install of Fedora 12 with all updates. I find it hard to believe that it is simply an installation issue.

It is difficult to create robust software that works properly under a variety of conditions. The KDE team really needs to be more receptive to user feedback, rather than taking the attitude that it works for the developers therefore it is stable. It most certainly is not stable if users on a variety of distributions are reporting similar problems.

Sometimes your users are the only window into corner cases that you have not considered and cannot easily see in your development environment. Taking them seriously is the best way to improve the quality of your product.

The sad truth is that we can (and almost certainly will) debate this and similar frustrations until the cows march home. Futility! This discussion will - in the end - go nowhere and the users' voices will - as is more typical than not - once again be ignored. I also find it a completely nonsensical argument that the distributions are somehow at fault for the shortcomings of KDE (or any other project for that matter).

The 4.4 KAddressbook/Akonadi release was an utter and complete failure and a huge let down to loyal KDE users everywhere. Arguing technicalities and release rules and process serves no purpose except to soothe the sensitivities of those that made the release error. It certainly brings no comfort to users. And arguing that it can't be fixed until the next major release only deepens the frustration. More importantly, this rigid attitude is effectively driving long and loyal users away from KDE. Seriously! Think about that statement.

All I can say, as one of those very long and loyal KDE users, is that I'm incredibly disappointed by this trendy new attitude. One question that should be asked by the collective KDE design and development community - as they seem to bathe blindly in their technical vanity and prowess - is... for whom are we developing KDE afterall?

samhain wrote: ist' just your installation/distribution/somebodyelseidontkow? Akonadi is stable? Nepomuk is stable?

For me they are since ages. Not a single issue with those two subsystems.

I really don't see when KDE4 will actually become stable. Just tested KDE4.4.3 on debian, krunner crashes now and then. But don't tell me, I know, it's the packagers fault.

Why do you make your experience universal? With normal operations, I never get crashes. It's been ages since I saw a Plasma or krunner crash, as well. And you know the deal: install debug symbols, get a backtrace (the crash report does that for you) and post on BKO with reliable instructions on how to reproduce the issue. It's not that complaining here will get you anywhere.

> For me they are since ages. Not a single issue with
> those two subsystems.
>

How are you installing them?


> It's been ages since I saw a Plasma or krunner
> crash, as well.
>

Plasma on KDE 4.4.2 crashes on me twice daily.


> And you know the deal: install debug symbols

Here we can blame the package maintainers: it never finds the debug symbols for me to install.


Tell me, what is the "easy way" for non-devs to test the latest nightly builds of KDE? There was once a KDE Nightly project, but it seems to be no longer updated since late last year:
https://launchpad.net/~project-neon/+archive/ppa

dotancohen wrote:How are you installing them?

openSUSE, KDE:KDE4:Factory:Desktop repository.

Plasma on KDE 4.4.2 crashes on me twice daily.

The only way I can crash it is by triggering a bug that's not in plasma, but probably in libkonq or even further down the stack. Otherwise, rock solid.

Tell me, what is the "easy way" for non-devs to test the latest nightly builds of KDE?

If you like weekly snapshots, openSUSE's KDE:KDE4:UNSTABLE repository does the trick quite nicely.

I have a couple of reproducible crashes, but I want to test on a later build that has debug symbols.

> If you like weekly snapshots, openSUSE's KDE:KDE4:UNSTABLE
> repository does the trick quite nicely.

I will look into that, thanks. I have considered moving to Suse, but lots of software is not available in their most updated form. Anki and Zim I could probably build as they are small projects, but Stellarium 10.3, OpenOffice.org 3.2 Python 3, and others keep me on Kubuntu at this point. Is there a repo that contains updated software such as these?

There are extra repositories in the Build Service that would probably supply what you need. </OT>

Thanks.

Could I have instructions for replacing kaddressbook with 4.3.5 when building version 4.4.3, please. The instructions in the link above might work for 4.4.2 but it seems libkdepim/pimapplication.h is missing from 4.4.3. It takes 12 hours every try to build the package so trial and error isn't really a practical technique.

The important thing is that both end users and experimenters can get what they need, but packagers do need to know what the options are for that to happen.

I know there's a packagers' mailing list but I'm not the regular packager and I'm not sure busy people really have time to read E-mail discussions just to extract the info they need on a new release. Shouldn't this information be in release notes or a README?

Why do you make your experience universal? With normal operations, I never get crashes. It's been ages since I saw a Plasma or krunner crash, as well. And you know the deal: install debug symbols, get a backtrace (the crash report does that for you) and post on BKO with reliable instructions on how to reproduce the issue. It's not that complaining here will get you anywhere.

Sorry but the first person to make his experience universal is you. You claim several times that KDE works fine without problems allways with OpenSuse KDE 4 unstable packages, if fact seems to unstable works fine for you since KDE 4.0 because you always write the same, and me and one partner have several problems and crashes with some basic usage as copy and moving multimedia files with openSuse 11.1 & 11.2 and KDE 4 stable packages.

Seriously, we're thinking in install trunk packages because seems to be more stable than proper stables packages. Really funny .

You missed my point. "It crashes, it sucks" is not an acceptable attitude because what does not work for you may work for others. Bug reports with reproducible test cases are the only ways to track the issues down.

alessandro.rossini wrote:Unfortunately, as discussed in bug 233078, some of the KDE PIM developers are against this solution.

I had a look at the linked report but can't find any comment by a KDE PIM developer on it.
Are you sure you've linked to the correct one?

Cheers,
_