In this week's CVS digest:
Quanta's visual editor makes progress.
KHTML gets text selection optimizations and immediate repaint from Safari.
Kontact, KMail and
KAddressBook get work on settings, time cards, drag and drop. Plus many bug fixes.
Dot Categories:
Comments
>Hi,
Hello
>you are still free to use more professional products
What make's you think KDE isn't professional?
>When did you e.g. last time had a backport for an other desktop you used?
When did KDE start using other desktop policies?
>I mean some of those rich companies must be very eager to listen to you.
I doubt they are.
>No?!
Yes, they will not.
>Now what... just because those people try to make something fun to use means they have to be your slaves?
First of all, I don't believe I ever called anyone slaves. It is repugnant even concieve that thought. Secondly, if I *freely*, *willingly*, *without any compulsion* submit my package for public consumption, I think it is also my responsibility to cater for it, yes, that includes fixing bugs that may arise from public usage and public testing.
The concept is not as controversial as you make it sound. If my orientation was successfully, isn't that one of the benefits of open source? Thirdly, everyone stands to benefit from such as culture, you, I, the developers etc. I'm not being selfish, I wish the best for the project.
Hi,
> The concept is not as controversial as you make it sound. If my orientation was successfully, isn't that one of the benefits of open source? Thirdly, everyone stands to benefit from such as culture, you, I, the developers etc. I'm not being selfish, I wish the best for the project.
I am not controversial about what you think you would do. See the many "I, my" in your statement.
I see need to defend people's right to do whatever is fun for _them_. And not come across people who play on their honour or something. You make it look like if they don't jump to solve your problems with their software, that would be bad.
They do indeed care and solve problems with KDE. If you are unable to help yourself, it may take some time before you get a new release with the fix by somebody else. So what?
Did you ever think why you get the source?
That said, KDE is indeed professional. I wanted to point out that their approach is actually giving you the best support of all desktops in the market. I don't think that KDE has to backport bug fixes for users more than others do that have multibillion dollar sales income from their desktop version. I mean, do you recognize that elsewhere the priviledge to _report_ a bug is something you cannot afford. Not talking of fixes in the next version you of course have to buy...
But as you say, you already know that.
Now listen, you get the source, because that way you can help yourself. Or you can help somebody who is capable of helping you in return.
Whining on what you would do doesn't help anybody. Do it. Become a developer of KDE and deliver the backports. Or pay somebody to. Or stop killing people's fun about developing the latest and greatest KDE.
Yours, Kay
The conversation is not getting anywhere. Feel free to believe whatever you think I'm making it seem. One thing remains the same. Bugs open security holes, vulnerability and exploits. The bug count in KDE is rising. I believe we need to curb via policies. If we don't, it will get out of proportion. KDE is not all about fun. It is about responsibility, working together as team, realising our mistakes and accepting criticisms and moving forward to correct them.
You can call my suggestions whining, bitching and moaning. I this point I really don't give a crap. Let's work together to fix it, or lets sit here arguing about the human rights of developers.
Yeah, let's create a policy which forbids to commit security holes, vulnerabilities, exploits and bugs to KDE CVS!
"Bugs open security holes, vulnerability and exploits. The bug count in KDE is rising."
The reason bug-count rises is because lots and lots of users report bugs. The number of users keep on going up, and that drives the number of bug-reports up. But there would be bugs in the software whether they are reported or not.
Of course bugs are a problem. But the number of bug-reports is NOT the problem, quite the contrary! your problem seems to be the number of bug-reports, not the bugs themselves.
It seems to me that solution to your "problem" is that we prevent people from reporting bugs, and that would cause the number of reported bugs to drop to zero in a short while. Problem solved!
Pardon my ignorance, aren't bug reports a fair indication of existing bugs? So lets go by example and assume they aren't. What exactly is your accurate criteria of calculation the actual number of open bugs in this project?
If KDE had no users there would not be any bug-reports. If there are lots and lots of users, there will be lots and lots of bug-reports. That is a fact. And your obsession seems to be about the number of open bugs in bugs.kde.org.
And, like I have repeatadly said (in vain it seems): Many of the bugs in KDE don't matter, they are from old versions, from CVS or beta-versions, unconfirmed, from broken packages etc. etc. Clean those out and you get ALOT less bugs. And I heard that Mozilla has something like 40.000 bugs. Suddenly KDE seems quite bug-free to me!
Compare the bug numbers for kexi and konqueror.
which has more bugs?
I predict the bug numbers will be considerably higher the closer we are to release. In indirect proportion to the number of users that find the software useful. This is a limitation and problem with the bug reporting system, rather than any indication of stability of the software.
If you want something to do, I suggest you go through the 4000 or so open bug reports and figure out what they are, whether they are fixed already, are they duplicates of others. Try duplicating the problem on your machine. Maybe try to figure out what is the cause of the problem.
After doing this for a few weeks you will grow in respect of the developers that have been doing this very for years.
There isn't any nice easy answer except rolling up your sleeves and getting to work. Those doing the work find it very demoralizing listening to the complaints from the sidelines. If you find an unpleasant reaction to your comments, take it as an indication of the effect you are having on the developers.
Derek
> Some developers are responsible enough to fix the bugs. Others just ask for a backtrace and tell you "it doesn't happen here on KDE-CVS". Fix!. Forget it. You either need to use KDE-CVS, bear with the bug or use the next major release of KDE, 6 months later or so.
The thing is that most developers just don't have the time or energy to have 3.1.x installed. So if it works in kde-cvs, it must have been fixed at some point between 3.1.x and kde-cvs. This is how it's always worked so far. I'm sorry, but for a mostly volunteer organization, we have limited resources.
> The question is why release your work for public consumption if you are not willing to be responsible for it, maintan it, or you don't care for the productivity of the users who are using and testing it?
Many developers are working on KDE just for fun. Don't you have a hobby of some kind? For many KDE developers/contributors/doc authors/artists/translators, it's just a hobby, nothing more :-)
>>>The question is why release your work for public consumption if you are not willing to be responsible for it, maintan it, or you don't care for the productivity of the users who are using and testing it?<<<
The KDE-3.0 series had 6 minor (bugfix) releases.
The KDE-3.1 series has had 4 minor releases, so far.
How does this fit into your argument?
People responded to your thread last time and had more than a dozen reasons that showed what was wrong with your quixotic approach and suggestions of a "100% bug free" KDE. From your comments it was clear you did not understand the way software development works, in OSS or in software development houses.
KDE developers are not feature centric all the time, it depends on teh rlease schedule and their will. Right now there are suually 3-4 times as many bugs fixed than the number of feature enchancements. In addition, many feature enchancements are necessary to fix a lot fo bugs often. You can't constantly patch something forever, there comes a point where that patched up thing isn't capapble of handling an more due to its architecture.
KDE developers tend to support old KDE releases for about a year, for 1.x releases and about 2-3 years for x.0 releases since the following versions like 1.x are binary compatible. This is more than many companies spend supporting a product. KDE developers are very responsible for their code and maintain it.
Its true that KDE developers don't backport bugs that aren't critical to an old version of KDE. It is no fun, often it is not possible and if the bug is already fixed in CVS you should just upgrade to the next version of KDE instead of waiting for the issue to get backported. Don't you see what an incredbile wasted effort it is tring to backport all the bugfixes from CVS not only is it not possible for a large number of bgus, it is also a dupicated effort unless the bgus are critical.
"Oh, just watch the flood of responsive that follow this. They'll all be in the form of "put up or shut up", "hire a development team", "they work for free", "you don't contribute so keep quiet", "you don't know how open source works", etc. Have I missed any?"
Yes, when you make unrealistic, unpproductive suggestiosn and you clearly ar ejsut clueless adn talking idealistically without knowing how the process works or having experience in the software field you shouldn't be suprised by these responses. KDE developers work for free, and I would like to see how you react when someoen constantly bugs you about how to spend your free time and in some way suggesting that you are responsible for maintaining stuff you do in your free time. If I build a sand castle in my free time, I don't expec tor want to maintain it or add enchancements to it if I don't want to and you know what telling me what is reponsible for me to do or what I should do with it is plain ignorant.
Suggestions are always welcome, but when tehse suggestions turn into demands and personal attacks that's another matter. Your suggestiosn are not generally constructive or are just far too unrealistic and clueless for anyone to take you seriously. Yes, you don't know how opensource works and these kind of demands will not be met, until you chose to do so.
Don't forge tot read these all over again: http://dot.kde.org/1063743715/1063799495/ it is clear you failed to udnerstand why people reacted the way they did and why you received the responses you did. I am serious study these carefully, until you understand what people are saying.
Yeah, I predicted your type in my last paragraph. Might I suggest you have a look at the Linux project. Read the mailing list, kernel trap and kernelnewbies. Also observe how they manage bugs, fix and back port bugs. When you are done return here and change the topic to " Are you cluesome?"
Perhaps, then, you might learn a thing or two about how open source should work. It's simple, there are feature releases, what KDE-3.2 is supposed to be, and there are bug and security fixes, what KDE-3.1.* is supposed be. But of course, I'm clueless. And I'm brain farting at the moment. You are making the most sense.
If you can't stand the process being criticized just don't reply.
I am familiar with te way the kernel development works and yes you are cluesome, but not in the sense that you sue it. You jsut have a lot of cluses that you are very much wrong, but I guess it's not enough for 2 dozen people and a few KDE develoeprs to tell you why.
The kernel is very different from KDE, unlike KDE a new kernel takes almost 3 years to release, a new version of KDE is released aproximately every 6 months. Upgrading the kernel is also a much more complicated process than upgrading KDE and can break the entire system and cause more incompatibilities than you can imagine. The kernel is the heart of linux (actually it is linux, but some people reffer to the entire Linux suite of applications when they say Linux) it is much more critical that older versions of the kernel have lots of critical fixes backported than it is for KDE.
In addition, many more developers are paid to work on the kernel than KDE, so they can afford to do this. KDE is a far smaller project.
In any case the kernel is not even close to what you wanted KDE to be in your quest to be controversial. it is nowhere near "bugless".
If you take into account the frequency of kernel releases and the frequency of KDE rleases, you will realize that the number of bugfixes backported to an older version of the kernel in comparrison to how many bugfixes were actually backported to an older version of KDE are about proportional when you take into account the total number of bugs fixed in the development versions of KDE and the kernel. Therefore, your comparrison does not stand.
In addition, the kernel is a separate project from KDE, apples and oranges, if you want to compare something compare it with GNOME. But any comparrison will not be accurate since not all OSS projects are the same and people definitely aren't the same.
"But of course, I'm clueless. And I'm brain farting at the moment. You are making the most sense."
When your right, your right. In your post you failed to adress anything I said in my previous post.
"If you can't stand the process being criticized just don't reply."
what's taht supposed to mean. Why would you think I havve anything against you trying your best to criticize me?
There you go again. You just won't stop would you. First I'm clueless about OSS development, and now I'm cluesome. Take a stand pal. And will stop mixing my issues "Bugless by KDE-4" with that of the original poster. They are two different issues. Reread them if you wish. With regards, to Linux project, my suggestion is exactly as they practice. If a developer doesn't maintain a package, doesn't fix bugs, or something breaks due to bugs, the developers work is thrown out of Linus' branch. Things have even gotten more strick ever since the vm issue in 2.4.
People are going to be using 3.1.* series for a good while. It is pointless fixing bugs in KDE-CVS without backporting to 3.1.* series. KDE-CVS is for features, development and so on. KDE-3.1.* series is for fixes and security pacthes. So why fix bugs in CVS when the people who really need them are using KDE-3.1.*. That is what the original poster is trying to get accross. This is totally different from "Bugless by KDE-4" which I still vehemently standby. I'm I making sense now? Or I'm a I still clueless? It's like fixing kerne-2.4.* bugs in kernel-2.6-test6. It doesn't make sense.
And for the last time, developers can do as they wish. I don't care. I'm not forcing them to code. I don't command them to code for me. They are doing it out of their freewill. And I appreciate that. What I'm suggesting is to the KDE community as a whole not a group of people. You have two choices, a high quality KDE with few bugs, or a bleeding edge experimental project with over 5000 bugs. Even though KDE is a unique OSS project different from GNOME or XFCE or Linux, clearly it is far from a perfect project. We learn a lot from other projects, OSS or commercial. The bugs are still manageable now. What happens when they explode out of control and their is so little developers to deal with them? Yeah, that's what's going to happen if think a project as successful as this is all about fun.
> fixing bugs in KDE-CVS without backporting to 3.1.* series. KDE-CVS is for features, development and so on
most can't.
> It's like fixing kerne-2.4.* bugs in kernel-2.6-test6. It doesn't make sense.
read what you said above.
> a high quality KDE with few bugs, or a bleeding edge experimental project with over 5000 bugs
there you go with bug count statistics again. there is simply *no way* that a project as big as KDE can't have as many bugs as it has. GNOME has an equivalent amount. Mozilla and OpenOffice probably have more since their code size is bigger than all of KDE's. The Linux Kernel probably does too. linux 2.6.x will probably have a much larger bug count than 2.4.x since it is about 30% in LOC.
"You have two choices, a high quality KDE with few bugs, or a bleeding edge experimental project with over 5000 bugs. "
Like I said, large part of those bugs don matter. They are either obsolete (from KDE2 or even earlier), unconfirmed, from CVS or beta-versions (where things are bound to be buggy) etc. etc. But hey, we do have a solution for "100% bug-free KDE"! We just have to stop people from reporting new bugs! In the last 14 days the developers closed over 800 bugs, while over 600 new bugs were reported. If we stopped people from reporting new bugs, I think it would take couple of months for bugs.kde.org to show that KDE has zero bugs left. Then you would be happy since KDE would be "100% bug-free".
What was that you said? That would acutally make KDE worse then before since people would not report new bugs? Oh.... Well, that would not work now would it?
the "problem" of KDE is that it has too many users that do their duty and report bugs. Those bug-reports inflate the number of bugs.
We do not have the "two choices" you suggested. We have two other choices: Stagnating but relatively bug-free KDE, or hi-functionality KDE with advanced features, excellent usability, good performance and a bit more bugs. I bet users would prefer the latter.
>>Also observe how they manage bugs, fix and back port bugs. When you are done return here and change the topic to " Are you cluesome?"<<
But also notice this important property of the kernel: if there is no one who wants to maintain and fix a old kernel series, it dies. If a driver or architecture has no maintainer anymore, it will be removed. It is all about people who are willing to do the work (or fund it). Linus Torvalds calls it directed evolution. KDE is much like the kernel in that aspect, the main difference is that there are no forks but branches. Nobody prevents anybody from fixing bugs in existing branches. Nor should anybody prevent anybody from adding features to future branches. People naturally do what they need most. KDE is self-regulated, because every change has a cost and people will carefully spend their time/money.
The direction that KDE takes is the direction of those who pay for it - with time or money. In that aspect KDE is not different from any proprietary licensed, off-the-shelf product. It's all about the customers, and they have different needs and wishes. Some of them may share your view (and thus invest in the same development), others do not. The influence of an individual or group is proportional to the amount of contributions.
But actually it does not matter for KDE as long as they pay and thus improve KDE.
> Yeah, I predicted your type in my last paragraph. Might I suggest you have a look at the Linux project. Read the mailing list, kernel trap and kernelnewbies.
There are *way* more commercial contributors to the linux kernel, who are PAID to do some of the grunt work that most KDE developers wouldn't do just because it's not fun (and a lot of work)
Well, since you obviously hate KDE so much (since KDE is "so full of bugs and developers are unwilling to fix them"), then why don't you use some other desktop then? Surely there are some desktops there that comply with your "100% bug-free" ideals? No? They ALL have lots and lots of bugs? Well, that's what I thought....
Bugs in KDE are not that bad. I mean, take a look at them. Some of them are simply things that "work, but they could work a bit better". Or they are reports about obsolete versions (KDE2 anyone?). Or they are from CVS. Or they are duplicates. Or they are unconfirmed.
Oh in case you didn't notice, the KDE-developers have closed ALOT of bugs in the last few days: "629 bugs opened, 818 bugs closed in the last 14 days"
If I hated KDE so much do you think I'd be wasting my time here willing to take flames for making KDE better?
It would be very nice, if you, after a lot of bragging, went ahead and backported some "simple" bugs. If you tried that, you would note, that backporting is very hard and very much likely to introduce new bugs. Noone wants new (possibly more severe) bugs in a stable branch. Thus only critical and trivial bugs are fixed in the _STABLE_ branch.
If you come across a critical or particularly annoying bug, it will in all likelihood be fixed in the stable branch as well.
Just read your article at OSNEWs.com, it's pretty good except some spelling and gramatical errors such as using where and were.
I agree completely with "I'd like to contribute but to this project but it doesn't look professional. No Documentation"
However, your other points, umm... let's just say that the voice interface isn't exactly very good usabiltiy wise or productivity wise. and you have to understand that simplicity and very few features are a bad way to design softare. It's as if instead of cleaning your house you just destroy all the rooms that are messy, yeh you have a clean house, but would you want to do that?
Anyway, some features do need to be removed completely or at least reorganize dina lto of sfotware projects I know, these feautres jsut get in the way, but most are useful.
Now the other point you made "The "Who cares, its free" Attitude" is also clearly wrong.
This isn't proprietary software, you release half-baked projects in OSS so that many developers can help you release a truly good version fo your software. This is what version numbers are for. responsible developers mark these as pre 1.0 and clearly say they are not ready for primetime.
Also, while nobody is chasing OSS developers deadlines in thsi market odn't come from your boss, but rather from your competition. I'm afraid, that you can't wait forever making your little project perfect, because by that time ther will be a clear market leader which has gathered so much momentum and now includes so many more features than you had planned that its just not worthwile. OSS develoeprs might also be discouraged seeing taht the proprietary alternative is soo much better and that catching up is virtually impossible. OSS projects have as much pressure for release as proprietary IMo.
Also, OSS does not copy MS or other companies excpet when tehy have come wih a good solution, for example the taskbar in windows and windows are very good and not copying these would be stupid. You also need to make the 98% of people who don't use Linux feel at home and not introduce them to something completely different, at least not until linux has at least 10% f the market.
BTW: I'm rooting for mid 2005 as the date Linux will be ready for primetime and I mean really really ready. Too bad that's when Longhorn comes!
For some odd reasons I've been unable to get connected to osnews. I also apologize for the horrible grammatical blunders. I must have sent the wrong copy of the article to osnews. I could have sworn I ran that thing through three different spell checkers including Microsoft Word, eww did I just say that. :-) As my final pathetic excuse, English is my third language. :-) I admit that no excuse for being sloppy. In the future I'll be more vigilant.
Overall, I'm glad you enjoyed the article, save the spelling errors and poor quality, and your criticism is noted and welcome. I still think KDE should have bug paranoia culture though, that won't change. :-P
I disagree, that article just writes large his complete refusal to understand a FOSS project like KDE. We are not developing this for people who need their hand held to write an email. Period. I think all of us would agree that we want to develop a system that *we* would like to use, and there's really nothing wrong with that.
"but..but...what about Joe User?! He can't be expected to figure out a hugely complex app like KMail! You have to *know* the email address you want to send to! That's too complicated!!" Well, in the first place, I think you *hugely* underestimate the abilities of an "average" user. I've never heard of anyone giving up KDE because they couldn't figure out how to do their work. You are really exaggerating this. Secondly, I think KDE's apps are not less usable than the equivalent apps on other systems, and in many cases they are more useable. Your email example goes way too far, beyond usability and into annoyingness. You are basically proposing "Clippy for KMail" UGH, no thanks!
Anyway, choice exists, and this is good. If anyone finds KDE to be the dizzying array of incomprehensible junk that you portray, then other projects can probably fit his needs better. Actually, for such a person I'd recommend no computer at all. They are inherently complex devices.
"You'll never penetrate the market then!" *Who Cares??* I don't think most of us are too concerned about "taking over the world", we just want to make great software.
Plus, I find some of your comments about how all FOSS software is poorly designed and very poorly documented highly insulting. I happen to think my app (KStars) has one of the simplest, most intuitive interfaces for a program of its kind, and the Handbook is quite extensive. With less effort than it takes to write your rants, you could get in here and help us improve things where you see problems. You don't need to know C++ to rewrite a Handbook chapter or redesign a UI file. Put up, or shut up. Or both! :)
Sir, the article wasn't on KDE usability, the KDE development process or KDE in general. I don't remember mentioning KDE or Kmail or any other Kapplication once in the article. My illustration on the "intelligent mail software application" was a hypothetical example demonstrated how an application could impress/attract users who see no advantages in using software applications running on Linux over what they are currently familiar with. I suggest you read the article again without the bias or vehemence you have against me.
While Kstar might be well documented there still exist a horde of open source applications, even in KDE, that aren't and will most likely never be documented. And I have participated in the documentation of several projects. I plan to participate in some documentation in KDE when I'm less exasperated and after my graduation. It's unfortunate you find a fact insulting. The truth hurts, deal with it. :-)
I didn't think it was so nice. I'll admit there were good points, but they were intermixed with severe problems and I can already predict that I'll be labeled a "bad developer" in spite of the fact that my project has documentation and an excellent record squishing bugs. I'm okay with that though because this guy has got a growing attitude of contentiousness and is more and more ready to fling out generalities followed by confrontational statements. I think it is important to put things in perspective...
From the article "Mystilleef is a computer enthusiast who believes computers are hard to use and software is diminishing in quality. He will be graduating from university this year. His field of specialization is Accounting and Finance with a minor in Computer Science and Economics. Among other things, Mystilleef enjoys arguing, reading, playing video games and outdoor sports." So he's ready to go out into the big bad world and make his mark, and he is specializing in accounting. My God! No wonder he is taking the position KDE must be 100% bug free. Bugzilla is the unimpeachable red ink on a balance sheet where the unquantifiable profit column must be world domination. If I thought like an accountant it would make sense. Then again I would have been too risk averse to start a business. I note he enjoys argueing, but no indication if that is debate, or just postulating interspersed with jibes. It does look like pushing people's buttons must be more entertaining than diplomacy.
Quoting again... "Don't release half-baked attempts at hacking to the public. If your project isn't complete fundamentally, if it still contains bugs you don't know how to solve yet, if it is not properly documented, if you have no intentions to complete your project or support in the near future, just be responsible and don't release it to the public until you are sure of what you are doing. I know several people who just got tired of packages breaking their system, and went back to safer Mac or Windows."
I think we can resolve this rather quickly. Step back in time and start Linux and KDE this way. Both projects celebrate the initial emails where a small amount of code had been started and releasing it attracted other developers. Mystilleef's position is as appalling as any I can think of. Had this position been taken by pioneers in OSS it would be dead today. Period! There is no way the lone individuals could have taken the projects to anywhere near where they are today, let alone a remotely usable state, by themselves. In the case of KDE, it was the catalyst for Gnome. So you could be running CDE on BSD. In open source when someone has an idea we say "show me the code" and projects advance on their relative merit. Now we are treated to "don't show the code" and I guess the only leadership we will have is the loudest voice not showing code. Oh goody!
There are few things more offensive than someone serving up theoretical nonsense as if it was manna from on high. I prefer the advice of Eric Raymond, "Release early and release often". Here's my advice. Go out in the real world, get a job, tell your employer he is all screwed up and you have a better way, get kicked in the teeth... repeat as needed until the concepts of practical applied knowledge and diplomacy take hold and foster some humility... then check back.
About this author... Eric Laffoon first programmed in fortran in 1976, has been self employed for the last 14 years and has been leading the Quanta Plus project for the last several years. He also believes age and guile beat youth and exhuberance every time. ;-)
>I didn't think it was so nice.
Why I'm I not surprised.
>I'll admit there were good points, but they were intermixed with severe problems and I can already predict that I'll be labeled a "bad developer" in spite of the fact that my project has documentation and an excellent record squishing bugs.
Based on my criteria, I really can't tell what kind of developer you are. Quanta, however, happens to be one of the exemplary OSS projects I admire a lot. Excellent documentation and bugs, well they are managed intelligently.
>I'm okay with that though because this guy has got a growing attitude of contentiousness and is more and more ready to fling out generalities followed by confrontational statements. I think it is important to put things in perspective...
Attack the issue, not the author. It is difficult to speak about open source software without generalising. I intentionally avoided mentioning any particularly open source software project to be as objective as possible. The article wasn't meant to be confrontational. It was meant to identify a few of the weaknesses in OSS as well as enumerate avenues to attract people to OSS, if in fact it is our objective to do so. I didn't write the article to please people. I wrote the article based on my observation and participation in several projects. Undoubtedly, the truth offends.
>So he's ready to go out into the big bad world and make his mark, and he is specializing in accounting. My God! No wonder he is taking the position KDE must be 100% bug free. Bugzilla is the unimpeachable red ink on a balance sheet where the unquantifiable profit column must be world domination. If I thought like an accountant it would make sense. Then again I would have been too risk averse to start a business. I note he enjoys argueing, but no indication if that is debate, or just postulating interspersed with jibes. It does look like pushing people's buttons must be more entertaining than diplomacy.
Contrary to your misconception, my comment regarding the issue "Bugless by KDE-4.0.0" wasn't stated to make KDE bugless, it was stated to encourage a culture or sub-project the reduces the astounding number of confirmed bugs to a manageable amount. Look into "Gentoo Bugs Day" for I where I stole this idea from.
Your stereotype about accountants is insulting, ignorant and unfounded. Why you had to attack my image dumbfounds me beyond belief. I didn't expect this from a respected member of the KDE community. Because of my utmost respect for you, I'll take it in good faith and in jest. It's okay for friends to make fun of each other.
>"I think we can resolve this rather quickly. Step back in time and start Linux and KDE this way. Both projects celebrate the initial emails where a small amount of code had been started and releasing it attracted other developers. Mystilleef's position is as appalling as any I can think of. Had this position been taken by pioneers in OSS it would be dead today. Period!"
The key word in my statement is "complete fundamentally". Now that I've said that, go back and read the article, this time with an open mind and without bias against the author. XFCE is a good example of a project that comes to mind. The rewrite, XFCE4 had been in the lab for so many years and when it was released to the general public, it was a success. Going by your argument, XFCE4 should be dead. You mistake release for public consumption with release for public development. I stand by the statement and I don't see anything appalling about it. I only think it will make open source software better and more reliable contrary to it's already existing reputation.
>There are few things more offensive than someone serving up theoretical nonsense as if it was manna from on high. I prefer the advice of Eric Raymond, "Release early and release often". Here's my advice. Go out in the real world, get a job, tell your employer he is all screwed up and you have a better way, get kicked in the teeth... repeat as needed until the concepts of practical applied knowledge and diplomacy take hold and foster some humility... then check back.
I don't blame your attitude towards my article. I imagined it will offend people like you, the older generation. For the likes of you OSS is perfect, it couldn't and wouldn't get any better than this. And change is definately not condoned, nothing beats the traditional way of doing things, the way things are done today. I have had several jobs. Last summer I had an internsip at a software firm. In school, I work for the computing services as an administrator assistant. I'm also a resident advisor. But I'll take your advice, and report back to you on it. :-)
So let's recap why you think my article sucks in no particular order,
1) The author is contentious.
2) The author is training to be an accountant. And accountants are anal
3) The author discourages OSS projects not to release their works to the public until it is complete and properly documented.
4) The author claims he enjoys arguing, so the article is written in vain.
5) The author is not pragmatic because he isn't as experienced as I am in coding and leading OSS.
I'll concede partially to the last point. Although, I haven't lead any OSS project, I have participated in several. In general, I'm dissappointed by your response. It is hardly contructive, riddled in personal attack and other immature nuances, and hardly touches open serious issues plaguing OSS as discussed in my article. When I saw your name in the reply link, I jumped in excitment at the link thinking I'd learn a thing or two from a respected OSS developer. Now, I wish you never even responded. Have a great day Mr Lafoon, I hope we meet under more hospitable circumstances in the future.
"It is silly to mistaken knowledge for wisdom, one make you earn a living, the other makes you live a life"
I apologize for misspelling your name in last response Mr Eric Laffoon.
"Excellent documentation and bugs"
Indeed, Qunata has very good documentation, but I never actually rate bugs on how cool they are...
"Contrary to your misconception, my comment regarding the issue "Bugless by KDE-4.0.0" wasn't stated to make KDE bugless, it was stated to encourage a culture or sub-project the reduces the astounding number of confirmed bugs to a manageable amount. Look into "Gentoo Bugs Day" for I where I stole this idea from."
Well, if that was your intention why did you have to say something so unrealistic adn flawed, nto that it couldn't happen in 10 years hypothetically, but because no develoeprs would work on KDE anymore due to their boredom, GNOME would also lead even tough it might be buggier, most bugs do not affect the user and so the user would choose GNOME over KDE because it would visibly evolve and become easier, faster, and richer in features. by the time KDE is bugless the rules of UI design and what software is designed to do would be totally different. These are jsut some flaws with this idea.
If your goal was to motivate KDE developers to fix bugs, you should not have stated an unattianable goal, rather something that KDE developers can actually reach. People lose hope when tehy are working towards a goal they can not reach> Even the galapagos turtle didn't walk anymore once it realized that it was acting as a transportation tool and that the apple on the stick would never be caught.
"The key word in my statement is "complete fundamentally". Now that I've said that, go back and read the article, this time with an open mind and without bias against the author. XFCE is a good example of a project that comes to mind. The rewrite, XFCE4 had been in the lab for so many years and when it was released to the general public, it was a success. Going by your argument, XFCE4 should be dead. You mistake release for public consumption with release for public development. I stand by the statement and I don't see anything appalling about it. I only think it will make open source software better and more reliable contrary to it's already existing reputation."
You do realize that from your aritcle the idea people get is that you should silently work on your project without tellinga nyone anything about it and not release till its very good. People would not think that you mean releases for the users not the developers. This si already done, through release numbering, rarely do I see an OSS project which is 1.0+ and really sucks.
"I don't blame your attitude towards my article. I imagined it will offend people like you, the older generation. For the likes of you OSS is perfect, it couldn't and wouldn't get any better than this. And change is definately not condoned, nothing beats the traditional way of doing things, the way things are done today. I have had several jobs. Last summer I had an internsip at a software firm. In school, I work for the computing services as an administrator assistant. I'm also a resident advisor. But I'll take your advice, and report back to you on it. :-)"
Now your stereotyping too as you have in toehr aprts of your post. I happen to agree with your point on documentatin but generally disagree with the rest and I am just 16, does that mean I'm part of the old generation too.
Accept that it is nto always that people don't understand your opinion or are too scared of change, but rather jsut plain disagre with your ideas and for good reasons.
I doubt that almsot everyone posting on the dot is old and fails to understand your points. Maybe it's time for you to rething and reread what we write too. You are just too radical in your statements as was your "bugless KDE statement" msot people are far more moderate, while they tend to agree on the general issue. I for example agree that KDE's number of bugs should be reduced to under 2,000 and it is being reduced, but I don't think less than 1,000 bugs is practial.
"I don't blame your attitude towards my article. I imagined it will offend people like you, the older generation."
Does that mean that you are 12 years old? I for one am 26 years old, am I "old"?
Conversations are best held between people with reasonable viewpoints. Without express knowledge it may be difficult to determine what is reasonable. Many people are often surprised at the statistical level of failure inherent to the most successful performers in any endeavor. In most endeavors the only way to have a perfect performance is to succeed on a small effort and never try again. I say this because you had previously suggested KDE should be bug free. This will happen with the 100% efficient internal combustion motor. Be sure to file a bug report for heat loss and inertial loss at the top and the bottom of each piston stroke. The only way to have bug free code is never release it.
> It's a futile attempt trying to encourage most KDE developers to close bugs.
This is not a reasonable statement. How many developers have indicated to you they will not close bugs, or are you just encouraging deficient? At least you are right up front with your hostility. I'll give you that.
> Or trying to encourage a development process that isn't "entirely feature centric".
Again I say, your credentials please? If you had to walk through a minefield would you want a guide who said "I've walked through this and know the way" or one who said "I haven't got any experience with minefields but I think I know a better way than the guy with experience"? Given the possibillity for disaster I like experienced leadership.
> You'd be dissappointed and flamed to oblivion.
You're still here. Maybe there's hope for you, if you lose that chip on your shoulder.
> Only some weeks ago I reported a bug. The response I got was "It doesn't happen here on KDE-CVS".
Do you know what this means?! It means it is fixed!!! You should be jumping up and down for joy. Of course it could still be a configuration glitch from your distro and it is unfortunate that the developers can't come over and install the fixed version. Hey, grab a clue... If it does not manifest it's self to a developer it CANNOT be fixed. You can't fix what's not broken... and if you leave the bug report there then you will incur the wrath of these people who complain how many bugs are in KDE. Do you know how annoying that can be? We don't want to upset them, do we?
> Yeah, I guess if I was using KDE-CVS I wouldn't have reported the bug.
No. You would have reported a number of other bugs because this is where developers work and it is considered unstable. That's because they are also completing requested features. Guess what. If they stopped the features, fixed the bugs and back ported them, then built the features, then debugged them... they would arrive at the same place. The only difference would be that they would get there much later... AND... there would probably be more bugs because each step touching something and changing it introduces the possibility of a bug. So sheer statistical probabllity, something you don't have to be a programmer to understand, indicates the current flawed process is superior to your proposed much more flawed process.
> Some developers are responsible enough to fix the bugs. Others just ask for a backtrace and tell you "it doesn't happen here on KDE-CVS". Fix!. Forget it. You either need to use KDE-CVS, bear with the bug or use the next major release of KDE, 6 months later or so.
If anything else you said indicated you were reasonable this might look like an issue. However while some bug fixes can be back ported to the prior release (assuming the developer has multiple releases set up on their system which is not always easy to do) others are just impossible. We have lots of stuff going into 3.2 that can be run on 3.1 if you run Quanta from CVS. But don't expect to see the visual page layout... because it requires kdelibs from CVS.
So there could be a little bug in an application that you want fixed that you would have to upgrade Qt and half of KDE to fix, and after that the other half of KDE won't run. So the only options are run CVS, wait for the release or have the developer abandon their current release work and fork KDE rebuilding a mountain of code themselves or possibly back porting everything from Qt on up. The problem is, that can't be done faster than the next release.
There seem to be a few guys who are so incredibly unaware of what is involved in the process, and seemingly unwilling to listen to any reasonable explanation, that they feel the only thing to do is attack the character of those people who are failing to give them what they want fast enough. Developers are not always articulate enough and rarely have the time to spell out for you why reality prevents you from having your instant gratification. Of course once you start suggesting flaws in their character prevent them from circumventing known reality you are a lot less likely to get a response you will enjoy.
Get a clue. Sometimes instant gratification is possible, other times it is not and sometimes what is possible is so horribly inadvisable and impractical it is better to think of it as impossible. There are some people I wish would try developing, not because I want to develop with them, but because I'd like them to begin to understand when they are being unreasonable. If you can't be reasoned with what difference does any explanation make?
I just don't have time for people with "can't be done", "never be done", impossible to be done" mantra. If I listened to people like that, I wouldn't be where I am today.
He's right you know, even relatively simple programs have dozens of bugs which are discovered and the ones that are discovered are at least just as many.
Sorry, we're only human. Sometimes impossible and can't be done are appropriate and this is one fo thsoe cases. By this I don't mean that it is entirely out of the question, but that it would really never happen, nobody would spend 10+ yeas jsut to perfect a piece of software to the point of which the developer feels that tehre are no bugs whatsoever discovered or not and by which time the software design and function is archaic.
Hi,
this would require 2 times testing from the developers. KDE 3.1.x is now in a state where no more releases except security is expected and KDE 3.2.0 is about to appear.
You have to understand that. If you don't want to accept it, feel free to add to the resources.
My understanding is that as soon as KDE is the enterprise desktop supported by e.g. IBM or HP, you will get what you want. Lots of engineers designated to backport fixes to the stable release.
But to achieve that, KDE has some more way to go. I perfectly understand the preference to achieve the level where more company support will arrive instead of private people in their spare time acting as if they were paid for it.
Yours, Kay
I think that any in depth discussion would be better carried out on kde-cafe, but I will respond to your misconceptions.
> this would require 2 times testing from the developers.
Why? I wouldn't have made the suggestion if I had thought that.
It is easier to fix bugs on the current release branch because it *is* stable. Then you need to try to apply the patch to the current development branch. In the case of my example, it appears that this would have worked OK.
Your point was about testing. Since the current release *is* stable, you can figure that if you make a minor change and it works that that is it. No extensive testing should be required. Then you apply the patch to the development branch. That has to be tested anywho; doesn't it? Does applying the patch increase the amount of testing required? I think not -- you have to test the Alpha anywho.
So, my thinking is that my idea would result in less work and better results.
> KDE 3.1.x is now in a state where no more releases except security is expected
> and KDE 3.2.0 is about to appear.
That isn't always the case, is it. I'm not saying that you should fix bugs on KDE-3.1.x forever, only that this is what should be done till it is closed and the final release in the branch is issued. I think that this would be when KDE-3.2rc1 is released, but this is a management decision not really part of my idea.
--
JRT
Hi James,
thanks for the answer. I tend to agree that it could be done.
But we also need to look at the difference of KDE development vs. company development:
Say you were a developer that develops KDE mostly for your personal use, want it to win the desktop challenge (not war) and care deeply about getting as soon as possible to improved new KDE releases.
To develop KDE you possibly use gcc 3.3.2 plus CVS fixes as comes with Debian unstable, the latest KDevelop and the latest working KDE from CVS HEAD.
The stable KDE would not even _compile_ without further work (I guess). So you naturally stay on CVS only. Nobody risks untested checkins on stable, even trivial ones for not-so-important issues.
Early in a stable series, a lot of bugs will get fixes on the stable release, but after such a lot of time, it is likely not worth it. The most annoying bugs are worked out and you can wait few months more till KDE 3.2 release, not?
When 3.2 is occured, for a lot time most people will work on that I guess, but once KDE 4 is approaching, don't expect fixes when everybody is on QT4, gcc 3.5 and so on....
Yours, Kay
Yours, Kay
It's nice to see support for gopher:// URLs being added, but it seems to be being done in a nonstandard way?
It looks like it will try to guess from the content if the URL was for a gopher directory or something else. Standard gopher URLs encode the content type of the target in the first character of the URL's path, as shown here:
http://www.freesoft.org/CIE/RFC/1738/16.htm
I suppose that it would be better if you would report such a bug to KDE Bugs: http://bugs.kde.org
Reported only here it would be soon forgotten, if it has got the attention of the right developer at all.
Have a nice day!
Actually, I did that over a year ago, and it was returned to me as not needed.
I started working on file dialogs with plugins and multi-paged, (hit the bush economy for 5 months unemployment; sure can stop a lot). The plugins can be done to allow searching in the space, but also to allow for conversion .
I also had another one returned that also works with the above. Kio's are too limited in structure. There should be 3 base type of file, page, and 2d/block base (sql, but also snmp).
By doing the above, the concept of files, dbs, prints, and even export/import disappear. Instead, we just "Send To..." and "Get from..." with shortcuts allowed (read bookmarks)
Then: sorry, that I have written this. You seems to have reached the right developer after all. :-)
Have a nice day!
> Kio's are too limited in structure. There should be 3 base type of file, page, and 2d/ block base (sql, but also snmp).
I have seen that there will be support for "Extra fields" in KDE 3.2, whatever that means. Is this what you mean by that?
"Extra fields" ...Is this what you mean by that?
No. While I have not been able to do any kde work for the last year, I would assume that extra fields is for extra attributes.
The real problem is that kio is suppose to represent a file stream via disk IO.
the KIO gives us the virtualization of it, but it just does not get it done for all of the real world. The real world has actually several major forms out there.
1) a simple stream for which kio can, and does, represent pretty well.
2) a page device/stream. PDF, PS, even pixs are pages that are ultimatly sent to a form of a page device such as a printer or a fax.
3) a multi- dimensional item, but more like a 2D or table based approach. The sql and snmp KIO are but 2 that would have benefited from a based class.
If you mean the gopher_kioslave in kdenonbeta, thanks for the url because i thought gopher url's were given in a different way, I'll have a look at that page you say and to others RFC i have here to see if i was reading in a bad way.
does anyone else wish the package system would be replaced? i like most of the default kde programs but that doesnt mean ill use all of them. and most of the time id rather only install the ones i want, instead of the entire kdenetwork or kdemultimedia package, which actually contain some reduntant programs. i know you can disable the packages you don't want but this is a little tedious, especially when you are recompiling every week or so... seems to me that it might be a cleaner solution to just have the kde distribution be kdelibs, kicker and konqueror, then let you install the programs you actually use. just a thought
No, that's the job of the distributors. We make it easy for the distributors to get everything, and for contributors/developers to contribute. Everyone else should probably get KDE from their distribution. If your distribution doesn't split KDE up, then I suggest you complain to your distribution. I use debian, and they split KDE up.
If you only want to __compile__ kicker and konqueror in KDEbase, I suggest you investigate the DO_NOT_COMPILE environment flag. Search for it in google.
Hi,
then use a distribution with a policy that requires that for everything. I may suggest Debian which I use.
Install a 20MB basesystem then do:
apt-get install xserver-xfree86 kmail
which downloads/installs everything needed for just that one program. You probably also want kdm to login graphically and kdebase to have konqueror, kwin and the other basics.
Yours, Kay
I totally agree, using the current way I'm getting all kinds of programs I don't want on my system, cluttering up my menus, cluttering up context menus (hopefully real context menus in 3.2) and other things.
A config system like the Linux kernel has would be ideal.. just do a 'make kdeconfig' (or so) and config what programs you want and what not.
It takes a bit more time, but it's worth it.
(and hey, it would add even more choice, and that's what we all want, right?)
I (would) vote for this one. :-)
Nice digest, thanks!
best bug report ever:
Refer to Bug 64769 - restarting kicker makes kwin something something
Diffs: 1, 2
anyone else get it? i read down teh page for a while until i went "OH OH OH!"
lol nice.