JAN
19
2004

KDE 3.2 Reaches Final Stage: Announcing Release Candidate 1

After over a year of development we're ready to announce the release of the first (and hopefully last) release candidate for KDE 3.2.0. Get it from download.kde.org or use Konstruct if you don't feel like calling configure by yourself. Due to the time constraints, don't expect distribution binaries, but they may pop up at download.kde.org URL too.

Comments

Who the hell is Drantin?


By planetzappa at Tue, 2004/01/20 - 6:00am

Ah, i see, the poster above... Sounded like some celeb or whatnot. Never mind!


By planetzappa at Tue, 2004/01/20 - 6:00am

it (KDE) is in your hand, your eye, your computer;
marketing is not in CS's mind; they only see "bugs" flying around their heads and codes jamming computers.
if you want details, look inside the source code; if you want detail feeling, catch yourself a mouse.


By details at Wed, 2004/01/21 - 6:00am

Well, 3^2+2^2=5^2

So there.


By Dmitry at Wed, 2004/01/21 - 6:00am

9 + 4 = 25? :/


By Cwiiis at Wed, 2004/01/21 - 6:00am

I think maybe you were thinking of the 3/4/5 rule...
It's actually 3^2 + 4^2 = 5^2


By Erik at Tue, 2004/01/27 - 6:00am

I remember reading the release schedule back in mid-2003 and they were shooting for a mid-December release. They changed it, and that's why it's on time.


By Turd Ferguson at Tue, 2004/01/20 - 6:00am

Now it's aimed for February release, maybe February 5th ;)


By Mario at Tue, 2004/01/20 - 6:00am

Great release! ;-)
Just a little thing: i can't set anymore the kind of shadow from ~/.config/kdesktoprc
...it doesn't work... and the default is "ugly" :p .
Anyway this is great!!! :-)


By Giovanni Venturi at Mon, 2004/01/19 - 6:00am

IT better not look this crappy in 3.2 final. We should have a nice MAcOSX, Nautilus, Windows XP style shadow.


By Mario at Mon, 2004/01/19 - 6:00am

Yes, anyone know the story behind the shadow? Why is it so bad? How to fix?


By ac at Mon, 2004/01/19 - 6:00am

This shadow thing, what's it all about? Is it good, or is it whack?


By Bob at Tue, 2004/01/20 - 6:00am

whack. It doesn't even look like a shadow.


By Alex at Tue, 2004/01/20 - 6:00am

The kdesktop icon text shadow was incorporated from a patch originally posted on kde-look.org. Here's the link: http://www.kde-look.org/content/show.php?content=4750

There are parameters that you can tweak to adjust the characteristics of the shadow, and up to KDE 3.2.0_beta2 they were located in ~/.kde3.2/share/config/kdesktoprc.

Since I installed KDE 3.2.0-rc1, changing the parameters don't seem to work anymore. Can anyone post the contents of their kdesktoprc file?


By Wilbur at Thu, 2004/01/22 - 6:00am

I've been running HEAD since Saturday evening and so far it's fantastic. All the glitches I had from the previous version are gone. I see a lot of polish and I definitely see speed improvements. I doubt another RC is needed.

That default gray/gears background isn't very good IMHO. Not only is it drab, it's harsh. Also the default desktop font shadow isn't anywhere good as the Nautilus desktop shadow. I'm not sure if this can be tweaked or not. I also think we should probably default to the Bitstream Vera fonts everywhere. Oh yeah, and Konsole should default to Linux Colors. :-)

The Dot frontpage looks like it lost some whitespace in Konqueror. There's very little space at all between the "comment number" line and the title of the next item. There should be a

. Otherwise, Konqueror seems fantastic and all my other bugs are gone.

More serious gripe: Cut'n'paste glitches sometimes when selecting in Konsole and pasting in Konqueror it doesn't quite work... behavior seems random -- rare but it happens. Also KDE stole my Control-A (beginning-of-line) for no good reason at all since it doesn't work. Ctl-A selects the whole text and yet does not put it in the paste selection even after pressing Ctl-C (does not paste with Middle Button nor Ctl-V). That's it for bugs, but I think this one is the most serious and annoying.

Otherwise, I'm a real happy camper and I want to see this release adopted widely ASAP. :-)


By Navindra Umanee at Mon, 2004/01/19 - 6:00am

Have you tried to start after prelinking kde?
I also made a clean install in a new /usr/kde/3.2 dir and after prelinking I could not start kde. There were kdeinit startup problems and lost dcop communication. Startup crashed at 28%.

My test was done with HEAD and qt-copy not with 3.2_BRANCH.

Bye

Thorsten


