Submitted by Some interesting tidbits concerning KDE 4. Firstly, there is a debate whether to close all bugs of KDE 3.x (or not) once 4.0 has been released; you can vote on a poll posing this question too. Secondly, some unscientific benchmarks show that KDE 4.0 from svn is less resource hungry than current KDE 3.x builds. Update: KDE 4.0 RC2 has been released.
Yes.
Ok, a few more words. Agree they should close them all, and start fresh.
Edited 2007-12-11 21:10 UTC
Does this mean all bugs reports and feature requests aren’t valuable? Will everybody have to resubmit all of them again? This is ridiculous. What about shutting down bugs.kde.org?
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.
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…
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
I don’t stone anyone
hehe
anyway, yeah, we should give these automatically closed bugs a special tag (I guess that’s what you want, right).
We also plan to send an email to the reporter, telling them their bug will be closed in 2 months unless they check if the bug is actually stil valid (including some hints on how to check).
If you want to backport fixes, no problem, 3.5.9 is sure open for that, and we do backport fixes ourselves and will continue to do that for a while. Of course, we don’t want to spend TOO much time on it, as we also want to ensure KDE 4 is good
“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.
We’re trying to get ppl to help out on parts of KDE that have a lack of developers – one way of doing so is to ask ppl who are clearly concerned about such parts to help out.
So you don’t want me to ask others to help, but you DO want me to look for ppl to help?
The ‘fix it yourself’ is the only answer we can give if we don’t have the ppl ourselves to do it. A proprietary company would simply say “we don’t want to put resources in it, forget it”. We say “we can’t put resources in it but feel free to help out”. What would you prefer us to say and do? First, second or do you know something else?
Anyway, yes, it IS possible there will be parts of KDE 4, which are now freshly written but will be unsupported in a year or so. Of course, only applications, not parts of the libraries, we are committed to the libs and if parts of them become unmaintained, others pick it up. We can’t do the same for applications, there are simply too many of them.
No, I understand you need people to help, but if you want a cohesive, near-corporate team you might HAVE to shop around for “employees.” I just over reacted because I hear / read that response (not from you specifically, I just responded unjustly to you) from a lot of developers: “You want it done DO IT YOURSELF!” It is not an uncommon response and it usually is not worded as politely as you did.
I apologize for using your response for my own agenda.
Well, I’m sorry for responding a bit pissed off
I do see your point – but often there are other reasons for the “do it yourself” – and that’s because the developers don’t WANT the feature, and just wanna get rid of the person who asks for it. I think that’s rather rude indeed. Of course, all FOSS developers do want to do more than they can do, so they always want/need more help
I think the anti-kde league is coming after you. Seriously, who the fsck modded this down?
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.
Seems to be a problem with a lot of open source products.
You notice a bug. You find out the bug is fixed in a either a newer release which contains new features and new bugs or you have to go to CVS to get the bug fix (again with new features and new bugs).
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.
And the result is a huge mess of different API’s for the same thing, and each app using another one. There goes the ‘let’s share stuff, it saves resources’ through the drain. KDE values a clean, consistent system, and thus takes the opportunity to do a major cleanup every 5 or 6 years. Which is what makes it the better DE (or even best, including proprietary competition) in terms of development.
That’s incorrect, and shows your lack of knowledge about Gnome.
Gnome has extremely modularized dependencies (which isn’t merely a good thing – it has drawbacks as well – the big blobby kdebase for kde 3.x has different strengths and drawbacks) and as such it doesn’t require more resources (apart from harddisk space). Add to that that most applications are quick to move away from deprecated API, so you wont be in a situation where there is a “huge mess”. DBus and Bonobo resides in different libraries unlike kdebase which contains most of KDE (the modularity of Gnome has several drawbacks though – a big Gnome installation requires more resources than a big KDE, that part is unfortunately true).
EDIT: Personally I prefer an incremental system rather than breakage every 5 years (which results in duplicate libraries and what not – kde3libs and kde4libs side by side – talk about a nightmare), but a clean up process does have one major thing going for it – it allows for cleaning up (hint to Gnome/GTK+ devs).
Edited 2007-12-12 16:00 UTC
You probably mean kdelibs there.
Actually kdelibs, the module, consist of a set of libraries, e.g. libkdecore, libkdeui, libkio, etc.
It is not one big single library, applications only link to those they need functionality from (unless the application developers needlessly specified all of them in their build files, but that doesn’t happen very often)
I do know how it’s SUPPOSED to work in Gnome. And I also know it doesn’t work that way in practice. There are many different toolbarimplementations in Gnome applications, and just one in KDE. I still see “added ability to configure shortcuts” or “Gedit now has configurable toolbars” and the like in release announcements. Something which makes me laugh, and think “boy, this is 200x, you guys still don’t have that sorted out in your architecture?”.
I know many KDE dev’s are pretty religious about having a clean, consistent and non-redundant API – but their attitude has ensured you won’t find many serious developers who would deny that KDE(libs) has evolved into one of the cleanest and most efficient (if not THE cleanest and most efficient) development environments in the IT business. We’re way ahead of the pack, and I’m not just talking about Gnome/GTK but also about MS and Mac. And unlike them, we’re cross-platform
The ‘nightmare’ of KDElibs3 and KDElibs4 at the same time won’t last much longer than 6 months, which imho is better than having old apis around for years and years.
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.
Sure, where is the support for Windows 95? NT4? Windows 2000? DirectX 10 for XP?
Microsoft is no different in this regard, except they support for a shorter period, unless you are willing to pay the big bucks. If you don’t you get nada whatsoever.
Except they are not EOL’ing the 3.x series so your entire post is offtopic and inaccurate.
I remember Win 2000 being released with over 64000 bugs so that is the reason people use Microsoft ?? Amazing
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.
Closing all the KDE3 bugs? It sounds just like an April Fools' joke. Except it's not April.
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”.
You know that marking a bug report as closed doesnt actually remove it from the bug tracking system, right?
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!!
yes yes yes. Read other ppl’s equally uninformed comments before you comment yourself, please. KDE 3.x is not EOL, that is a whole different issue (and there will be kde 3.5.x releases for quite a while, don’t worry).
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
I saw an analogy the other day that made me laugh: crudely paraphrased, it was that most bug reports are like someone phoning a vet and saying “There’s something wrong with my pet” – and then hanging up.
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
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?
By the way, that resource comparison is completely useless. As Lubos pointed out, the way they measured memory is wrong, and the results mean nothing. KDE4 is probably still lighter than KDE3, but these numbers aren’t evidence to support that.
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.
i think KDE team should close Bugs on 3.5.x series when 4.1 is out, to close it now is to early, KDE4.0 isn’t gonna be stable enough to close Bugs on 3.5 series now
Edited 2007-12-12 01:19
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?
Sadly, this version (RC2) is still to unstable =/.
Edited 2007-12-12 02:25
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.
If KDE wants to ensure that no corporation ever takes the KDE environment seriously, than yes. They can instantly close all bugs in KDE 3 when KDE 4 is released.
However, in the real world. Various users, for various reasons, cannot upgrade to the “latest and greatest” major release as soon as it comes out.
In a nutshell, if KDE wants to be taken seriously, they cannot afford to instantly effectively “obsolete” KDE 3 as soon as KDE 4 comes out. They need to support KDE 3 for at least another year or two. And part of that support will involve backporting fixes made in KDE 4 to KDE 3. This is simply the reality that any project that wants to be taken seriously in the mass market needs to deal with. They have to provide support and bug fixes for older versions.
Edited 2007-12-12 04:24
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.
My experience with bugs in kde isn’t very well either.
I’ve filed about 50 bugs and very few of them were ever fixed. Most have just stood there confirmed.
For the last year there has been no activity in any of them.
Can you give a link to some of your bug reports?
It’s ridiculous that the KDE project would even consider doing this… that’s something you would expect from Microsoft. I had doubts that KDE would be able to do everything they were planning with KDE4 to begin with without problems; the fact that they’re considering just killing off KDE3 this early makes it look like they *are* having some serious development problems. Why else would they just kill KDE3, right around KDE4’s release, unless they were having problems and need to put as much work on KDE4 as possible, at the expense of the older version? This news just reeks of Microsoft to me.
Just because one KDE person on a blog mentions that we need to close all bugs for KDE. Doesn’t mean its going to happen. I HIGHLY doubt thats going to happen.
Move along, nothing to see.