KDE 4.3 Beta 1 Signals Beginning of Bug Hunting Season

The first beta version of the new and shiny KDE 4.3 has been released. The list of new features and improvements is long and impressive as ever. There is a new tree view mode in System Settings, many cool new features, the desktop search becomes more visible to the user, and yet more polishing in user interfaces all over the place make using KDE more fun. Interesting infrastructural bits are the integration of geolocation services into Plasma and Marble, a couple of nice improvements for KAlarm, the notification icon for your calendar. Apropos, the calendar in the clock now shows you holidays. More work down there in the panel brings the option to have the panel cover windows, to accurately align your panel using the new spacer. While KDE 4.3 already looks nice and stable, the KDE team wants to shake out as many bugs as possible before KDE 4.3.0 will be released in late July.

Get in gear ready for test-driving KDE 4.3 and help us ironing out kinks for everybody's KDE pleasure.

Dot Categories: 

Comments

For (K)(X)(ED)Ubuntu use this repo:
deb http://ppa.launchpad.net/project-neon/ubuntu jaunty main

Then you can install KDE 4.3 alongside KDE 4.2.
(Install the kde-nightly package or something).

For kde , they should consider a longer release cicle, for example making RC2 RC3 and so until gets solid rock, and then RTM or something like, that.

Making only one RC1 will cause KDE 4.3.0 not be solid rock system as many of us expect.

Anyway Kde 4.3 beta 1 is in right direction, = D

Did you read what Christoph said above? (His post title was "Feature Freeze", unfortunately the new dot does not create links to comments.) It's absolutely impossible to kill all bugs, because, for example, developers lack resources to reproduce many bugs that depend on configuration.

Also, some bugs emerge from programs being in a transition state to a better solution (one example being System Settings which did not yet get Administrator Mode because they want to do it the right way with PolicyKit).

A similar argument applies for some bugs and also some crashes: Developers might already know how to fix them, but they would possibly introduce even more bugs through a hacky solution.

So there can be numerous reasons why a bug does not get fixed in the first place. The last and most important reason is lack of manpower, but we cannot solve that. There is a saying that "assigning more workers to a delayed project delays it further", which is quite true: New developers have to find their way into the program, which may consume the time of the old devs who have to explain things to them, or the new devs might break stuff without noticing, thereby introducing even more bugs.

As you see, there is no way to get bug-free software with just a longer release cycle. Our release cycles already consist of one third feature freeze. Even more could be counterproductive, as it lowers the motivation of the developers significantly. I hope you understand this reasoning.

Yes, hunt bugs if you want to, but don't waste your time filing a bug report.

Because, it is quite probable that a developer will immediately post a lame excuse for why it isn't a bug. The latest variation on this is claiming that things that are obviously bugs are "Wish List" items.

See:

https://bugs.kde.org/show_bug.cgi?id=195837#c1

I think that this can be restated as I (AJS) didn't design this correctly so your are just wishing that it had been done correctly.

Perhaps the bugs are all wishes. :-D

Actually, whether this was a design error or a coding error, it is still a bug.