Submitted by The KDE project has announced that it has reached its one millionth commit to its Subversion repository, indicating that the KDE project is very healthy indeed. “This is a wonderful milestone for KDE,” said Cornelius Schumacher, President of the KDE e.V. Board of Directors, “It is the result of years of hard work by a large, diverse, and talented team that has come together from all over the globe to develop one of the largest and most comprehensive software products in the world.”
The KDE project appears to be pretty healthy all around. Not only are the number of commits/month increasing, they’re also seeing a steady influx of new developers. “The pace of development within KDE is rapid and healthy, and new developers join us at an astounding rate,” said Schumacher, “On average, each month for the past three years, more than twenty new developers have made their first commit.”
According to Schumacher, the strength of the platform stems from its vision and quality. “”We have dedicated ourselves to innovation and building a platform well-suited to future needs,” he explains, “This has enabled developers to write amazing software for the platform using a variety of languages. As a result, the response from the community and press to our KDE 4.2 release has been overwhelmingly positive.”
A special thanks go out to the Subversion team, but at the same time, the KDE project is moving certain parts over to Git, because KDE developers believe Git suits their coding needs better than Subversion. “The centralized model of Subversion has served us well and works very well for some of our contributors, such as translators. But in other areas the increasing speed of development and the availability of mature distributed version control systems has led the community to think about the current infrastructure,” Schumacher states, “Many developers have found that their development style would be better suited by distributed development tools like Git, Mercurial, and Bazaar. We believe in using the right tool for the job. As such, parts of KDE development will be migrating to Git.”
On a related note, the Gran Canaria Desktop Summit Akadamy 2009 technical papers have been published. Congratulations to the KDE project for reaching this milestone!
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!
Harder with git? You have to be joking.
You can do:
git shortlog -s -n
Which shows the number of commits made by each person. You can get all sorts of statistics out easily.
True for one git tree. But how do you integrate all the private git trees?
It is distributed, you know. So the true extend of work done might or might not be visible.
Anything that goes into KDE itself will end up in some primary repo somewhere, or into SVN if they are still using that as the main repo. The commits can get counted then. Commits in private repos are as irrelevant in Git as uncommitted working copy changes are in SVN.
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).
Congrats.
I love their products.
Sounds impressive but I would like to see more bugs fixed instead of “the next big plasma applet”. The number of open bugs is probably the same as the number of commits and it’s a shame some bugs have been open for years (even when people vote for them).
I completely agree with this, but it is a shame some KDE fan boy has modded you down ..
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.
So your pet bug isn’t be fixed. Cry me a river. You also assume that the people adding plasma features are the same ones who might otherwise be fixing your pet bug.
Perhaps you should contact the developer assigned to your bug directly and bug them about it?
It’s just one example of a long list. Make a list of the most voted bugs and see how many are still open after long periods of time.
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!)
It sure feels that way!
That’s a pretty stupid comment, really. You might feel you were clever and witty, but you failed.
If you want to be able to say something remotely useful, try getting the total number of open bugs for other big projects, like mozilla, gnome or open office. Then calculate the number of lines of code in these projects and compute the basic defect ratio. If you’ve done that, you’ve got the beginning of something useful.
I am confident you will find pretty much the same ratio everywhere.
Bug #? Works just fine for me. I remember some problems in earlier releases, but its been fine since 4.2 for me.
Great job, KDE team.
In my opinion(!), KDE is by far the best desktop on *nix, and I’d like to see it going for many years to come.
Best wishes and congratulations!
Which parts of KDE are moving over to Git?
All of it at some point.
The bits that GNOME wrote.
/jk
Only Amarok has already moved to git but the whole KDE project will eventually do the same. What I understand is that the when and how hasn’t been decided yet. KDE is going to wait how things work up with Amarok and only then migrate.
Ok, that makes sense, thanks for the info!
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.
oooooooooooooohhhhhhhhhhhhhhh big deal
it is a slow news day when we people get excited about KDE commits.
Geeks!
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
Performance improvements are always welcome.
Edited 2009-07-23 00:15 UTC
Something tells me that in a couple of months, KDE 4 will have a jump on its version number scheme, to KDE 7. I wonder *WHY* something like this have the risk to happen… to immitate exactly *WHAT* again? Hmm… Just a thought… Never say never dude, you saw Slackware 4.2 jump…
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.