samhain wrote:

No I find out that in this situation within the "KDE development system" tends to act very similar.

Yes, but it's a KDE-only problem. I do not know any single other opensource project that ever forced/forces alphaware on the user and abandoned the stable version (Yes, I know, nobody told etc. etc.).

How many times does that have to be repeated just for you?
KDE3 is still around (now called trinity), and for a big bunch of people KDE SC 4.x is working quite good. Not for all of them though, sure.
And if you know it, why are you still making statements like this?

samhain wrote:

My question is: What can we do to improve the situation? How can the priorisation be refocussed to fulfill user neads?

Just be patient, in a year or two the software will probably reach rc1 status. That is, after the single point of failtures have bitten a grat amount of users, which has not jet happened (e.g. Akonadi is on it's best way to do this).

This is seriously making me angry. I don't how often it was said what can be done to improve the situation, and not just be patient. And stop the FUD about it becoming an RC in some years.
KDE SC 4.5 RC1 is the actual version, get used to it.
Oh, and to add some more info, the KDEPIMsters decided not to release with 4.5, they decided to polish a bit more before releasing.
But no, they don't think of their users...

samhain wrote:The problem is, there are too few developers working on too many open ends - just look at the buiglist.

Funny, you know it but do your best to drive the last developers away...

samhain wrote:And worse, the koordination is done technic-centered and user-centered. And to top it, it's quite impossible to change it, even if the project management wanted to (remember "The Mythical Man-Month"?) Where to get more developers? Don't know ... it's forseeable that the same struggle will come up with QT5.

Qt5 is far from being released, and KDE 4 will most likely not stop at 4.5, like 3.5 did.

Seriously, please, get some more productive, less sarcastic, that is soo boring, i am thinking myself to not visit this area anymore....
There is so much you could do, you seem to even know some strange book from 1975. I bet you have more to provide than what you did till now. If not and you are happily using KDE3, why are you even caring then about such topics?

Hi neverendingo

neverendingo wrote:Did you already post any X server logs somewhere? Because in case you don't even get a X login, this might also be related and not KDE at all. Or maybe KDM.
So look into cat /var/log/Xorg.0.log or ~/.xsession-errors and look for errors (in the former they start with EE)
Note: If you want to report something like that, open another topic in the appropriate area so it can be found more easily and is not mixed with a discussion.

This is one example. I do not look for a solution in this posting - thank you!

mhl wrote:Think of what I wrote above! Where is the overall coordination? How does the development involve the users? What about the release management?

neverendingo wrote:Like david_edmundson already wrote, the majority usually decides, and then it is to someone being willing to implement it in their free time.
As for project coordination, there is not really an overall KDE project coordinator. Every subproject has a maintainer who is responsible for what goes in and what not.

I am really not sure how this should work. My experience especially is that the parts do not fit together. So there should be more overall coordination!

neverendingo wrote:(...)
But most importantly of all, plain complaining doesn't bring you anywhere. Reasonable arguments, respect and patience always brings you further.

You are right, complaining is dangerous! But sometimes even showing that the situation is really unsatisfying might help. The overall situation frustrates users like me! When looking at bug reports everone will see single bugs and it is hard to realize if the parts fit together - or not!

The development and release management should sit together and discuss a way to improve quality especially in the are of the interfaces or let's say the overall fitting together of the parts.

Thanks for your patience! Martin

"I am thinking myself to not visit this area anymore.... "

I would suggest doing that, I will do the same. I could spend time arguing - or I could go triage some bugs.

I know which I'm gonna do.

Best Regards

mhl wrote:Hi blackcat,
I can only say: I do not understand the problem either! In case of kaddressbook I understood exactly what Akonadi was designed for. Very good idea but a. it should not have been released like that and b. kaddressbook is central part of KDE PIM so why do you write "I do not understand the problem" and "besides kaddressbook" Akonadi is no necessary part of KDE 4.4. KDE PIM is a central part of KDE and the addressbook has always been and still is a central part of KDE PIM. So the conclusion is: kaddressbook should never be releases like it was with reduced functionality (or at least give us a migration path!) and severe bugs. (By the way you are wrong: Akonadi is used for kalender as well and this does not work either even in worse way: calender entries are eliminated after having entered!)

First, akonadi can be used for the calendar, but it is not required yet. Second, the limitations of the early 4.4.x release of kaddressbook were well-publicized, if your distribution decided to use it anyway then you should be blaming them. There is no problem whatsoever with a distribution holding off on switching to the akonadi-based applications until they are considered stable. In fact some distributions like openSUSE are doing exactly this, while providing optional akonadi-based versions for those who want them. Whether kaddressbook should have been released or not is a valid question, but there is no question whatsoever that it would have been a non-issue if distributions had done their duty and released stable versions of the software.

In this case, though you are using debian testing, which is by definition unstable software. If you are willing to use an unstable version of a distribution, then you have to be prepared to deal with unstable software. That is what unstable distributions are for.

mhl wrote:But again: This posting is not to complain about single bugs, what I try to make clear is that there is a lack of coordination in the whole project!.

Really? So I assume you have read the kde-pim mailing lists to find out what sort of discussion has been going on? Or is this just your interpretation based on how you perceive the results of a series of independent decisions made by both the KDE-pim team and by the debian packaging team?

mhl wrote:And I don not write this to tell you that I am angry about the developers. I am confused and tired and really deranged about the fact that open source is developped like that. For a very long period we all thought that open source development is a model that is much better than the one that Microsoft or Apples uses. No I find out that in this situation within the "KDE development system" tends to act very similar.

How is it similar? Debian packagers either intentionally packaged software with known limitations (which I can't fault them for, it is an unstable version of the distribution), or they didn't do their homework (which I can fault them for because that is a distribution's responsibility).

mhl wrote:My question is: What can we do to improve the situation? How can the priorisation be refocussed to fulfill user neads?

Maybe by distributions not pushing software with well-publicized limitations, or users not expecting unstable distributions to somehow be stable.

Hey Blackcat!

Seriously, besides the fact that I am a bit tired of the problems that went after me since I have been using KDE Linux (from 1999 until now this is not a very short period!) I am asking myself what could be done to improve the situation. Please do not forget: I like the idea behind KDE 4 and I am sure this is kicking away Windows <No.whatever>

TheBlackCat wrote:

mhl wrote:My question is: What can we do to improve the situation? How can the priorisation be refocussed to fulfill user neads?

Maybe by distributions not pushing software with well-publicized limitations, or users not expecting unstable distributions to somehow be stable.

We all know that you saying: "You use debian testing!" is an argument that I cannot argue against. But there are to many problems that are not directly linked to this question. e.g.:

1. Is Akonadi really only released with stable distributions? If yes, my argument is killed. If no I wonder if it really works.

2. What could be the reason to kick of functionality in kaddressbook that was used and where there is no migration path. E.g:

a. Categories are gone what means that filters are gone what means that the export functionality is half the way senseless.

b. Why there are less fields or even field names mixed up? Same effect as with a.

3. Konqueror / Dolphin: Where did the bookmarks functionality go? Does it really work as it worked before in stable releases? Try to move folders e.g.!

4. A pure functionality / release planning question: What happened to the application independent printing preview functionality? See brainstoming entrance viewtopic.php?f=83&t=84727. This was in december, up to now I cannot see that any of the typically used applications supports printing preview. So, what is the benefit for us users? What I do not like about this, is, that now it more looks like Windows. Before there was a real benifit compared to Windows, now printing preview is gone. Is this really a "Debian Testing" problem?

5. Cut-and-paste ...now only works likes it always worked under windows - the longer, complicated way.

6. CPU ressources / power management: My fan is running all the time with two applications at the top but the CPU usage changing all the time: kmail and Xorg. But, yes it seems to be kmail. Maybe this has to do with akonadi, who knows?

7. I could find some more examples, e.g. Amarok and this audio CD question. But again, the main point is not the complaining but to ask for good reasons why functionality changed.

You tell me to watch the mailing lists before deciding to update? Which mailing lists should a user watch? How many? Which are the right once? Priority on KDE mailing lists or distribution mailing lists, german or english? Think of it, not only development is time consuming!

Regards, Martin

mhl wrote:1. Is Akonadi really only released with stable distributions? If yes, my argument is killed. If no I wonder if it really works.

Define "stable distributions". Some distributions have a policy of releasing bleading-edge software even if it isn't entirely functional, others release only software that is mostly stable (no software is completely stable), others wait even longer, some wait until the software is basically obselete. It all depends on the culture of the distribution. As I said, openSUSE, which tends to be in the "mostly stable" camp, is sticking with non-akonadi versions now. Fedora, which tends to be more in the bleeding-edge camp, wouldn't surprise me if it went with akonadi straight away. People have to understand the culture of their distribution.

mhl wrote:2. What could be the reason to kick of functionality in kaddressbook that was used and where there is no migration path. E.g:

Because they wanted people to start using it so bugs that can't be found any other way could be found. This was all explained in the announcements regarding the KDE pim release for 4.4.0.

mhl wrote:3. Konqueror / Dolphin: Where did the bookmarks functionality go? Does it really work as it worked before in stable releases? Try to move folders e.g.!

I thought konqueror has bookmarks. Dolphin never had bookmarks, I think it was expected that people would use the sidebar instead. People who really like bookmarks can use konqueror.

mhl wrote:4. A pure functionality / release planning question: What happened to the application independent printing preview functionality? See brainstoming entrance viewtopic.php?f=83&t=84727. This was in december, up to now I cannot see that any of the typically used applications supports printing preview. So, what is the benefit for us users? What I do not like about this, is, that now it more looks like Windows. Before there was a real benifit compared to Windows, now printing preview is gone. Is this really a "Debian Testing" problem?

In the switch from 3.5 to 4.0 it was thought that Qt's printing dialog would soon have all the features of KDE 3.5's. This did not happen, but this was not under KDE's control. Making such a dialog is not a trivial manner, it has proven to be very hard especially since KDE is trying to stick to well-maintained Linux standards shared with Gnome whenever possible. Most, if not all, of the functionality will be back by 4.6.

mhl wrote:5. Cut-and-paste ...now only works likes it always worked under windows - the longer, complicated way.

I am not sure I understand. I have not noticed any change in cut and paste that cannot be fixed by modifying the klipper settings.

mhl wrote:6. CPU ressources / power management: My fan is running all the time with two applications at the top but the CPU usage changing all the time: kmail and Xorg. But, yes it seems to be kmail. Maybe this has to do with akonadi, who knows?

Kmail should not be using akonadi. Why do you think it has anything to do with akonadi, or KDE at all? Have you made any effort to see what applications are actually triggering the CPU load, or are you just making wild guesses?

mhl wrote:7. I could find some more examples, e.g. Amarok and this audio CD question. But again, the main point is not the complaining but to ask for good reasons why functionality changed.

Functionality changes for many reasons. It might be because the old functionality was bad or considered bad by developers (e.g. kicker). It might be because someone came up with a better way (e.g. plasma). It might be because changes in the underlying tools that KDE is based on required changes or opened up better possibilities (e.g. Qt 4 or pokit). It might be because changes in the underlying tools required major rewrites and not all functionality is back yet (also Qt 4). It might be because there was a change in the focus or goals of the project (e.g. gwenview).

mhl wrote:You tell me to watch the mailing lists before deciding to update?

No, I am telling you:

1. Pick a distribution that fits with how you like to use your system. For example, don't pick a distribution that is known to use bleeding-edge software if you want a stable system.

2. Don't accuse developers of not communicating with each other unless you have actually looked at what sort of communication was really going on.

Hi TheBlackCat,

these were examples, I told you that!

TheBlackCat wrote:

mhl wrote:

mhl wrote:2. What could be the reason to kick of functionality in kaddressbook that was used and where there is no migration path. E.g:

Because they wanted people to start using it so bugs that can't be found any other way could be found. This was all explained in the announcements regarding the KDE pim release for 4.4.0.

Interesting, you really tell me this? Changing field names in a live system to find bugs? Deleting "categories" to find bugs? this is really "funny"!

mhl wrote:3. Konqueror / Dolphin: Where did the bookmarks functionality go? Does it really work as it worked before in stable releases? Try to move folders e.g.!

I thought konqueror has bookmarks. Dolphin never had bookmarks, I think it was expected that people would use the sidebar instead. People who really like bookmarks can use konqueror.

A bug, it does not work any longer!

mhl wrote:4. A pure functionality / release planning question: What happened to the application independent printing preview functionality? See brainstoming entrance viewtopic.php?f=83&t=84727. This was in december, up to now I cannot see that any of the typically used applications supports printing preview. So, what is the benefit for us users? What I do not like about this, is, that now it more looks like Windows. Before there was a real benifit compared to Windows, now printing preview is gone. Is this really a "Debian Testing" problem?

In the switch from 3.5 to 4.0 it was thought that Qt's printing dialog would soon have all the features of KDE 3.5's. This did not happen, but this was not under KDE's control. Making such a dialog is not a trivial manner, it has proven to be very hard especially since KDE is trying to stick to well-maintained Linux standards shared with Gnome whenever possible. Most, if not all, of the functionality will be back by 4.6.

Ok, that means, the KPrinter-Dialog is gone because of QT? And it will be back in 4.6? I would like to see that!

mhl wrote:6. CPU ressources / power management: My fan is running all the time with two applications at the top but the CPU usage changing all the time: kmail and Xorg. But, yes it seems to be kmail. Maybe this has to do with akonadi, who knows?

Kmail should not be using akonadi. Why do you think it has anything to do with akonadi, or KDE at all? Have you made any effort to see what applications are actually triggering the CPU load, or are you just making wild guesses?

Now you are starting to offend me - can you please stopp that? For this wild guess there exists a bug report and the problem seems to have vanished but reappeared. Noone can say what the reason is but this periodically (within 2 sec.) high CPU usage of kmail without happening anything is really annoying.

mhl wrote:7. I could find some more examples, e.g. Amarok and this audio CD question. But again, the main point is not the complaining but to ask for good reasons why functionality changed.

Functionality changes for many reasons. It might be because the old functionality was bad or considered bad by developers (e.g. kicker). It might be because someone came up with a better way (e.g. plasma). It might be because changes in the underlying tools that KDE is based on required changes or opened up better possibilities (e.g. Qt 4 or pokit). It might be because changes in the underlying tools required major rewrites and not all functionality is back yet (also Qt 4). It might be because there was a change in the focus or goals of the project (e.g. gwenview).

Yes, for sure, there might be one thousand reasons! I say this again and again: the problem is the release policy! and this is not only a problem of the distribution but the KDE coordination. If there are too many holes on the road the way is slowed down too much.

After more than ten years experience with KDE I can tell you:

1. Yes, what we see on the road is nice!

2. Currently there are too many bugs!

3. The way, functionality is kicked away without checking what happens to the users out there should be overthought!

Martin

mhl wrote:A bug, it does not work any longer!

Do you have a reproducible test case?

mhl wrote:Ok, that means, the KPrinter-Dialog is gone because of QT? And it will be back in 4.6? I would like to see that!

To be precise, at the time of 4.0 there was not enough manpower to port KDEPrint to the new infrastructure: printing is complex, and the few people who got it right had no time. It was then suggested to use Qt's printing dialog, hoping that it would incorporate the missing features over time.

It didn't really worked that well, although now it's definitely better than before.

mhl wrote:high CPU usage of kmail without happening anything is really annoying.

The fact is that it cannot be Akonadi's fault, since KMail, in released versions, does not depend on it nor does use it.

This is the kind of "back & forth" that I miss in the forums. People lay out their thoughts, ideas and passions and then defend them!

mhl wrote:]Interesting, you really tell me this? Changing field names in a live system to find bugs? Deleting "categories" to find bugs? this is really "funny"!

Changing field names sounds like exactly the sort of bug that they needed to do a release in order to find. Categories were not removed, they did not have the time to re-implement them using akonadi in time for the release, and they thought it would be better to get it out there so people could start using it rather than have to wait another 6 months for KDE 4.5.

This is all explained in the release announcement, as I said repeatedly now. I don't expect every user to read every release announcement, but now that I have pointed out at least twice that the answers to your questions are there, I would think you would take the hint and read it before asking more questions just on the off chance those questions have also already been answered.

mhl wrote:A bug, it does not work any longer!

Works for me. Did you file a bug report?

mhl wrote:Ok, that means, the KPrinter-Dialog is gone because of QT? And it will be back in 4.6? I would like to see that!

I'm not sure KPrinter-Dialog itself will be back, but most or all of its functionality (and probably some new functionality) will be present.

mhl wrote:Now you are starting to offend me - can you please stopp that?

Why am I offending you? It is a legitimate question. Why is it so outlandish to ask on what basis you draw your conclusions? You already admitted a great deal of uncertainty in blaming akonadi.

mhl wrote:For this wild guess there exists a bug report and the problem seems to have vanished but reappeared. Noone can say what the reason is but this periodically (within 2 sec.) high CPU usage of kmail without happening anything is really annoying.

Fascinating, but it doesn't actually answer my question: how do you know it is akonadi's fault, or even kmail's fault?

mhl wrote:Yes, for sure, there might be one thousand reasons! I say this again and again: the problem is the release policy! and this is not only a problem of the distribution but the KDE coordination.

No, you specificaly asked me for the reasons. Now that I give you the reasons, with specific examples, you turn around and say you don't care about the reasons. If the reasons are not important why did you ask for them?

And I ask you again: did you actually look at the mailing lists to see what sort of coordination is actually going on? You make specific allegations about a lack of coordination, which very well might be valid, but have you made any effort whatsoever to actually check how much effort goes into coordination?

mhl wrote:3. The way, functionality is kicked away without checking what happens to the users out there should be overthought!

Functionality is not "kicked away", more often then not there simply isn't time to re-implement it. There are only so many developers and so much time. And believe me, I do read several of the mailing lists and a lot of thought and discussion goes into what happens to users.

You complain about being offended, but this accusation of yours is far more offensive to the developers who expend a lot of effort in their free time to give you a totally free desktop environment, is apparently made without any attempt to actually check whether it is true, and is completely and totally opposite of reality. So if you are getting offended simply by being asked what basis you have for your conclusions, imagine how developers feel when they are outright insulted for supposedly not doing something they spend a lot of time and effort doing.

einar wrote:The fact is that it cannot be Akonadi's fault, since KMail, in released versions, does not depend on it nor does use it.

[/quote]
Though it does not really depend or use it, KMail from kdepim 4.4 does start Akonadi at startup and, if Akonadi fails to start, KMail is forced to close.

dpalacio wrote:

einar wrote:The fact is that it cannot be Akonadi's fault, since KMail, in released versions, does not depend on it nor does use it

Though it does not really depend or use it, KMail from kdepim 4.4 does start Akonadi at startup and, if Akonadi fails to start, KMail is forced to close.

Thank you dpalacio, that really is what happens. To be honest, I already forgot this behaviour because starting KMail twice is something I do very often, so I get used to this fault - bad enough! Here is the bug: https://bugs.kde.org/show_bug.cgi?id=240695

If blackcat says: Akonadi is not necessary to run KMail and in fact the starting behaviour does not work, there must be some interaction between Akonadi an KMail!

But let me come back to the way I "complained" and what developers may offend: I say it is a question of coordination and release policy. In addition I say: Why does "the KDE team" believe, that the user would be able to analyse the situation and find out that akonadi or maybe nepomukservice is the reason for time consuming behaviour of applications like Kmail if even the error service (deleopers) has no idea what really happens. Here a bug report on this question: https://bugs.kde.org/show_bug.cgi?id=225602

For users it is extremely difficult and time consuming to analyse bugs and the situation is getting worse if there are many bugs and noone - really! - knows, what dependecies exist.

Regards, Martin

KMail uses Akonadi for it's address book functionality, as KAddressBook uses Akonadi in 4.4

dpalacio wrote:Though it does not really depend or use it, KMail from kdepim 4.4 does start Akonadi at startup...

Correct, as a dependency of its address book access functionalities.

When people write it does not use Akonadi yet, they usually mean that it does not use Akonadi for its main data (emails) yet,

...and, if Akonadi fails to start, KMail is forced to close.

Which was actually reporting a wrong cause. Akonadi did start, but KMail didn't detect that correctly.
This has been fixed in both the upcoming version as well as 4.4.5
https://bugs.kde.org/show_bug.cgi?id=236538

Cheers,
_

Hi Anda,

anda_skoa wrote:

dpalacio wrote:Though it does not really depend or use it, KMail from kdepim 4.4 does start Akonadi at startup...

Correct, as a dependency of its address book access functionalities.

When people write it does not use Akonadi yet, they usually mean that it does not use Akonadi for its main data (emails) yet,

what in my opinion sounds quite funny because what is KMail without adressbook functionality? Noone uses a Mailsystem for more than two days without using the addressbook func. So this functionality is a central function of the mail system even if we see it modular.

This is one reason why I think some discussions in here are time consuming. If e.g. someone wants to criticize Outlook for its addressbook func. propably noone will say "oh, this is not Outlook, this is addressbook!" and so on.

...and, if Akonadi fails to start, KMail is forced to close.

Which was actually reporting a wrong cause. Akonadi did start, but KMail didn't detect that correctly.

So this is a kmail bug and no Akonadi bug! Or even more precisely: This is (was) a bug of the interface between KMail and Akonadi! From the users perspective it does not make any difference anyway. He only sees: KMail will not startup correctly and this every time it is started. (Loss of data possible in specific matters!)

This has been fixed in both the upcoming version as well as 4.4.5
https://bugs.kde.org/show_bug.cgi?id=236538

Cheers,
_

Thanks a lot for the clear statement, this helps! Thank you for bug fixing and thank you for telling me that this bug is fixed I have to check if my bug report was closed!

Regards, Martin