By Thorsten Schnebeck at Mon, 2004/01/19 - 6:00am

I didn't do anything special like that. What do I need to do to prelink my KDE? (I'm on Mandrake 9.2)


By Navindra Umanee at Mon, 2004/01/19 - 6:00am

Here is Gentoos Prelinking Howto, should be valid for Mandrake, too.
If you use NVidias binary driver you have to compile Qt with the (new)
-dlopen-opengl configure option (I *think* this option is qt-copy only, so far)

http://www.gentoo.org/doc/en/prelink-howto.xml

+++
3. Prelinking - Prelink Usage

I use the following command to prelink all the binaries in the directories given by /etc/prelink.conf.

# prelink -afmR

Warning: It has been observed that if you are low on disk space and you prelink your entire system then there is a possibility that your binaries may be truncated. The result being a b0rked system. Use the file or readelf command to check the state of a binary file. Alternatively, check the amount of free space on your harddrive ahead of time with df -h.

The options explained:
-a "All": prelinks all the binaries

-f Force prelink to re-prelink already prelinked binaries. This is needed as prelink aborts if old prelinked files are present and their library dependencies have changed.

-m Conserve the virtual memory space. This is needed if you have a lot of libraries that need to be prelinked.

-R Random -- randomize the address ordering, this enhances security against buffer overflows.

Note: For more options and details see man prelink.
+++

Bye

Thorsten


By Thorsten Schnebeck at Mon, 2004/01/19 - 6:00am

Doesn't mandrake already prelink their binaries? I thought they did (like Redhat) which caused the great load times...


By rsk at Tue, 2004/01/20 - 6:00am

"I also think we should probably default to the Bitstream Vera fonts everywhere."

Yup, they got added in XFree 4.4 so that would be a nice default.


By bugix at Tue, 2004/01/20 - 6:00am

I agree with everything you said except the wallpaper and konsole statement. Can't wait for KDE 3.2 on February 5 (3+2=5) Please release it on the 5th.


By Alex at Mon, 2004/01/19 - 6:00am

How about Feb 3ed? (03/02/04) for kde 3.2? :)


By kormoc at Tue, 2004/01/20 - 6:00am

all is in the title


By William at Mon, 2004/01/19 - 6:00am

Right now it seems that KDE 3.2 is just too buggy, I think it should have a RC2 and have a mid February release date, otherwise I will consider it a rushed product.

Check the statistics for yourself, sure bug counts aren't all tat important, but when this late in the release cycle there is such a huge spike in new and unconfirmed bugs, you know there is something wrong. Besides, the goal for 3.2 was to have a release with under 3,000 (2,500 was planned) bugs, now it seems the new goal is under 4,000.

Bug chart here http://tinylink.com/?OdDme9ObFk

Notice how last year for KDE 3.1 the number of unconfirme dbugs and new bugs went straight down as if freefalling, this is how it should look for 3.2, but instead it shows a large increase in bugs, not a decrease as is normal.

I want KDE 3.2 to rock and right now on my system it just isn't where is should be a this stage in the cycle. To make KDE rock it needs at least one more RC. From what I've done on software development I know that the RC should be released when you think everything is the way you want it to, because when you think everything is like you want it to be, you will notice in the RC, that it's not quite there yet mos tof the time. But sometimes, like for Linux kernels, the RC becomes final because it really is where it should be.

Thank you, please consider a RC2 for a good 2-3 weeks more.


By Mario at Mon, 2004/01/19 - 6:00am

Did you tried RC1 ?
It's stable, no crash of konqueror or others apps.

All my bugs from beta2 are gone. But they still open in the bug database. Probably duplicates or somebody didn't closed them. There are many reasons why there are many opend bugs.

But the current rc1 is ready for primetime


By JC at Mon, 2004/01/19 - 6:00am

>But the current rc1 is ready for primetime
Sure? Is e.g. this showstopper ( http://bugs.kde.org/show_bug.cgi?id=70070 ) fixed in rc1?


By Carlo at Mon, 2004/01/19 - 6:00am

Your bug is neither confirmed nor marked as critical. So I guess the developers have a hard time to reproduce it.

Also I'm pretty sure that they need more information from you like your language and locale settings.


By Anonymous at Mon, 2004/01/19 - 6:00am

1) It's not a locale problem.
2) The involved devs speak german, but even if not, everyone should be able to translate JJJJ to YYYY in this context.
3) It doesn't matter, if the bug is marked critical or not, if the user experience sucks.


By Carlo at Tue, 2004/01/20 - 6:00am

> 1) It's not a locale problem.

But it seems to be at least a local problem since I never experienced anything like this. So the developer surely does need more information from you about your setup.

