While simple answer to your post is: "You don't take in account all issues, which as many simplifications in real world lead to conclusions that may, or may not, survive more thorough scrutiny. " I'll take time to go trough and answer the best I can. That will be incomplete too, but it will be based on more details and more accurate. On Sunday 12 April 2009 02:34:20 pm Richard wrote:
On Sun April 12 2009 1:52:46 pm Rajko M. wrote: ...
can you re-read what you wrote. I'm very sure that anybody using "ALL" have actually no idea what he is using, nor he tried to find equivalents.
Focusing on words like ALL or EVERYBODY in an attempt to cloud or divert the real issues is a favorite tactic o people that Pete was responding to and often it is successful in clouding or diverting the real, underlying issue(s). The OP wasn't lambasting KDE4, he was saying that while attempting to upgrade KDE3, a change in KDE4 caused a failure.
I do understand that. I just noticed that, in my opinion, one should not use easily "all" and "everybody". First, we usually can talk only about our experience, and we are not "all" and "everybody". Second, to avoid mentioned I'm looking for numbers in miscellaneous statistics. They suprise me more often than not, which indicates that talking from my corner of the world is not valid either as "all", nor "everybody".
He asked the legitimate question which I paraphrase 'Why not fix bugs especially the easy ones because I have pointed out what and where the bug lives and when it happened'. Sven chose to make it a KDE3 vs KDE4 issue,
It is not Sven's choice to switch topic. His first respond to original poster states (paraphrased) that Novell has no plans to dedicate people to maintain KDE3. In current time, when everyone is forced to rationalize, they want KDE4 to be developed as fast as possible. It is left to openSUSE volunteers and their interest to keep KDE3 up and running. Some people do that, trying to incorporate new stuff offered in KDE4 libs, but it obviously doesn't work well all the time for all little conveniences we are used to. Without looking in the code no one can tell what is more important, one function, or security fixes in newer implementation. Is dropped function problematic one that needs serious work to be safe, or it is just oversight by developers. That means without knowing background, that we don't know, claiming it is easy fix is not substantiated with anything relevant.
not an issue that is much more fundemental to todays support and development model(s).
You worked with software where you was creator and you was able to make decision what, when and how, it will be fixed. The openSUSE as distribution has not that luxury. First mainstream/upstream is deciding in all three of the questions for majority of software included. If openSUSE developer decide to fix a bug the way openSUSE users want and upstream doesn't accept fix, he is stuck to fix every version after that, as long as it goes [1]. Second, distribution developers responsibility is not to fix all the bugs in all applications they incorporate. Their responsibility is to fix only parts they changed in upstream code in order to make applications work fine based on common versions of libraries.
I'm talking as KDE3 user that moves KDE4 applications in File Associations, from second to first place, and that makes me informed about issues that people can face. The difference between applications is by the day smaller, with more settings offered on KDE4 side. Not all components are at the same development level, but what seems to be fairly well completed is better than what is provided in version 3.
Again, the issue isn't one of KDE3 vs KDE4 and no one argued that KDE4 is not progressing nicely but one could argue that until it is much further along, it is premature to drop, even remove, a previous and essentially complete and functional product especially for the sake of developing a functional replacement.
KDE4 is just reaction to KDE3 status. KDE3 had too many patchworks introduced to allow use newer hardware capabilities, new demand for functionality, that did not exist few years ago when ground work for old KDE was done. Maintenace of that code required too much effort, and any improvement would mean much more work then rewriting. Note that I don't know much about coding and what I mentioned above is what I picked up from KDE web sites, and some comments on problems with the code are few years old when nobody was thinking of KDE4. I guess that anyone of developers would rather move slowly without stirring water, if that would not mean much longer period of breaking stuff and fixing bugs. One of issues is also that KDE woke up somewhat late, so rush to expose KDE4 to user base to test should be understood, specially that openSUSE is one of very few distributions that still give users option to run KDE3 as main desktop, and KDE4 as playground.
While KDE4 2.2 is a long way ahead of earlier versions, it still isn't ready to be jammed down peoples throats by saying if you want to upgrade your system (kernel, drivers, other applications, etc), you will lose the Desktop Environment that currently works well for your needs, worse, as Sven indicated in a previous post in this thread, it will remove previous versions. So, 11.2 will damage existing installations if you aren't careful when you *upgrade*.
The problem is that assumption (that 11.2 will damage existing KDE3 installation) is pulled out of thin air. The installer can be designed to refuse to update (upgrade) system without explicit user permission.
See this: http://en.opensuse.org/KDE_Configure_Desktop/General/Desktop/Window_Shado w itty-bitty function that never existed in KDE3. Important if you want to tune graphical layout to perfection, not important if you have customers that will stick with you despite competition that offers all the same plus good look, which indicates attention to detail. ... No one said that KDE4 doesn't potentially offer new or even valuable features. What has been said is that fixing bugs should be of a higher priority than trying to add features. Fixing bugs in an earlier, but still included in the current distribution can often prevent the same thpes of errors from be incorporated in the new development version.
Only guys that work on KDE (and those that can read the C++) know why they don't fix some of reported bugs. It could be that bug is in Qt libs and already fixed in Qt 4.5 while still present in Qt 4.4 that we use with KDE 4.2.2. The big problem is when users assume, or being pushed into assumption by people that show some knowledge, that there is something like single block of code called KDE4 that has errors, and it is only up to the KDE developers to fix them. What application developer can do if his code depend on libraries (kdelibs) that further depend on another libraries (qtlibs) and bug is there, ie. qtlib function doesn't work the way it is advertised in API documentation. You can make workarounds, but when Qt devs correct problem you are stuck with code that is incompatible. That happened with 4.2.2. In order to improve user experience, fast, they fixed part of the application code they are responsible for, and now you can't use Qt 4.5 with KDE 4.2.2. I'm sure that you don't advocate this path, it is waste of time.
Unfixed bugs are often there because of bad logic which will often be used in the new development and thus propogate that type of bug in the new code. Of course, the mentality of not fixing bugs in current releases because a new one is under development won't stop the developend version from having the same/similar bugs. Worse, once released, that becomes the 'current' version and won't be fixed because a 'newer, more wonderous, less ancient, etc. version is again under development so the bug will have yet another chance to propogate.
Whole logic of above statement is in general correct, but applied to KDE it assumes that KDE guys have no interest to create correct working code, which is flat wrong. They are not children, many work for companies that have interest in KDE well being, other can expect if they are good in KDE someone will offer them employment (it happened before), so you can imagine that majority has very good incentive not to show even remote signs of irresponsibility that many poster here and around the Web take as primary assumption for their claims.
Rajko, while I occasionally, even farily often, disagree with you on some issues, I respect you because in the bigger picture, I perceive that you are being, or trying to be, constructive. The person you responded to has none of those virtues, nor my respect.
You already answered that in separate email. Pete is just annoyed because things he is using doesn't work, but that will be addressed. Not every KDE developer has the same amount of time to fix the things, nor KDE as a whole should stop development until they are done. I've read somewhere idea of reassigning resources, but that is not possible with exception in some special cases. While all developers can read and write C++, that doesn't mean that they all know special requirements of each application. Expecting that you can reassign email client developer to help guys handling graphical interface, or vice versa, because they both use same programming language is the same as expecting that mechanical engineer can handle electronics design issues, only because they both talk English.
FWIW, I too use KDE3, have KDE4 installed and seen a lot of progress. That isn't the real issue. I hope KDE4 succeeds my wildest hopes and even the wildest expectations of those involved with its development, the issue is one of priorities and attitudes and while KDE is a good example of how not to introduce a new product, it isn't even the issue of this thread.
I'm pretty sure that KDE will make it. Idea of small changes that break nothing is noble, but that doesn't work well when you want to go from system designed with year 2000 hardware, as a base, to year 2007 hardware. You have to change fundamental assumptions what you hardware can do. Not to mention underlaying software (kernel) changes, new services introduced since 2000, and, of course, user expectations. [1] The branching of OpenOffice to Go-OO http://go-oo.org/ is consequence of something like that. I was witness - bug reporter - where discussion on OpenOffice bugzilla was defense of difference to MS product, for sake of difference, exposing user to unexpected Calc behavior. It was stupid small thing about graying out Save when file is not changed, which works fine in text editor (most of the time), and not in Calc. The openSUSE developer agreed that Save should be available all the time, as there is no damage if you use Save on file that is the same as before, but upstream disagreed. The bug report there is long living, few years old, with a lot of comments, and I don't think it will be solved anytime soon. Of course this periferal usability issue would not make reason for Novell to dedicate developers time to Go-OO branch, there was many more, and many of them substantial, I guess youcan find them somewhere on Go-OO web site. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org