The KDE Project announced
KDE 3.1.4 today. It's the fourth maintenance release of the successful KDE 3.1.x series and
ships with many bugfixes and improved translations. KDE 3.1.4 also contains two fixes for security issues in KDM. Users of KDE 3.x are advised to upgrade to KDE 3.1.4. Read the incomplete change log or jump directly to the
download links on the KDE 3.1.4 Info Page. The Konstruct build toolset was updated accordingly.
Dot Categories:
Comments
Myth. Been here: http://c2.com/cgi/wiki?RecentChanges lately?
And what? I mean, how wrong it would be if we have less buggy KDE 2.0?
I would actually prefer it.
Matej
Would you rather use less buggy (than it really was) KDE 2.0 or current KDE 3.1.4?
Go ahead, sponsor a (team of) KDE developer(s) to clean out all bugs. As most of the current KDE developers are doing it in their spare time without any payments, they are bound to be working on stuff they are interested in. Bughunting is not much fun, although I agree it's nessecairy.
I'm giving an all I can to the KDE community at the moment. If I could sponsor a team of KDE developers to clean out bugs I would, unfortunately I can't and that's besides the point. While the developers valuable efforts are much appreciated, with the right policies we could encourage them kill bugs relating to their apps before they commit sizzling features of interests to them. Bughunting is as much of the development process as testing and coding. Or perhaps, I'm being idealistic again.
Make that "pretentious". You obviously don't contribute to KDE in the way of code, and yet you try to lecture the ~200 regular contributors about the best way to approach KDE development. Just appending "I'm oh so grateful, by the way" does not give you this right to mock.
I find your response repugnant and insulting. Even if I don't contribute to KDE in the way of code, couldn't there be other means I could contribute to KDE? First you insult my integrity then you *mock* my contributions to KDE because I don't provide code to the community. I guess the only way I can contribute suggestions to is if and only if I'm a coder, right?
And when did I need to provide code to be a bonifide member of the community. If you do not agree with my suggestion there other less rude ways to state you point, rather than attack me in person. I'm not here to lecture anyone. You can agree with my suggestion, disagree with it or just shut up. Good day.
" And when did I need to provide code to be a bonifide member of the community. "
You don't. The KDE project is not just developers. It's programmers, doc writers, helpers, artists, and even layabouts giving suggestions :)
As someone who *does* code and contributes semi-regularly to KDE, I'll have to say that although programmers are probably the single most important part of the __development__ of KDE, the KDE project itself would have gone nowhere fast without anybody else besides programmers.
he did not say that! He just said that he doubts that you are qualified enoguh to give an objective and helpful answer about what KDE should focus on in their development process.
Of course there are many ways to contribute to KDE and they are all much appreciated. kde.org/support
So we've boiled down the KDE community down to a select few? Elitism? "The few, the brave". If your name is not on the NOC list, your opinions don't apply! Leave promptly to your left. Thank you!
The rule has always been: "Who contributes, decides", because it can't work differently when you are dealing with free software. Why do you think people would implement your vision of something if they don't agree in their spare time? Either go and do it yourself or pay someone do to it for you, but don't expect the KDE Developers to be your personal code drones.
And "Contribution" is not equal to "hacking". there are a lot of things non-developers can do. Check out Aarons' WhatsThis tutorial for an example, artwork, translation and documentation for others. Contribute! Make yourself a name, be reasonable. That's what will get you respect in discussions.
KDE is no exclusive club. But people that keep demanding things while never contributing anything start to be annoying after a while. How would you react when you give out chewing gums to a kid and then the kid comes back every day expecting a new chewing gum with a new flavor and when you don't react it sits down and cries until you get him one? I hope you get the point.
Contributors and bugreporters are welcome, whiners not.
Cheers,
Daniel
> Contributors and bugreporters are welcome, whiners not.
Fully ACK. A year without no features and just bug fixes would probably even cause many contributors to lose interest in KDE and stop developing for that year. I probably would. Thank god that KDE doesn't really have a central authority that sets broad ranging policies like that.
I think that you miss an important point.
Software needs to be designed -- it must do the proper things.
If we take your paradigm that 'he who writes the code decides' in that context it must mean 'he who writes the code designs it'.
So suppose then that the 'he' got the design wrong.
If we follow your idea; if someone else is capable of clearly stating exactly what the code does wrong and how it should work, then are you saying that this information has no value -- that it would not be a contribution because that someone didn't write the code?
Designing something is not trivial. There is (or should be) a place for people that can only contribute by designing.
--
JRT
> Designing something is not trivial. There is (or should be) a place for people that can only contribute by designing.
Sure, but remember that open source != real/commercial world. Open source software is driven most by people who contribute in a physical manner. That means actual coders, doc writers, translators, artists, etc...
People who contribute in a non-physical manner (designers, bug reporters) are also greatly appreciated by open source projects. The KDE project greatly appreciates them. However, unfortunatly, they aren't simply going to have as much influence compared to physical contributors. The KDE project is not a company where the non-physical contributors can force the physical contributors to do something (e.g, managers/project leaders, etc.. in a company compared to programmers, artists, etc..)
This is the strength of OpenSource (and at the same time its weakness)... !
Imagine a major car manufacturer, where the management fires itself and only the engineers decide what's cool and what's going to production.... heck, sometimes I wish it would be that way (even if I would have to learn a few more buttons and the tutorial would always date 2 years back..., but it'll be worth it)
O.k., they tell you the car would be way too expensive and just too 'geeky' for the average user..., well be it that way: average cars for average people
> ...remember that open source != real/commercial world.
Since when? I thought I was /really/ using this software. I also thought that most distros /really/ sold OSS.
Must have been a dream....
Alright, I should have said, "KDE is not developed like a typical commercial application"..
> Even if I don't contribute to KDE in the way of code, couldn't there
> be other means I could contribute to KDE?
Oh sure... documentation... art work... about a million other things.
> I guess the only way I can contribute suggestions to is if and only
> if I'm a coder, right?
If you're going to critiscise the coders then I think it would be prudent if you because one of them first. Nearly everybody works on KDE in their spare time because they enjoy it. You have to understand that implementing features is fun. Fixing bugs -- while vital -- isn't quite so fun. If you think you can try and make everybody only fix bugs for a year then you are at best misguided.
Postpone KDE by one year and GNOME will come and kill you dead. Guaranteed.
GNOME 2.4 already is far behind 3.1 except in a few areas. Remember that there was a huge lull in GNOME development from 2001 to 2002 because of gnome2 development.
Why? KDE had a lead on GNOME, yet GNOME didn't die. Xfce, Xpde, Windowmaker, Fluxbox and many other DEs/WMs are still around.
I don't get this "KDE vs. GNOME" mentality so many seem to have here at the dot. They are both great products, and they both do some things better than the other. Let's just leave it at that, and work towards better versions of KDE, OK?
So? As long as you make regular KDE releases that's fine.
KDE does have far too many bugs but releasing a bug free product is just about impossible and would take many years of development, developer swould quickly lose interest and so would users because amny bugs are obscure and so msot won't even notice that they were fixed.
KDE would be great if it just slipped from 5,000 bugs to sub 2,500.
> KDE would be great if it just slipped from 5,000 bugs to sub 2,500.
Let's assume every second bug would be fixed but none of them would have ever affected you or would have been noticed by you: You would still be moaning. Summary: Only bugs which affect you currently matter, not numbers of reports of everyone collected over all time.
I think that I said something like that after 3.1.0.
Actually, I suggested a paradigm shift so that the development tree configuration favored fixing bugs over developing new features.
This was posted to the: "kde-devel" list and all I got was flamed. :-(
--
JRT
The best way to not have any bugs is to not have any users. Look at the list of bugs per module. It is highest with the modules that are used the most.
That means release often, even release broken. Bugs get found, the critical ones get fixed first.
The coders are constantly refactoring. The design process is to write code, throw away.
Very efficient, producing very good quality code.
Derek
KDE 3.2 was shifted to a focus of taking more time to work on bugs and the release schedule was taken off track until it reached particular levels of bugs. For our module we had low bugs and we got to spend more time working on features. Others may have chosen to take the time to work on features and perhaps even at the expense of bugs. That's because the process sets up to freeze what you can do for the purpose of fixing those bugs.
Bug fixing is a matter involving a lot of factors, but procedure makes more difference than policy. The current system is procedurally very rational. New major point releases end up being incremental with less bugs being able to be introduced. Perfection is a noble aspiration, but often a very irrational goal when placed in context. Theoretical perfection is the extremely small percentage gain from the high percentage effort that insure stagnation, extremely long development cycles, user and develeper frustrations and lo and behold... you get bugs anyway.
We have set our objective to realize an average 10 or less bugs, which has cost us features, and strangely enough obvious bugs occasionally crop up months after a release because testing becomes very difficult. A simplistic approach to clean software is not going to work. Nor is it going to happen without a lot of users being involved running CVS HEAD, which they are attracted to for new features.
Today, I have witnessed elitism among the KDE team. I'm as disgusted as I am disappointed. Because I do not possess proficient coding skills and I do not contributed code directly to the project, I've been labelled as second-class contributor and as such, my suggestions, which another member termed whining, are almost worthless, or carry less weight than that of a KDE coder.
Way to go friends, you definately attrack more enthusiasm with this attitude. May KDE continue to filled with bugs. I'll take my second class contributions (AKA whining) where they are better appreciated and needed. Are you kidding me? It is acceptable for KDE to ship with thousands of bugs?
For my part I don't take user comments serious which don't state "I actually use KDE and find it buggy" but do say "I have looked at Bugzilla statistics and find KDE unreleasable". And I wonder if this is KDE specific because I don't see such statements on gnomedesktop.org while GNOME has a comparable amount of issue reports. Perhaps it is because of the same impression like mine that here more developers participate in the comment section and users think they can change something with constant whining.
I don't care about gnomedesktop.org. If I had issues with gnome, I'd know where to *whine*, thank you. Well since you don't take users comments seriously, why don't you stick to the kde-devel mailing lists for now. I believe dot.kde.org is a forum where kde users are updated on the progress of KDE and share their comments, or whining as some of you put it.
Hello,
for the KDE developers it's the fun that makes them develop KDE. Are you trying to kill the fun for them?
You ideas of imposing policies on developers that the developers don't find themselves necessary is arrogant at least. It can be explained by ignorance only.
In fact some people fix bugs, some create new features and it all works out well. Many new features like kwin rewrite fix very old bugs.
So what's in bugs:
1. Bugs about new features which are obviously not too important anyway.
2. Bugs about khtml. Everybody seems satisfied with the rendering of Konqueror, only few sites don't work. Yet this creates like 1000 bug reports. I don't care. Since when would missing compatiblity to Mozilla and IE bugs be a problem? The standard pages work fairly well already.
3. Bugs about very special situations. How many bugs are about styles that few people use. The default style Keramik works bug free. That's what matters.
4. Bugs about non-completed designs. Some things are still inconsistent because redesigns are pending but not done yet.
5. Bugs that are plain wrong.
The count is big, but I won't even notice many myself ever. Even more are unreported.
What you people don't get is: KDE has a lot more testers now. KDE has a lot more applications and expectations now (like rendering everything perfect in khtml). So more bugs get reported and found because we have a bigger community now.
The bug count will only increase from now on just for this reason.
Stop killing the fun of others that develop KDE.
Yours, Kay
Again
He just said that he doubts that you are qualified enoguh to give an objective and helpful answer about what KDE should focus on in their development process.
Of course there are many ways to contribute to KDE and they are all much appreciated. kde.org/support
Look budy, we all than you for your contributions, it's jsut that you don't know enoguh about how software works and the OSS development process to have a really helpful opinion rather than just wishful thinking. The KDE developers know the issues and problems they know how to adress them adn you're bringing nothing new to the plate with this. Yes, we would all like a less buggy KDE, but few would want KDE to appear to be at a standstill because all developers are fixing bugs and msot developer swill not do this anyway, tehy would make an experiemtnal or cool branch and jsut work on that instead.
As many have explained to you it is virtually impossible to have a bugless KDE. It is just not achievable and many of those bugs are old and don't affect you.
Well, gnomedesktop.org updates their page much more often than the dot, and as such, they get much, much, fewer comments (ten times less?!) on each page.
As such, dot.kde.org articles get many more whining/offtopic/inflamatory/trollish/flamebait comments than a gnomedesktop.org article does.
Not only that, but they use a much more modern system than dot.kde.org uses, that shows IP's if it's not logged in. This probably reduces it too.
(keep in mind that the old gnotices site, before gnomedesktop.org, had it's fair share of whining/offtopic/inflamatory/trollish/flamebait comments ).. but guess what? It was almost EXACTLY like dot.kde.org. It even used the same comments engine.
> And I wonder if this is KDE specific because I don't see such statements on gnomedesktop.org while GNOME has a comparable amount of issue reports.
Just found this interesting comment http://slashdot.org/comments.pl?sid=79139&cid=7003183 talking about the Mozilla/OpenOffice.org/RedHat situation.
"Today, I have witnessed elitism among the KDE team."
Have you? Have KDE-developers responded to you and said something like "STFU n00b!"? I haven't seen anything like that. Sure, few people (me included) have replied to your post, but are those KDE-developers or just casual dot-readers (like me)?
Fact is that your suggestion of "100% bug-free KDE" is not realistic. It cannot be done. Yes, bugs should be killed, and they are. Just in the last seven days, KDE-team has killed 399 bugs.
I just went through some random bug-reports. They were from old version of KDE. Most were from 3.1.x but not from 3.1.4. Some were from KDE 2.x or from CVS-version! Large part of the bug-reports were unconfirmed.
Point is: you look at the number of bugs with horror. But how many of those bugs are REALLY valid? How many of them are from old versions that no-one runs anymore? How many of them are from the bleeding-edge-version that normal users don't run? How many of them are confirmed? How many of them have been fixed with the report being left open?
> or carry less weight than that of a KDE coder.
You're mistaking "coder" for "contributor". And ___of course___ somebody who doesn't contribute in a physical manner (be it doc writing, programming, being an artist, web designer, etc...) to KDE is not going to have as much influence in the future development of KDE as someone else is going to have.
This isn't elitism, it's just how it works. Most KDE contributors are volunteers working on their __free time__. Many are students with large course loads. Many have full time jobs. Some have families to feed and children to take care of. We are humans too, and we are working on this for __fun__.
So, if you tell a set of KDE contributors to stop working on what they want to for a full year, don't expect your comment to be taken very seriously. Many KDE contributors would just stop contributing if they were forced to that. Thankfully, KDE just doesn't work like that.
And also, since you want KDE's bug stats to go down, I suggest testing out older bugs (especially things like khtml), and try to reproduce them if you have a CVS copy of KDE. I went through 30 last week (as many as I had time to do), and I found a few that worked in HEAD and commented as such.
There are already a few people who do this, but there aren't enough. It doesn't need any coding skills, doc-writing skills, artist skills, but is a way you can influence the development of KDE more directly.
Yes you could call it elitism. Those who write the code decide their own priorities. If you can't code, hire someone who can. And they can do your bidding.
Don't like it? Tell me, how else should it be done? The licenses permit forking. Go ahead.
I'm serious. You can suggest. Many who actually contribute code dislike your suggestion. Maybe you should listen carefully to what they say. They are smart people.
And what do you think the developers are doing, except fixing bugs? Two worked for the better part of a year to rewrite a basic module of KDE. Why? To fix bugs. Make it correct.
For your edification. Bug statistics are as most other statistics: useless out of context. Like lines of code by developer. It tells you something, but not much. Same with number of bugs. I will make a prediction that may sound outrageous. There will be more open bugs at the end of this release cycle than at the beginning. It is a matter of the number of users. More users find more bugs. Regular users find small issues that irritate them, and bugs are reported. KDE is getting very good, and will attract a very large user base with this release. High bug numbers represent a large user base. This situation also reveal a flaw in the bug database system.
The basic thing to remember is that software development is a process of the human mind. The fact that computers are involved tends to make us think that is should be logical, deterministic, predictable and all those comforting things. But it ain't. Even one developer. A large project made up of a few hundred contributors, a code repository of over 10gb, as a human endeavor is unimaginable. You are seeing the workings of the human mind in all it's glory and decripitude. I consider it a privilege to watch, let alone have a very small part in it. There are answers to many questions here, including how does one manage a very large software project.
Derek
If you don't want feedback and discussion, then don't make comments. Otherwise if you want to make a comment expect feedback positive or negative.
Not everybody in the world is going to agree with you or think you're a bloody genius. :-)
> Today, I have witnessed elitism among the KDE team.
I think you need to chill out. You posted saying it was a rant and expecting to get flamed. I haven't read them all or who they were from but I think you need to climb down off your cross and be reasonable.
> I'm as disgusted as I am disappointed. Because I do not possess proficient coding skills and I do not contributed code directly to the project,
Really? I didn't have them when I joined the Quanta project to work on the UI specs. I was forced to learn C++, then I sponsored Andras and now I finally am getting fairly good at C++. Look, if you are interested in something then pursue it and stop making excuses. I've had 14 year olds contribute code to the project. How long do you think they have been coding?
> I've been labelled as second-class contributor and as such, my suggestions, which another member termed whining, are almost worthless, or carry less weight than that of a KDE coder.
Well people listen to me, but it's because I'm a project maintainer and I have a history of making good decisions about Quanta. I've gotten a reputation based on my performance. I still do not feel up to technical decisions on a number of things that I look to more experienced developers in the KDE project on before developing an opinion. This is just common sense. KDE is largely a meritocracy where your credibility is based on what you demonstrate. I like this because it doesn't allow for ideas that sound wonderful and noble in theory, but prove disasterous in practice, to harm the project. Where are your credentials? If you have none can you point me to some credible resource, such as a respected developers writings?
You are the one who sets the weight of your suggestions by what you bring forward in demonstration of your ideas.
> Way to go friends, you definately attrack more enthusiasm with this attitude.
To be blunt, I love enthusiasm, but it needs to be directed and coupled with good experience to become leadership. I've had enthusiastic people who could do nothing more than waste my time with one wild idea after another that I could shoot holes in far too easily. I'll tell you something else too... if you have a strong feeling about something and you want to better it then you don't really give a rip about a little constructive rejection. If you could come up with the answer with no experience or knowledge of the process what does that say about the people who have that and the awareness of the problem? They're just stupid? They achieved greatly through stupidity? Possibly you may need to re think your strategy.
I suffered a lot to get to where I am. It was hugely dissapointing when our original team split. I endured a lot that was far less pleasant than anything I've seen here. I didn't even have anyone to suggest what to do to. If you want to make something happen you are going to need a lot more than complaining about others and you're going to need to be willing to back up your ideas with proof and take action.
> I'll take my second class contributions (AKA whining) where they are better appreciated and needed.
And this is going to make me feel good that we could partner and I could depend on you? If you want to whine then by all means do it out of earshot. If you want to accomplish something then you're going to need a little more tenacity and you will need to be reasonable and open to the possibility that the truth may not be so obvious and you could be wrong. If you go through life assuming everyone who disagrees with you is irrational you could be headed for a lot of dissapointment.
> Are you kidding me? It is acceptable for KDE to ship with thousands of bugs?
It's an interesting question considering I've got systems that have had the desktop up for months without a problem and I almost never have a crash even with development software. I've only noticed a few of those bugs. Is it okay to tell me to stop adding features that I really need or maybe I should go work on something else? Who are you again, that you can tell me to do this? Is it okay to stagnate the project and slowly kill it for your ideals? Your credentials in this matter?
Who's kidding who? What are the real world repurcussions? How do you go about enforcement if you can't get consensus? Where is the road map? You can't answer these questions... and if you think that there haven't been a number of people in KDE focusing on clean code and you're the first one to think of it then skip reality and just page up to where the earlier thread is on the same thing.
No bugs is a noble aspiration, but an absolutely disasterous goal.
While I enjoyed reading your lessons of life, and the trials and tribulations you experienced during the development of quanta, a great software by the way, and your capacity as a developer in the KDE team, we both live and lead different lifestyles as well as different commitment capacities.
As much as would wish to squiz everything out of my already tight schedule to contribute code into the KDE project, I just can't at least at the moment. I don't brag about my contributions to this project or any other. I don't like the attention. And as I have stated earlier I'm contributing all I can to the project directly and indirectly at the moment. I don't owe you or anyone else a credential of my contributions to the project or any other OSS project for that matter. It is against my principles and beliefs to brag about them as I don't contribute for popularity, fame or benign exposure.
If you or anyone else feel you need to judge my suggestions based on how much code I contribute to the KDE community, then just do that. I have nothing loose. I have had intelligent discussions with professional software engineers working on interesting commercial projects, and none of them responded in a high ended manner as to suggest I'm not qualified to critize or make suggestions on ways they could improve their projects because I'm not a coder.
You and anyone else are very welcome to critically analyze and attack my
suggestions, but don't attack my person by politely calling stupid, dumb or not qualified in twisted terms. I welcome any criticism to my ideas. With regards to my coding skills, I would just not contribute code to the project until I'm comfortable doing so, that will be sometime in 2006 if I'm disciplined with the goal I've set for myself. :-P I'm very interested in kwin and kdelibs. I've joined the mailing lists and all what not. But I'm discouraged by the elitism I've witnessed here. This has been an eye opener. I don't place coders any higher than users, or maintainers or doc writers or testers or you name any member of the community. I've done all I can to support and promote KDE. I have encourage at least 2 people to contribute code to the community. I'm also learning a programing language just to be able to contribute code to the project. But if this high handedness is prevalent in the community, then I guess I need to stop wasting my time and effort. And perhaps that of yours and others.
Once again, I'm not complaining or whining. Like I said elsewhere I whine and complain by reporting bugs at bugzilla.
I installed 3.1.4 about two weeks ago and I haven't shut it down since. In all this time I have found very few really serious bugs (Konqueror crashing a few times, that's all).
Maybe I'm lucky and I can't say I have really used all apps, but I haven't found any serious problems that afflicts my productivity. I think you demand a bit too much, although I agree that there would be nice with some polish here and there.
(I wish people would have had your demands back when Windows 95 was released. Then we would all be running Linux or OS/2 or something :))
Sorry, I meant 3.1.3
First, I guess that I need to present my credentials:
http://home.earthlink.net/~tyrerj/files/qt-x11-free-3.2.1-PSfontname.pat...
I was told that the bugs I reported were Qt issues, so: I fixed Qt.
With this patch, you can produce PostScript files with the correct font names.
Now, you said that Konqueor only crashed a few times.
I think that in version 3.1.x, that that should be considered a serious bug. Why in version 3.1.4 does Konqueror still crash on me?
We should consider that there are different types of bugs. This is a serious bug -- probably a coding error. There are also bugs which are not serious -- things which could work better but work OK.
I don't agree with everything that: "Mystilleef" said but he makes some good points.
As I see it, it is the presence of serious bugs that we should be concerned with. They don't seem to be getting fixed. New versions are branched off and the bugs remain.
I believe that there is a problem here with corporate culture -- it is the hacker mentality. I see a lot about coders, but where are the software engineers? Does the project have any?
You can all say what you want, but the fact is that THIS is the weakness of OSS development. I will say it again, and many will disagree -- the design is more important than the codding. To say that design is not a physical contribution is nonsense.
Back to the Qt code. What I tried to fix was something that was well codded, but poorly designed (it would NOT work even if perfectly executed). I see several other design problems with: "qpsprinter" which I didn't attempt to fix.
So, the electronic engineer would like to make two points about bugs:
1. Many of them are the result of design issues not codding issues.
2. For the bugs to get fixed, the development paradigm needs to be changed.
We are currently building software the way that Detroit used to build cars.
First we build it, and then we try to fix the defects.
But, they don't build cars that way any more. They now endeavor to build them without defects.
My simple suggestion is that development should be based on the current release.
As it is now, a development branch is created, it has unfixed bugs and it acquires new bugs. Then it is tagged for release and they try to fix some of the bugs.
The result of this paradigm is that 3.2 will probably be more buggy than 2.2.x. And, it will just continue as it does at MicroSoft -- one buggy release after another.
--
JRT
While I appreciate disagreements with my suggestions, which is absolutely welcome, I think it is ignorant and arrogant for anyone to insult my intelligence by telling me I don't know how software works or I don't understand OSS or I'm only qualified to make certain suggestions but aspiring for a bug-free KDE isn't one of them. Enlighten me. Attack my suggestions, not my person. I didn't come out here saying the KDE community (i.e. users, coders, testers, doc writers, sponsors, bug reporters, well wishers, to mention but a few) are all wankers for allowing KDE bugs to skyrocket. That would be trolling, flamebaiting or whining. No, I didn't do that.
I acknowledged right from the begining that KDE is a large project and bugs of this magnitude can be expected. I am not imposing my suggestions over anybody. The *only* reasonable argument to my suggestion is the fact that KDE developers, coders in particular, are at liberty to do as they wish with their code contribution. And I don't disagree with that. However, most of us fail to acknowledge that squashing bugs is a part of the development process. Squashing bugs, doesn't slow down development contrary to popular belief. The KDE development team is small, and at this level the bugs are manageable. I fear for the day when the bug count is so high we can't manage or control them. I don't see how devoting one year to squashing bugs retards the development of KDE. We speak as if squashing bugs is counter productive and not useful while adding features is holier and better.
While squashing bugs is not fun, I think developers should be encouraged to do so. I think if we can devote one year to squashing bugs it will improve the overall quality of KDE and in the future bugs will be more manageable. In this year, developers are at liberty to continue working on their new features and any other thing they consider fun. No developer will be forced to smash bugs against his or her will. Those who wish to will and those who don't wouldn't. And nothing guarantees that all bugs will be eliminated at the end of the period. The objective is just to bring the bug count down to a reasonable or controllable amount and there by improving the quality of KDE.
The Gentoo project has a similar concept called the gentoo bug day (a day in a month devoted to eliminating bugs). And it has been very effective. That's where I stole my idea from. I'm not a genius and I'm not imposing my idea on anyone and neither I'm I being ungrateful nor I'm I whining or trolling. This is a genuine concern and wish for KDE to be the best. I'm also not insulting anyone persons integrity or intelligence or ideas, so be kind enough to reciprocate the gesture. Feel free to disagree with the issue, statements like, "It just won't work", "Stop whining", "You are trolling", "Software always has bugs", "Go hire developers or do it yourself", "Wishful thinking", "Go complain to gnomedesktop.org", "You don't have a Ph.D in computer science and C++, so you don't qualify to make that statement", and so on don't address the issue and as a result don't count. I'll henceforth ignore to such statements.
On a final note, I whine by reporting bugs and nagging developers over at bugzilla and I encourage others to do so, but politely.
Your real stubborn and spin anything we say the other way.
Nobody insulted your intelligence, we only don't think that your more knowledgeable than the KDE developers themselves on how to develop KDE. Of course you can suggest whatever you please, but that doesnt mean that people will agree or follow your suggestions and they honestly have little reason to do so, as you said you are not a developer and are just speculating on this issue. So far in my opinion you have proved this.
The developers have free will and KDE can not tell them "you may only use your free time to squash bugs" this has to be their decision, I'm glad you agree. However, just because they may refuse to fix bugs as many bugs as you want them to does not mean that they don't acknowledge that fixing bugs is a critical part of the project and that they don't do it. Just this week the obviously hard working KDE team has fixed over 385 bugs and also completed 140 wishes.
Nobody ever thought that squashing bugs retards the development process; however, devoting an entire year to squashing bugs is preposterous! Most likely half of KDE developers will lose interest in the project and so no more bugs than usual will be fixed. In addition it would upset the user base of which most will not have been affected by the bugs fixed and feel that KDE is not giving them what they want and improving. Yes, maybe in a good two years we will have a eliminated just about every known bug (I doubt it since many are impossible to fix without adding new features) but we will be so far behind that nobody will care. Just like nobody will want Microsoft paint which lets pretend is a bug free product over CorelDraw 11 which most likely has hundreds of bugs. The same think would happen to KDE, most bugs that affect a lot of users are fixed quickly however the ones that affect 2% of the user base arent fixed as quickly and majority rules. In addition, the libraries and core change so automatically new bugs will be introduced quickly and your bug free product will quickly regress back to a buggy state. Its just not worth it, as long as our libraries are a moving target. What KDE needs is BALACE just like everything in life.
This is a genuine concern and wish for KDE to be the best. I'm also not insulting anyone persons integrity or intelligence or ideas, so be kind enough to reciprocate the gesture. Feel free to disagree with the issue, statements like, "It just won't work", "Stop whining", "You are trolling", "Software always has bugs", "Go hire developers or do it yourself", "Wishful thinking", "Go complain to gnomedesktop.org", "You don't have a Ph.D in computer science and C++, so you don't qualify to make that statement", and so on don't address the issue and as a result don't count. I'll henceforth ignore to such statements.
Here your just spinning again. These statements above are placed out of context, if that were all they said that would be bad, but the people said this and additional paragraphs. In addition you even made up a few such as ", "You don't have a Ph.D in computer science and C++, so you don't qualify to make that statement", and so on don't address the issue and as a result don't count. I'll henceforth ignore to such statements.
Anyway, a Bug Day is a reasonable idea and would be helpful, I have nothing against this and in fact I like it ;) KDE already has similar things such as the Nove Hardy conference but this is more focused on one issue and Im all for it, maybe at the end of every 31 days is a good time
BTW: No I'm nota KDE developer, i only player around with KDE code a bit, but didn't really contribute any useful code.
Thank you I appreciate your input. It is a much better criticism than your earlier responses. And yes, I'm a very stubborn individual, but I'm working on it. ;-) And, yes, I use hyperbole a lot to get my point accross. I play around with KDE code once in a while but I dare not contribute. Well except you are willing make me break your system. ;-)
You don't have to code, tehre are plenty of things you can do otherwise http://www.kde.org/support/ and this is just a small list of things there are tutorials for improving documentation (in the what's this items for example) artwork, creating usability studies, posting news about KDE, submitting bugs, confirming bugs, donating money, translating, spreading the word (when 3.2 is released rather than now, I think that would make a lot better impact) etc. Anyway, i didn't do much for KDE, but considering that a proprietary software product that would equal KDE would retail for at least $30, I have donated $30 to KDE after 3.1 and I will donate at last $30 after each release.
Well I already do most of the things you mentioned. I test betas, report bugs, vote on bugs, I've donated money (I'm not going to mention dollar amounts but I've donate quite a lot to KDE and have forced all members of my family to do the same since they use it too), begged two of my friends, who are great coders, to help the project, I spread the word, use KDE ( and love it) etc. That is why I was a little disgusted by some of the comments made by other individuals above. Fine the only thing I don't do is code, at the moment ( I plan to in the future) but that doesn't mean I can't critize, offer ideas, or suggestions, or advice.
I also already mentioned right from the begining that at the moment, I can't do more than I'm doing presently. If I could I would but I can't. Since the documentation team is a little short staffed, I was thinking contributing there too. But at the moment I'm angry and I'm just going to stay off any KDE involvement till I cool off and devote that time concentrating on my graduation coming up soon. Maybe KDE-3.2 will renew my interest. :-)