> 2) The involved devs speak german, but even if not, everyone should be able to translate JJJJ to YYYY in this context.

Of course but that's not what I meant. Talked about your language and locale _settings_.

> 3) It doesn't matter, if the bug is marked critical or not, if the user experience sucks.

I'm sure it sucks. I'm also sure that the developer works on this as fast as possible, but you were talking about a _showstopper_ that should delay the release. IMHO this is not the case.


By cloose at Tue, 2004/01/20 - 6:00am

>But it seems to be at least a local problem since I never experienced anything like this.
Play around in KOrganizer, setting the month and years a few decades forth and back, open the print dialog and you should be able to share the problem.

> Talked about your language and locale _settings_.
Still wondering what it could have to do with it.

>[...]but you were talking about a _showstopper_ that should delay the release. IMHO this is not the case.

_showstopper_ not from the technical standpoint (it's a trivial bug, rm -rf ~\.kde and i'll get the date shown again - I hope so at least), but from the user standpoint it simply sucks. Think about opening kicker->clock->calendar and watching the date 01.DD.YYYY, searching for an email by date and all of them are formatted like this...

I could mention other things. Freezing kde, when noatun opens empty or broken audio files, lost settings of open kde applications, on next restart after kde had to be killed, ...


By Carlo at Tue, 2004/01/20 - 6:00am

~/.kde of course ;)


By Carlo at Tue, 2004/01/20 - 6:00am

please list the bug numbers..


By anon at Tue, 2004/01/20 - 6:00am

I think that the following bugs should be solved before 3.2

CRASH: Bug 72775: CRASH: printing message in draftfolder

Bug 70418: [test case] table height=100% gives strange gaps (regression)

(this one prevents me from using the web interface of my company's
Novell email system68921

Bug 68921: Marking text with keyboard disables keyboard input )

This one makes it very hard to edit something in a box on a web page.

I could go on...

For example there are quite a few webpages where the javascript does
not work or even whole javascript menus do not show up.
Mail me (see the bugs for my email address) if you need examples.


By John van Spaandonk at Wed, 2004/01/21 - 6:00am

> no crash of konqueror or others apps

Konqueror crashes for me.

I have filed several other bug report for the branch.

Yes, it still needs a little work.

--
JRT


By James Richard Tyrer at Fri, 2004/01/23 - 6:00am

> I think it should have a RC2 and have a mid February release date

Another RC would be not about greatly reducing the amount of bugs. In fact only showstopper bugs are allowed to be fixed now in KDE_3_2_BRANCH until release.

> otherwise I will consider it a rushed product.

Silly, it's already delayed by almost two months.

> but when this late in the release cycle there is such a huge spike in new and unconfirmed bugs, you know there is something wrong

Sure, users delaying their reporting of bugs they know since Beta1/Beta2 until one week before release.

> Notice how last year for KDE 3.1 the number of unconfirme dbugs and new bugs went straight down as if freefalling

That was the time when the bug system was switched and many duplicates and old bugs were closed. Did you also notice how until the release of KDE 3.1 in January 2003 it almost climbed up back again?

> To make KDE rock it needs at least one more RC.

No, it needs KDE 3.2.1, 3.2.2, 3.2.3, ...

> the RC should be released when you think everything is the way you want it to

Then we would see never see a release.


By Anonymous at Mon, 2004/01/19 - 6:00am

> > To make KDE rock it needs at least one more RC.
> No, it needs KDE 3.2.1, 3.2.2, 3.2.3, ...

Exactly,
- To buggy to be released as stable. Too many minor bugs and annoying issues.
- Will only be stable enough after the release . It needs time and actual use to mature.

IMO the obvious solution is quite simple actually.
Keep the process, change the names. The 1st release (with binaries and all), after the short sequence of RCs should still be called a RC and not a .0 version. It would have a lifetime of 1-2 months and then the equivalent to .1 would be the .0 release.


By Source at Mon, 2004/01/19 - 6:00am

This won't work. Fact is most people don't even test RCs (ask Linus).


By Anonymous at Mon, 2004/01/19 - 6:00am

Yes it will. Fact is most people do (ask the Mplayer team).


By Source at Mon, 2004/01/19 - 6:00am

People are way more likely to use the RC's for something like Mplayer then for something like KDE or a kernel. The reason? What is the worst thing that happens if Mplayer doesn't work right? You can't watch videos, big deal.

If your kernel has major issues, or the system of which you most often use to interface with your computer has major issues, it is a lot bigger deal. There is a reason why the kernel is never ready in a .0 release and that is because the user base of a kernel goes up by a factor of 10 or more as soon as they make a .0 release. Why do you think every kernel has a rush of bug fixes at the begining and it settles out as time goes on and there are a lot fewer releases.


