In this week's KDE Commit-Digest: Continued post-release polishing of Amarok 2.0. Support for conversion between temperature scales in the "Weather" Plasmoid. Initial import of "System Status" Plasma applet, which is renamed "System Load Viewer" (shows CPU, memory, and swap usage). Support for on-the-fly compilation of Plasma data engines with the C# language bindings. Further development of the "BookmarkSync" Konqueror plugin, including additions of autofetch, autosave, and a settings dialog. More refined integration of Wikipedia "place" information in Marble. A QtScript engine to allow creation of games using QtScript in KGLEngine. An experimental "curve brush" added to Krita. Support for the ext4 filesystem added to PartitionManager. More reorganisation of wallpapers in KDE SVN, with a general kdeartwork module cleanup removing IceWM themes, KWorldClock maps, and unmaintained iconsets. PolicyKit-KDE moves to extragear/base. Eigen 2.0 Beta 3 is tagged for release.Read the rest of the Digest here.
Comments
We're up to date! Thank you Danny, and have a wonderful new year!
Danny, thank you for continuing your work for commit digests.
Hey Danny!
Thanks for all of your hard work! You are awesome!
Are there any idea's yet how we as a community can help Danny to make his task a lighter one? I've just checked his blog entry on the subject and there are still zero comments there. I'm not a developer so I can't exactly asses what's needed. His main problem seems to be to hunt down all the commits to find the most interesting one's. He suggests that developers mail him when they committed something noteworthy.
I have an idea but I don't know if it is technically possible. This idea is to let the developer somehow tag noteworthy commits with a special "Digest" tag. This way, Danny could make a script to filter on that tag. Developers should by now have a general picture on what is considered Digest-worthy, considering all the already produced digests.
Any other idea's?
"His main problem seems to be to hunt down all the commits to find the most interesting one's."
No, the main problem is getting the devs to write "feature" articles - as you can see by the rapid rate of Digests where the feature articles have been (temporarily) dropped, "just" searching through the commits is not the bottleneck.
I love the feature articles, but I don' think they need to be tied to the commit digests. I've enjoyed the recent smaller digests as well, and they stand alone without a story to go with them.
Of course these feature articles are great, but I guess we can't expect there to be one each and every week. I think they should be posted directly to the dot as they are written, and keep the digest in the reduced form it is now.
Anyway, great work Danny, always a pleasure reading your work.
I've read Danny's blog post about missing "feature articles" and stuff. While I really appreciate his work, I don't understand his problem in this case. I see lots of "feature articles" every day on http://planetkde.org/
Feature article about panels in 4.2? Here: http://aseigo.blogspot.com/2008/12/hiding-panels-feature-complete-for-42...
Articles about upcoming Amarok features? http://amarok.kde.org/blog/archives/843-From-the-Post-2.0.0-Git-Vaults,-... and http://amarok.kde.org/blog/archives/858-From-the-Post-2.0.0-Git-Vaults,-...
Looking back at 2008: http://aseigo.blogspot.com/2008/12/passing-between-years.html
Cause they are not new? They were read and discussed already?
What's your point? If you want up-to-date information, screw the commit-didgest completely and point your browser to http://cia.vc/stats/project/KDE and scroll down to "Recent Messages".
Just as the commit-didgest is just a compilation of a week's work, it could quote two or three important blog posts of that week.
If he doesn't want to quote blog posts, fine... it's his decision -- just as it's the developers' decision to post to their own blogs instead of mailing Danny and then hoping that it gets picked up a week later.
or even better: http://commitfilter.kde.org/
=)
"the Digest is not going to become a mirror of PlanetKDE!"
http://dot.kde.org/1230851783/1230892169/1230904882/1230905622/
If the Commit Digest articles are just copy'n'pasted from planetkde, then they lose a lot of their relevance.
Devil has a point. Imho the added value of the commit digest are the commits, not the stories - those could be posted as dot-stories or blogs, and not be different. I would therefor be entirely OK if the current digests would set the tone for the future.
However, I can imagine having the additional content makes composing the digest much more fun, and ultimately it is up to Danny. After all, he does the work.
Well - I DON'T like to read all the devs' blogs. I just don't have the time for that. Blogs have the tendency of containing too much information I'm not really interested in - the commit digest had the advantage of concentrating on real news around KDE and not the individual itches of some developper.
I guess this is a hard hit against the ego of some bloggers ;) ?!?!?
However, if Danny e.g. would just use the commit digest to link to interesting blog posts with real information about new features of KDE or nice tutorials, as some KDE4 bloggers are publishing, this would be great.
> Well - I DON'T like to read all the devs' blogs. I just don't have the time for that. Blogs have the tendency of containing too much information I'm not really interested in - the commit digest had the advantage of concentrating on real news around KDE and not the individual itches of some developper.
Do you know of Planet KDE (www.planetkde.org)? The blog posts there are 90% developing things, and the rest 10% can be sorted out by just reading the title in most cases.
I guess he means that he don't want read the whole technical post about anew feature, just the commit-digest resume of that new develpoment.
Yes. 90% of all blog entries don't deal with the news I'm interested in, but - blogs being the contemporary equivalent of diaries - with some itch the dev currently has. I'd like to have detailed description of some new KDE4 feature, written in a way that is appealing to me as an end user.
In a way, Danny is the last person who seems to be interested in conveying interesting news of the developpmnent to the end user, to many other KDE4 devs seem to be no longer interested in communicating with thesometimes critical user base :(. The lack of "featured articles" seems to be one more symptom of that attidtude.
I would like to see more automated statistics as this really inspires you, for instance an EBN report for the week. Everything that is automated does not need to be manually compiled.
I think that this could still work. Take a look at the Linux Kernel.
The git changesets already have small summaries applied. Now, if different parts of KDE have a "leader" who could extend these summaries every once in a while to see what is more important, it could help Danny to speed up his summaries.
Good job, we are back to be up2date!! Happy new year by the way! :D And keep up the good work!
> from the i'm-not-a-department dept
:)
Thanks Danny. Your efforts are much appreciated.
Cheers Danny! And don't let such a mundane fact like reaching the present time stop this amazing Digest marathon of yours. It would be *awesome* if the Digests reported on KDE developments happening in the future!
I guess the day Qt switches to a public git repository (not snapshots, but a real repository) weekly digests of Qt would be possible, and I would love to read them, too. Reading KDE digests is much more interesting, but knowing what to expect from the "next" Qt would be very nice.
For Qt 4.5, the focus is on performance. If you now think "Yeah, they optimized it a bit", you are plain wrong. I tried the "-graphicssystem raster" switch, and IT FLIES! Even much faster than Qt 3 for sure.
Now only KDE 4 needs to pick up the same path, and optimize icon loading and KWin speed. Feature-wise, KDE 4 is superior to KDE 3 already. Really, try current trunk.
Thanks to all involved, 2009 is going to be an awesome year, I wish all the best!
I hope that because actually kde 4.1.87 sucks on my computer, is slow. I have a core2duo and an intel graphic card.
Ok, I'm only using 4.1.85 aka Beta2 on an Intel Atom with Intel graphic card and its fast enough. Speed is not the problem, here everything is quite stable (-> back to standard KDE-3 beta release quality) and featurewise its sooo much more complete than 4.1.3. But there is one top missing (notebook) feature: kbluetooth4 + bluez-4.x. I'm still searching for a working setup for kbluetooth4 and bluez-3.
Bye
Thorsten
I use trunk, it's very slow and plasmoids crash all the time. I really hope 4.3 will be better but given the state of 4.2, I'm afraid 4.4 will be the first great and usable release, not 4.3 :/ Kopete still needs a lot of work and no VoIP or video with jabber, konversation hasn't even been ported, khtml still don't work with big sites such as digg and google apps, amarok2 new playlist sucks (that will be fixed before 4.4 though), strigi/nepomuk is still very buggy (searching by tag don't return anything here) and no app uses them, kate is still buggy and lags a lot compared to gedit or textmate, kdevelop4 hasn't been released yet, digikam still very buggy etc.
So yes, KDE 4.2 and probably 4.3 won't be The release, anyway 4.4 should have most features back, more stability and will be faster thanks to Qt4.5, that's still a full year of buggy/slow desktop to cope with :/
> that's still a full year of buggy/slow desktop to cope with :/
What do you see buggy/slow about KDE 3.5?
:-?
You understand that KDE 4.2 is still in beta, right? So if anything crashes on your system, wait at least until the final release of KDE 4.2 before you say that it sucks.
BTW: Your user name suggests that you use Kubuntu. It's a well known fact that Kubuntu ships broken KDE packages. I use the trunk packages provided by openSUSE. While they are not flawless (KDE 4.2 is beta and the SUSE guys can't do magic), my KDE 4.2 experience is by far not nearly as bad as yours.
Whatever, I'm not going to change distros everytime KDE makes a release, also kubuntu packages for kde 3.x were great. I also heard that gentoo and mandriva package were buggy. So I blame it on KDE.
KDE does not make any packages. If you use in Kubuntu 4.2 beta2 from
dep http://ppa.launchpad.net/kubuntu-experimental/ubuntu intrepid main
you get also nearly upstream-stream quality packages. But you have to pay attention that you do not mix 4.1.2, 4.1.3 and 4.1.85 packages altogether: This leads to a crashy desktop. Its easy to overcome these problems using aptitudes problem solver.
But you do not get the qualitiy packages like you have as opensuse user for sure.
In Kubuntu you have to compile digikam 0.10pre and kdebluetooth yourself as these packages are too old or incompatible.
Bye
Thorsten
First of, if one distributions release packages with bugs not existing in other distributions or when compiling from source, the distribution is the right place to put the blame not KDE. That should be rather obvious.
When it comes to Gentoo their stability are always an issue, very depending on the specific options used when setting up the system. Getting a unstable system is easy.
As for Mandriva most sources report their packages of KDE to be excellent and among the best there is, so where you got your information from sounds rater suspect. On the other hand most reports of Kubuntu marks their packages as sub-par. Specially the KDE4 ones, but also the KDE3 ones had a generally bad reputation. The amount of distribution specific bugs also leads to suggesting the claims are true.
> the distribution is the right place to put the blame not KDE
No, if KDE makes it incredibly complex to build package so that even competent capable devs such as kubuntu's, gentoo's or else can't do it right then KDE is to blame. All packages on ubuntu are great except for KDE, same for gentoo and other distros. And all the packagers people I talked to always told me that KDE was a bitch to package, and that since KDE 3.X. I'm not saying KDE should provide packages, that the distro job, all I'm saying is they should make packagers job easier and they are obviously failing there. Blaming the distro for not getting an obviously too complex architecture that is KDE is doing it wrong.
And again you reveal yourself as a troll. If KDE are so hard to package, the Kde-buildsystem mailing-list should have been filled with request for improvements and pleas for help by packagers, but this does not seem to be the case.
And historically KDE has had a reputation to being rather easy to package, a evidence shown in that nearly all distributions with one or very few packagers chose KDE. And several get praise for the quality of their KDE desktops, for instance PCLinuxOS, Slackware, PC-BSD and DesktopBSD.
> And historically KDE has had a reputation to being rather easy to package, a evidence shown in that nearly all distributions with one or very few packagers chose KDE. And several get praise for the quality of their KDE desktops, for instance PCLinuxOS, Slackware, PC-BSD and DesktopBSD.
Does it include KDE4 packages?
Also does it mean that kubuntu packagers are incompetent? or that they are not numerous enough? There are like 15 so it should be enough, if 15 people are not enough than something must be wrong with KDE cause I don't think they're all incompetent, same goes for other distros that don't get good package for KDE.
Yes, that includes kde4. In Arch Linux, there is one guy maintaining all the KDE packages + most of the dependencies (and he only does it in his spare time), Pierre S. Then you have another guy making nightly KDE trunk snapshots, also by himself, Mark C. And then you have the kdemod project (or chakra), which consists of two core packagers for kde4 + two kde programmers (plus some packagers for kde3 and extragear programs). (All these are very well-maintained, and I can't remember hearing about any breakage they introduced.)
I won't comment on why the kubuntu packages suck, but debian packaging is unnecessarily complex, imho.
> Also does it mean that kubuntu packagers are incompetent?
Yes, their incredible incompetence is a well known matter of fact. They don't package kde, they 'pimp' it in a simply stupid way of thinking. I'm using Kubuntu for a long time, an 90% of all kde-probles can be solved just by removing the kubuntu-specific-packages (kubuntu-desktop-settings and such).
Ok, to be fair, half of the trash comes from ubuntu self, with their stupid translations-must-fill-into-our-stupid-system-philosophy and such.
As a mandriva 2009, KDE 4.1.3 user, I certify that the desktop is very stable. In fact more stable than opensuse 11.1, which I recently installed on a different partition.
As for kubuntu, I never gave it another thought, EVER. Yes, I tried it and it is shitty. No need to go by hype. And I didn't.
I am a serious linux user - I use linux at work AND home. Mandriva and opensuse get the job done. I've been doing this for years.
I generally found the kubuntu packages for kde3 broken in some way or another. And whilst I really like low level ubuntu (much nicer than bloated suse), their kde packages leave a lot to be desired.
Now if I could only find a decent stable debian based (or fast...without broken dns like suse) with decent kde packages I would dump opensuse too.
archlinux isn't debian based, but the package manager is excellent (and extremely fast, installing 204 packages took less than 10 seconds here, when the packages were already downloaded), and the whole distro is based on the "KISS" principle, which means that elegance and simplicity all the way to the bottom (from the linux kernel patches to the kde packages).
digikam, amarok, konversation, and kdevelop aren't part of KDE. They have their own release schedules.
Have you reported all bugs?
Because currently the bugfix rate is extremely high. There are really only very few crashbugs left on my computer, and i know that they come from an unpatched Qt.
So, please report the bugs, and 4.2 will be great. (well, it already is, but better is always good :-) )
How are the numbers for open bugs/wishes calculated? I've just noticed these numbers on commit digest from 21st Dec:
Open Bugs: 16362
Open Wishes: 14661
Bugs Opened: 481 in the last 7 days.
Bugs Closed: 700 in the last 7 days.
versus these from
Open Bugs: 16361
Open Wishes: 14661
Bugs Opened: 487 in the last 7 days.
Bugs Closed: 707 in the last 7 days.
As far as I have noticed, the numbers are not actually right if we take into consideration dates for which the digests are composed. Is this a small mistake on Danny's part or are there no means for querying bugzilla on open bugs in the past? Maybe some kind of a cronjob would help gathering proper statistics? This would improve accuracy of digests - even if composed with delays, the data could still be collected and stored for future use.
I am by no means complaining, just asking out of curiosity. I enjoy reading Danny's digests and wading through numbers.
//sorry for my bad english
bko (bugs.kde.org) appears to make an interesting calculation. Within the last 7 days
517 bugs opened were opened, 2127 bugs were closed that *should be a drop of open bugs below 14k.
though bko reports 16287 open bugs.
ah, yea, and whoever finex is, respecto. same applies to john layt & others, but what you did is beyond madness : )
finex closed most of the bugs as "WONTFIX" so this is not really fixing , but hey the database should be cleaned up right - please use the feature to autoclose bugs if the reporter does not care about the reported in 1 release cycle, to not have already resolved bugs there...
As I have said before, "Bugs Closed" is not a good metric, since it encourages bugs to be closed without a good resolution. In most cases, a good resolution is fixing them. So, I would suggest that "Bugs Fixed" be separated out so that we show:
Bugs Resolved Fixed
Bugs Resolved Other
a further note here that we don't actually close bugs since we have no QA department to do so.
The present figures for bugs closed have no real meaning since most of the bugs closed are KDE-3 bugs which are being closed because they are obsolete. They should probably be actually removed after they have been marked resolved for a year.
My guess is that the numbers are fetched when the digest is generated. With the short time between the digests the numbers don't change much.
So you finally caught up! Great! Thanks, Danny, for your amazing work!
http://www.picturepush.com/public/1296385
well done, sir, well done!
So when are we going to nail down showstoppers in plasma, kded, file opening freezing plasma and thus rendering the system inoperative?
I leave the latest SVN in an unused mode triggering the kscreensaver and within 20 minutes I've got 2 or more knotify bug errors.
Of course, you are familiar with http://bugs.kde.org
If the devs are not able to detect these bugs that are so obvious and so annoying to anyone who has tried 4.2, then really kde is hopeless.