Post a Comment
Ay carumba, way to overreact. Sure, shut down bug.kde.org, obviously the devs don't care ??? Some of them are important. Some of them are relevant. Some of them are irrelevant. Many of them are stale. Unless you or others in the community are opting to step up and comb through 15,000 bug reports to determine validity, I don't see what's wrong with this.
They're not talking about wiping out the bugs, they're talking about marking them closed. If you have a bug or feature request, spend 30 seconds to reset it to open. Not a big deal on behalf of the community, considering the work the devs have trying to manage the bug load and determine which are valid and which should be put out to pasture due to obsolescence.
That's the way community is supposed to work. The devs have a job to do, and those of us that can't dev should do what we can to make their job easier.
Edited 2007-12-12 04:27 UTC
They probably should shut the thing down seeing as how they don't seem to actually even bother to look at the bugs for ages...
Case in point: I submitted in a clear, concise, specific bug with KDE back in October of 2006 complete with specific application, conditions, and reproducible examples (none of this teh broken, teh broken' stuff).
No one even looked at the bug until almost 1 year later. What was the response? "Confirmed". Then it was "reassigned to KDElibs".
Gee, real useful.
dear superstoning one,
please make them give the closed bugs a differentialable tag so you can actually see what the reason for closing the bug was. Else the result will be like throwing two haystacks together: a grey, gooey pile...
Why so? --- I definitly want to have a go at the KDE code base soon (=when I got some more time) and even want to fix my own bugs, and BACKPORT them. BACKPORTING is a goood thing to do, you know?
regards!
Edited 2007-12-12 14:19
"Well, someone needs to do the work, and for some parts of KDE there simply aren't enough who can do so. Feel free to help out..."
Then why are there such parts, ones that don't have the people to support them. Maybe KDE should focus on establish a larger base of consistent developers to maintain the code. Are there going to be parts of the KDE 4.0 code that won't be supported (over a year for a response to a reproducible bug report, only to recategorize it == no support to me) even tho' they have been freshly redesigned and rewritten?
And maybe the guy/gal who filed the bug report really doesn't HAVE anymore time to spare, or maybe he/she doesn't know how to code.
Anyway, I am not trying to slam KDE or the developers. I guess I am just getting tired of hearing the "well if you want it fixed, why don't YOU do it" response from open source projects who at the same time want the product to be canonical across the desktops of people everywhere.
This is why people use Microsoft products. So, before any major distribution has even adopted KDE4, they want to end-of-life KDE3. Nevermind slower moving distributions like CentOS/RedHat and Novell, even Ubuntu and openSUSE won't have it for months after release.
It's wonderful to cut off the past. I love doing it. BUT, customers hate it! No business would ever adopt KDE with such a support stance. If you want to argue 6 months, 18 months, 5 years, fine. The fact is that you have to allow people some room to adopt a new system. Why do you think Ubuntu came out with their LTS scheme? Because no business will adopt software that doesn't have long-term support.
That happens with proprietory software as well. The the first response to any report of a bug with MS or Oracle et al is "have you upgraded to the latest version" Its a great trick to say that they'll only support the current or later version and please get your credit card out to upgrade to it
And Ubuntu has Cannonical to offer that support and paid for it. It's not that KDE developers don't want to support KDE3, it's just that we don't have the ressource to do it. If business wants long term support they won't get it for free, they just have to pay Red Hat, Novell, Canonical, Mandriva or whoever else can provide that support.
And frankly, what kind of support Microsoft is now offering for older version of Windows ? It's mostly limited to security, well, KDE is still offering security update for KDE3 and it will keep going until there are users for KDE3.
And remember, KDE is just the Desktop Shell, while Windows is the whole system, there aren't that many fixes in Windows Desktop Shell.
There are a few problems with this:
* KDE 4.0 will not have all KDE3.x apps ported to it -- it's just the base platform plus some important apps. You can still use KDE 3.x apps that haven't been ported yet -- you just have to have KDE 3.x run at the same time as KDE 4.0. If KDE wants to cut KDE3.x loose, KDE 4.0 users will have to live with a partially supported environment.
* By giving up on KDE 3.x, any further support work that's done by one distro will be part of that distro alone and not shared with others, especially if some KDE 4.x features are backported. Anyone who was around during the late 2.4 Linux kernels development cycle knows that distros will create semi-compatible backport forks if the development of the main line is too slow.
* The proper way of handling bugs that you don't want to fix because a new release exists is to defer them not to close them. That actually makes it blatantly clear that the bug isn't fixed. If someone wants to backport a fix, then let them and then properly close the bug.
Personally, I hope that KDE 4.0 has taught KDE developers the same lessons that GNOME did when it released its 2.0 platform (or Netscape when it went from Netscape 4.x to Mozilla). The platform was a *huge* improvement over the 1.x platform, but the cost of "porting the world to 2.x" really hurt GNOME. It hurt it so much that GNOME has not tried to make such a massive architectural change ever since. That hasn't prevented GNOME from making dramatic architectural changes over a few releases (compare slow clunky Bonobo filled GNOME 2.0 with fast lean modern GPIO-DBUS-Cairo GNOME), but it has gotten rid of the "break everything then find resources to pick up the pieces while you're still managing the most popular version" problem.
That hasn't prevented GNOME from making dramatic architectural changes over a few releases (compare slow clunky Bonobo filled GNOME 2.0 with fast lean modern GPIO-DBUS-Cairo GNOME)
It really helped that pretty much nothing used Bonobo.
It hurt it so much that GNOME has not tried to make such a massive architectural change ever since.
Unfortunately, that is just covering up other problems.
Not to mention that Bonobo hasn't been removed. Merely deprecated. Anything using Bonobo still works, and Evolution Data Server is one the packages relying on Bonobo (slated for migration to DBus in Gnome 2.24 I believe, though there is already using DBus).
Gnome has managed to make major changes because none of these removed anything, but merely added new functionality.
It's wonderful to cut off the past. I love doing it. BUT, customers hate it! No business would ever adopt KDE with such a support stance. If you want to argue 6 months, 18 months, 5 years, fine.
Well, on the desktop side of things, people tend to discard things on a more regular basis because things are moving at such a pace and, relatively speaking, reasonably few people use open source desktops today. Those that do, simply upgrade and take their stuff with them. Virtualisation also makes this a lot easier for businesses. As more people start using open source desktops, needs will change and development practices will reflect that. Distros will need to weigh in with solutions as well.
On the other hand, I have games for Linux I bought seven or eight years ago, and they still work. They have survived umpteen library changes and a major kernel change. Motif applications still work.
Why do you think Ubuntu came out with their LTS scheme? Because no business will adopt software that doesn't have long-term support.
Ubuntu's LTS, like Debian's whole stable things, is pretty much meaningless. All that can happen is that security issues can be just about fixed, although code will have to be merged from elsewhere and you can never really guarantee it, it's extra work, and other forms of bugs probably won't be fixed that are fixed in later versions of the software. Debian has this problem, as the code they have to merge themselves gets problematic. This is basically why Iceweasel came about. It's Firefox, but not a version of Firefox that actually is Firefox.
This gets worse once you have people writing lots of third-party applications.
In the case of KDE, what we'll probably see is KDE 3 libraries being shipped alongside KDE 4 and if they need supported then they will be. It should then be possible to integrate KDE 3 libraries into KDE 4 so that you then get KDE 4 features in KDE 3 apps for free. However, there aren't lots of KDE 3 apps out there that won't be recompiled that will break.
LTS for the OS and base libs is fine, and is valuable. Gives you a known-good, unchanging base to build upon.
LTS for the apps that are part of the distro, where they are frozen at a specific version until the end of time, is not. Even with backports, this sucks!
Having security updates for 5 years for the base OS is great, and useful. Having just security updates, with no feature updates, for the apps, for 5 years, is lame, and useless.
Hopefully, someday, one of the Linux distros will realise this, and move to a split "base set of packages for the OS", "separate repos for the apps that run on that base" setup.
Did you even read the article. They don't want to EOL KDE 3. They want to remove all bug reports from the database and start from scratch.
Their reasoning is that there are too many old bugs and there is not enough manpower to go through it all. To quote the article.
This does not mean they are dropping support for KDE < 4 it means they are cleaning out their bug database. To make it easier to maintain.
I do not remember Microsoft offering long life support on their software? No software company is going to be static, that is the nature of the business and no company is going to say we are going to purchase this software and run it for 30 years...
IF anything companies have left Microsoft environments for Open Source to control their own upgrade cycles. If MS was the crown jewel of support why are they so don't they fix their software and make it secure??? Because they can't!
Well, not coming up with a new operating system for 6 years makes you support your older versions already for quite a while.
Locking in customers so thoroughly that even migrating to Vista is painful makes businesses delay migrations. And lets them call for long time support.
As noted above, and as promised in various KDE press releases, the KDE 3.5.x series is expected to be around for a while after the KDE 4 series comes out.
It's evident that they're managing to release bugfixes for KDE 3.5 even though they're working on KDE 4; I'd like to see them continue that even for a short while after the release of KDE 4.0.0, especially since a lot of KDE 4.0 will be brand new, as opposed to shifts from 3.3 to 3.4 to 3.5.
Of course, I say that as someone who expects KDE 4.0 to settle in fairly quickly.
Bug reports may contain information on work arounds, or even just things to avoid. This information should be kept as long as there is sombody using the system, in this case that would probably be for several years.
At the very least they should, send out a message to the owners, and interested parties of the bug to ask if they still are interested in getting it fixed before they close the bug, and even nobody is interested and the bug is closed the information should be kept, e.g. by giving it a state of "closed unfixed".
I don't think that all the KDE 3.x bugs should be closed upon the release of KDE 4. For one, many distributions that strive on stability will be using KDE 3 for quite a while after the KDE 4 release, and these will be possibly vulnerable or buggy. If these bugs are not fixed we could have security problems. Another point would be, from what I gather the KDE team and much of the KDE community is saying that KDE 4.0 is just a release to get the major groundwork and technology for KDE 4 out there, and that that versions that users would more likely want to use will be release later on. This would leave a major gap.
Oh dear.. There is going to be a landslide of people freaking out because they are equating closing old bugs with ending support. It is NOT the same thing.
Get this through your head before flipping out.
- If a bug still applies, it will of course be re-opened.
- Closing bugs does not make an existing product less stable.
- KDE 3.5 is still being updated with bugfixes, and will be updated with security updates for a long time, just like every other KDE release.
- Closing bugs for housekeeping is not the same as EOL.
- Bugs are closed, not deleted. No information is lost.
- This is not being done for shits and giggles. The current bug database is becoming useless to developers because there is so much irrelevant stuff in it.
Just because KDE4 comes out, does not mean the previous version should EOL! Ok it's probably "stable" in the eyes of the devs, but imagine if XP SP2 had been EOL when Vista came along... it just doesn't make any sense, and I honestly can't believe rational people would suggest it!!
This is what I think needs to be done; close all the bugs, and in future control who reports all new bugs - because quite frankly we have idiots out there who either;
1) Post duplicate bugs because they can't be bothered actually searching the bugzilla database for other bugs of a similar nature
or (the worse)
2) People who have really crappy bug descriptions when it comes to lodging bug reports; before writing up a bug report read ESR's 'how to ask a question'.
For god sake, if Konqueror doesn't render a website properly don't put 'konqueror broken' for the bug title; use something descriptive such as "Konqueror Rendering Bug: <name of website>" or better still, if one knows what the bug is related to - say, an unimplemented javascript feature, then put that in the title.
It really does frustrate me, and I'm sure other people who do contribute back, by those who lack the basic comprehension skills to be able to eloquently articulate what is wrong. Simple screaming 'teh broken, teh broken' doesn't give much information as to the cause (or possible solution) to the problem.
Edited 2007-12-11 22:41
1) Post duplicate bugs because they can't be bothered actually searching the bugzilla database for other bugs of a similar nature
While that is a problem, calling these people idiots because they don't know the correct procedure won't help. It's tough to file a good bug report, and finding duplicates is a lot of work and not always easy.
The solution here is to politely point people to instructions for how to do it better next time (not always possible either, I know).
Edited 2007-12-11 23:00
The solution here is to politely point people to instructions for how to do it better next time (not always possible either, I know).
Looking back at the post, I think the point I forgot is how (1) is inter-linked with (2); if there aren't good bug descriptions, people aren't able to search/find the bug related to their problem - if people can't adequately do that, they give up and file a duplicate bug report.
Regarding it being tough; its common sense. I don't want to come off as rude, but the first port of call when you have a bug is to search the bug database using the description or even the error message (assuming they're using a up to date bug database which allows searching inside the bug reports).
As for politely, if you look at all the major bug reporting for opensource projects they *always* without exception suggest that you search the bug database for the bug before submitting a new one; if you don't know what to do; read a howto.
I'm not slamming ignorance; we were all ignorant at one stage, but then we, through reading, learn what needed to be done. What I'm saying is that if you don't know what to do; ask someone, look up howtos and read, sign up for the respective mailing list; if it is a konqueror bug, subscribe to the user mailing list and ask a question.
Yeah well closing the bugs for KDE3 won't stop people from re-posting the same crap for KDE4. In-fact I predict more bug reports for KDE4 if there aren't already a whole bunch of them. I Honestly don't see how KDE4 can even be considered RC2, this thing is not stable at all and there are things that are not working. Ofcourse I should search the database to see if my complaints have been filed. I don't see that happening with a lot of users though.
Perhaps, a countermeasure would be to make the the bug report system more smart. This is about the same situation when you develop s data system for a broad audience, you need to be very careful about what information can be inserted on the database. I do know the bug reports are less constrained, but see no other way to keep them relevant other than to use some AI to classify, group, discard and create reports around them. This would make them much more appropriated/attractive to developers eyes.
I think it cuts both ways. I have in the past filed/contributed to a couple of bugs on bugs.kde.org and I'd have to say I was left with little desire to go back.
For the record, I named the affected component (and version) and summarised the problem in the title in both cases, and gave details of the OS/version and compiler settings, related configs and reproduction steps in the body. On request, I produced relevant log-output for one of the bugs.
Now were either of these bugs a duplicate? It'd be hard to say for sure, though I did my best to search for any possible dupes. Why am I not sure? Because bugs.kde's search is very dumb and searching successfully is (in my experience) a real trial. This is true of most bug-dbs to be honest, but KDE's is the most rudimentary I've seen.
What really broke my spirit though was the lack of response. Again KDE are not alone in this, but the silence can be deafening. At least in one instance I was asked for some further data, but there hasn't been any reply since I submitted that (about 18 months ago), even to say "well, that didn't help unfortunately."
I believe I've been attempting to help both KDE and myself by reporting bugs, but where is the motivation to keep doing so when you doubt whether anyone is listening?
KDE's bugzilla seems untameable in its current state. Closing all KDE3 bugs seems like it could help, but the underlying problem (bugs being opened faster than they are closed) will remain. Closing all those old ones might help in that it makes things look less hopeless, encouraging people to work on it more, so perhaps it should be done (or as someone mentioned, perhaps KDE4 should get its own bugzilla).
I'm rather scared for the future of the project. The dirtree view of Dolphin doesn't show the root directory (hard to get to your home dir if the dirtree only shows its subdirs). I tried to report it and saw a ton of wishlist items about related things (no horizontal scroll in the dirtree panel etc) so it seems bugzilla will be overflowing as before. Then when I tried to open imageshack to have an image to which I could link Konqueror crashed, or maybe it was just plain KDE that crashed since it all stopped responding and I had to ctl-alt-backspace.
This was after Plasma died a few minutes before and reset itself. That was after realizing I couldn't move plasma widgets (or couldn't figure out how which is just as bad) so when one covered another I had to close it. Kickoff at least worked, but unfortunately it isn't my cup of tea.
It's really hard for me to believe they are using the term Release Candidate for this. I can't imagine using this day to day for at least another year.
This being open source, ideally I'd help out instead of complaining, but it seems apparent that adding anything to bugzilla just increases the chaos, and I don't have the time to assist with code (not to mention lack of familiarity and expertise). There's really nothing I can do and it feels kinda bad. I'll just keep hoping for them that things straighten out.
just thought I'd be the first to mention that KDE 4.0 RC2 is looking pretty good.
Starting to look like a mature desktop already - one that could be used day-to-day. Of course I'm only basing this on screenshots but hopefully when I try it out in the next couple of days I wont be disappointed.
Looking forward to the 4.0 release! I've been an early adopter in the past (some would say that all current linux users are early adopters) so no need to change 
Discussing to close KDE 3.0 before KDE 4.0 is even out of the door? Don't be silly. I agree - quite unscientific. We can only draw qualitative conclusions from that data. And Yes I also agree my comment doesn't add much ... there isn't much one can say, really... is there?
They're closing the bug reports, not the KDe 3.x series.
Seriously, can all you morons who complain about this just read the damn article and activate your braincells for a few seconds before writing your stupid complaints?
Why don't they just have a separate bugzilla (or even better a separate tag) for KDE4 bugs. This will be with the understanding that most developers will care more at those bugs that are tagged for KDE4, unless something in 3.5 gets voted up a lot or something like that. Plus, if you find your favorite old bug still persists in KDE4, just open a new bug with a KDE4 tag that points to the old bug or allow reporters to add a KDE4 tag to old bugs. This way you don't lose the workarounds posted in old bugs and won't be rude to all the reporters.
Also, to those who are talking about Microsoft's fix system, please note that we are talking about bugs and not security fixes. Microsoft's SP3 for XP will expected to be the last bugfix for XP (about a year after Vista's release). They will continue to support XP for a long time but that usually means security fixes not general bugfixes- which I am guessing will be true for KDE 3.5.x as well.
and another moron not reading the article. As someone before said, can you please activate the few braincells you seem to have, and even more so, read other ppl's comments before you add another stupid remark?
Closing the bugs as 'too old' doesn't remove them from the database, doesn't mean we won't SUPPORT KDE 3.x and generally has nothing to do with anything you say.
They are not talking about closing KDE 3.5.x
They are not talking about erasing open bug reports.
They are simply stating that after several years with bug reports open for various versions of KDE, it might be a good idea to reset the database in order to ensure that people with valid bug reports can simply reset their ticket back to open and ensure that the devs see it, rather than wading through 14,999 posts of "compiz doesn't work" or "Konqueror 1.2 fails with Webcrawler".
If there's an admission of guilt here, it's that the devs have been too overwhelmed to properly manage the pruning and updating of the bug database, but it's a situation hardly unique to KDE. I suppose they could simply flag every open bug as "WONTFIX" as other projects do by default if only to keep the bug fix count down, but they don't roll that way.
Seriously, if anyone thinks that the KDE devs just want to erase open issues and pretend they don't exist, they're not really following project closely.
I agree, I voted yes for the simple reason that the bug database needs pruning. KDE 3.3 was released 3 years ago and their are still many bugs filed older than that.
Looking for a bug to fix becomes a hassle as tons of them are old and probably no longer applicable.
This has nothing to do with no longer maintaining KDE 3.5. Any bugs that are still around can be resubmitted and should be fixed.






