Post a Comment
The important bit is this:
"The 500,000th commit took place on January 19th, 2006, and the 750,000th commit 23 months later on December 18th, 2007. In contrast, only nineteen more months were required to reach the 1,000,000 commit milestone."
Now that they migrate to gitorious it will be much harder to track commits.
Well done, KDE!
Uhh, will it? All the commits that make it into the mainstream will be in one repo somewhere and those can easily be counted:
git log --pretty=oneline | wc -l
Except that it's also really easy to count arbitrary ranges of commits, such as how many commits were made between tags, which is much more difficult in SVN (probably requires manual involvement, unless properties are used to indicate where a tag or branch was made).
He was modded down for being incorrect. The KDE devs do spend a lot of time fixing bugs, but KDE is a big project and so will have a lot of bugs. That's just the way it is. Also, old bugs aren't going to be fixed because they apply to KDE 3.5 and that is no longer being developed or supported (despite some distros still using it).
Here is what Bugzilla shows for the last 7 days: https://bugs.kde.org/weekly-bug-summary.cgi
Notice how half of the projects/components have actually closed more bugs than were open at the start of the week?
And for the last 31:
https://bugs.kde.org/weekly-bug-summary.cgi?tops=20&days=31
It's a little bit worse, but not by much. Plasma, while having a net increase of 68 bugs, still closed well over 600 bugs in one month. That's a pretty big deal.
So to say that they aren't fixing bugs is just nonsense.
I didn't say no bugs were getting fixed. But, for example keyboard shortcuts don't work properly since 4.0.0. They were scheduled to be fixed in 4.1, then 4.2, 4.3 etc. and they still don't work as of now. At the same time many new plasma stuff is added while the bugs pile up. So maybe it's time to stabilise at one point in time first.
Well, first of all your flippant "the number of bugs will be similar to the number of commits" is, of course, nothing but unhelpful hyperbole. There are about 22000 bugs in a project that encompasses hundreds of libraries and applications and at the last count, excluding extragear, about 5 million lines of code. Note that bugs and commits include extragear. This is actually a pretty impressive ratio.
Second, you attitude shows you don't know how a free software project operates. Your mind works in the corporate developers-are-exchangeable-resources model. That's completely inappropriate. It's even inappropriate for a corporate setting, but it doesn't apply at all here.
Nobody within KDE can reassign anyone to something. Nobody within KDE even wants to tell someone who shows up with his first plasma widget "don't commit it, first fix Paranoid Android's bug". We're way too happy having gained a new contributor.
And then, yes sometimes people leave bugs to fester for way too long. I'm guilty of that. I don't like it. There are Krita bugs that I have wanted to fix three years ago, and they are really nasty. But I'm not going to let Paranoid Android dictate my priorities. I reserve the right to fix an underlying problem first before tackling Paranoid Android's problem, a guy I don't even know and who engages in meaningless hyperbole and who very likely hasn't even participated in a small free software project, let alone one as big as KDE.
(And, for the record: I am still the fasters KDE bugfixer over the past year, with 2 minutes from bug to fix! So there!)
I think there was some chatter about doing it in September, but obviously it's going to depend on how well things go with Amarok's test run.
They definitely wanted to try to transition everything over during the 4.4 development window, and they don't want to do it too late in the cycle to keep from interfering with the beta releases and bugfixing.
Although KDE 4.3 release is due out in just a couple of weeks time, KDE.org have announced a third release candidate version.
http://kde.org/announcements/announce-4.3-rc3.php
July 22nd, 2009. The KDE Community today announced the immediate availability of KDE 4.3 RC3, a release candidate of the 3rd iteration over the KDE 4 desktop, applications and development platform.
While 4.3 already feels very stable, there still have been quite some changes to the code-base since the second release candidate. In order to have the 4.3.0 release well-tested, the release team decided to put out another release candidate and postpone the final 4.3.0 release by one week. The most notable change is probably a fix for a performance problem in Plasma, where applets would shortly freeze after being resized. This bug has been resolved by delaying the caching of rendered SVG images until after the resizing has finished.
Performance improvements are always welcome.
Edited 2009-07-23 00:15 UTC
I'm happy for KDE, but it's still incomplete as of 4.2.4, and it's still buggy. KDE 4.3 may or may not iron out some of this, but we're deep into a release and it's still incomplete and buggy. I agree with an earlier poster that I'd rather see quality instead of the next big Plasma release, or whatever. Give me substance over flash.
I really find it funny that despite running a Core i7 920 and an nVidia 275GTX card with 6GB of memory, my KDE 4.2.4 installation gives me a notification now and then that compositing was too slow and it's temporarily turning it off. What? So, is the resources for KDE gotten to the point that Vista requires, now?
Not quite, what you see is that code kicked in that prevented your desktop from becoming unusable due to bad video drivers (too little frames being rendered for compositing to be useful).
The nvidia driver still has grave performance problems, even my integrated intel chip feels faster than my desktop's 7600GS. I know it's frustrating for users, but we (KDE) decided to not paper over driver bugs so they eventually get fixed and don't stand in the way anymore in the future.