By jts at Tue, 2004/01/20 - 6:00am

"People are way more likely to use the RC's for something like Mplayer then for something like KDE or a kernel. The reason? What is the worst thing that happens if Mplayer doesn't work right? You can't watch videos, big deal."

I know that. I was beeing sarcastic.
They're more likely to use Mplayer than KDE, just like they're more likely to use KDE than the kernel. I was just using his distorted reasoning.


By Source at Tue, 2004/01/20 - 6:00am

MPlayer has never had a stable release in their whole project lifecycle. So, yes, if people want to run MPlayer at all they are forced to run one of the eternal "release candidates".


By Jan Ekholm at Tue, 2004/01/20 - 6:00am

This is completely wrong!

Please do not confuse stable and numbered 1.0. The 0.90 was stable. Only bugfixes/minor enhancement were done to the serie, while there was a development branch aside (called "main").

Just having add a look at Mplayer's news archive page would have given you facts instead of attacking Mplayer with blatant mistakes (or was is a lie?)

For example the annoucement for 0.90:

" 2003.04.06, Sunday :: Finally! MPlayer 0.90 released!
posted by Gabucino
459 days have passed since we released our last "stable" release: MPlayer 0.60 "The RTFMCounter"."


By oliv at Tue, 2004/01/20 - 6:00am

You're aware that your "bug charts" contain feature requests, aren't you?


By Stephan Kulow at Mon, 2004/01/19 - 6:00am

I use kde 3.2 10 hours a day 5 days a week for heavy development and it is more stable/efficient than kde3.1, gnome-2.4 or WindowsXP ever since beta1.

-> No crashes
-> lisa, fish, smb are seamless now
-> konqueror is very fast
-> KDE 3.2 now loads faster than winXP and gnome.

I know several people that I work with have had great experiences with it so far. If you are having problems check your cflags, glibc and gcc versions or report a bug. Unfortunately many people who mean to help be reporting bugs inadverntantly submit user errors as opposed to actual bugs. It is usually a bad idea to base the stability of an app based on the number of reported bugs.

One good explanation for the increase in bugs in the increase in user base, particuarly newbies ;) We can only hope...


By moe at Mon, 2004/01/19 - 6:00am

=p


By Mario at Mon, 2004/01/19 - 6:00am

"but when this late in the release cycle there is such a huge spike in new and unconfirmed bugs, you know there is something wrong."

What makes you say that? Let me guess: Since there was a spike in number of bug-reports, you automatically assume that it means that there are more bugs, right? Well, it hasn't occured to you that the spike may be due to:

a) There were more users reporting bugs
b) Those bugs had been there for a long time already, but they were just now being discovered
c) due to part a), there were lots of dublicates
d) Due to having more users, there were more wishes (wishes are reported in bug-reports as well)

None of those are bad. Just because number of bug-reports go up does NOT mean that the code is magically becoming buggier. It just means that more people are reporting more bugs.

If I release some app, and to my knowledge it has zero bugs. After two weeks, I have received 20 bug-reports. During those two weeks I haven't touched the code at all. According to your logic, my code would have somehow magically transformed to contain those 20 bugs, when in reality they were there all the time, I just hadn't noticed them.

If you run KDE today, and next week there are (for example) 100 new bugs being reported, it does NOT mean that the KDE on your hard-drive has somehow magically become more buggier.

To my knowledge, Mozilla has over 10.000 reported bugs, and that's just for one app!


By Janne at Tue, 2004/01/20 - 6:00am

> To my knowledge, Mozilla has over 10.000 reported bugs, and that's just for one app!

it had more than 100,000 last time i checked, which was over a year ago


By anonanon at Tue, 2004/01/20 - 6:00am

Perhaps the version numbers should be determined objectively =P

e.g. version = target version - ceil ( (bugs opened - bugs closed) / n ) + c


By Anonymous at Wed, 2004/01/21 - 6:00am

You would expect an increase in bug reports when a project moves from beta to RC status simply because more users will try it at that stage. Similarly, I'd expect another spike in bug reports when it goes from RC to final. I'm not saying you're wrong about RC1 not being ready though - just arguing with your point about more bug reports implying something has gone wrong.
But even 3.2.0 will probably not be a totally satisfying end-user product, just because until it's had a lot more hammering there will still be bugs to work through. It'll really start to get that hammering when 3.2.0 is out and more people try it (hopefully debian/unstable will have it pretty quickly).


By Adrian at Thu, 2004/01/22 - 6:00am

Pages