Friday, June 12, 2009

beta cycle

Today 38 new defect reports were opened against Plasma; that's one third the number of the entire previous six days. People are really pushing on the betas and we're getting great feedback and reports. It's really helping to increase the quality of what will become 4.3.0, and we're managing to stay half a step ahead: 49 reports closed today, 142 over the last week.

There have been some duplicates, but remarkably few for the volume. The rapid turn around time between betas is helping there, I think. People who tried beta1 have generally upgraded to beta2 now and people joining in on the testing are on beta2 which included a bunch of fixes over beta1. The result is new issues being reported, not the same old ones. Much thanks to the release team for helping improve this part o the cycle.

The new crash reporting system in 4.3 is also really coming through and helping people with their reportig. I can't really call it a "crash dialog" anymore since it does so much more than that. The results are already evident, at least to me: the quality of backtraces is up, the consistency of the reports is much better (it's rare to get a report without a "what I was doing" section now) and I've even had some direct feedback on how much nicer the new dialog is from reporters.

Some very long standing crashes and numerous "annoyance" bugs have been cleared out already, and we have several weeks yet to go!

For those reporting issues, if you haven't read the How To Create Useful Crash Reports page yet, please do so. There are some great tips in there.

Things aren't all perfect, though. Like every project on the planet, we only have so many human resources, and 4.4 development started a bit early on us due to a combination of Google Summer of Code / KDE Season of Code and some strategic projects around netbooks that have timed themselves "just right". Most of the team is spending most of their time now on things that will land in 4.4; given the "must have" nature of these things and the relative complexity of some of them, I decided yesterday to adjust our bug count target for 4.3.0 to give the team a freer hand to work on these 4.4 issues.

We still have a target goal and 4.3.0 will be an outstanding release, it's just a bit more reasonable given our priorities for 2009. A number of our team showed up on IRC today and helped slay the dragons as they rolled in, so there's still a lot of attention being paid to polishing up 4.3.0 for the release.

On a side note, one thing that I have found a bit frustrating is that we don't have a branch to work on stabilization in. That means that bugs that require string changes, for instance, can't be made and I have to just remember to come back to them once 4.4 devel opens up. I really think we should branch for stabilization and leave trunk "open"; this is that whole "always summer" concept and I'm missing it more and more as time goes on. :) There is the social problem of making sure that people spend time on stabilization, but that is a social issue and one that we've managed to strike a very fine balance on in Plasma, though what the balance is varies from release to release in accord with our goals.

To really make that happen requires, I think, something other than svn into the mix. Chani has done some much needed work on the translation workflow and now scripty works with git. Michael Pyne also found time to make kdesvn-build (will one day become an anachronism of a name? :) to work with git repositories as well. So we're making progress on that point, getting some of our pieces of infrastructure into place so we have the choice to move when the time is right for us as a project.

There's still much to do, including documentation for KDE contributors so we don't experience unnecessary slow downs during transition (I think this is trebley true for the translation team efforts), hooks between our bugzilla installation and git and then the actual move-the-svn-repos (though Thiago has done a lot of work on that already).

Never a dull day in KDE. :)

On a more personal note, I bought some wonderful parchment paper the other day and some terrific inky black pens to write with. It's been a while sice I sat and wrote my personal thoughts down in this manner. I use pen and paper for software design and writing presentations quite often, but I've fallen out of the habit of putting my inner meanderings down in some form. Last night I was struck by the urge to write some verse, in fact, though I got no further than some music on the stereo and the strings on my guitar. :)

7 comments:

mpyne said...

Aaron, if you think kdesvn-build is an anachronism, you should have seen its predecessor, kdecvs-build. ;)

(The only reason it was kdecvs-build and not simply kde-build was because there already was a "kde-build").

I may just end up renaming it kdesrc-build or something, who knows...

Ahmed Kamal said...

Hi Aaron,
Thanks for the awesome work you're doing for KDE. I've been using KDE since v1! and till now love every single bit of it. However, I am recently getting annoyed by KDE-4 (which is still awesome), because it simply is getting slower. KDE-4 is slow! I have no scientific experiments to prove it, but all of my co-workers agree (compared to Gnome). Don't get me wrong, I absolutely applaud the excellent work done in getting KDE4 in shape. I love the features and looks of KDE4 over Gnome, however, I cannot help but feel it simply is slower. Can the KDE team start some kind of a performance optimization team perhaps ? Do we already have something like that ? Once again thanks a million guys for the amazing work

biophysics said...

I compiled trunk yesterday with the help of kdesvn-build and it is running great.

Aaron J. Seigo said...

@Ahmed: it's obviously easier to make something without features faster ;), but the most common cause for slow downs in plasma is graphics driver performance. unfortunately right now not all graphics drivers are improving in performance. hopefully this sorts itself out eventually.

there have been a lot of optimizations between 4.0 and 4.3, though i'm sure there's still room for improvement in places.

profiling, patches, etc all welcome.

at least here, 4.3 with current Qt feels faster than any of the previous releases. *shrug*

Shantanu said...

Right, The bug report tool is really awesome. Its simple and straightforward.
Looking forward when KDE moves to git.
@Ahmed
Maybe not a big piece of advice, but try suspending compositing by Alt+Shift+F12. That should help speed up the performance. (Though it'll disable some of the things like transparency etc)

josericardo said...

Hi Aaron,
Now that you mention git, I wanted to ask you why kde still hasn't adopted git as its scm. To my mind it should be more reliable and would speed up kde development even more.

Michael Meier said...
This comment has been removed by the author.