KDE SC 4.7 Release Candidate Hits The Web

[RealNC]

MALLOC_CHECK 3 IS a good choice.

You don't believe? Use google for fsck sake!

ORLY? A development/debugging setting that slows down execution of every application, sometimes up to 25% or more, is a good choice for end-users? If you have used Google yourself instead of only telling others to, you would have found that this is supposed to be enabled only for betas and snapshots of KDE, not for release canditates.

So with when problems arise a warning is printed and the program aborted.

Which is a WISE CHOICE for test candidates like alphas, betas and release candidates.

No, for RCs it is not.

Question: why do YOU think it is a bad choice? Please with complete sources.

Because of the runtime overhead that makes the whole system go slower? OK, your opinion is that KDE should enable this for Firefox, mplayer, VMWare, VirtualBox, and every other app I have installed and which isn't part of KDE itself. It's your opinion, and you're entitled to it. Me, I think it's a retarded opinion. And I'm entitled to it too.

[RealNC]

I really can't be bothered to check

Oh, so typing "env | grep MALLOC_CHECK_" is too much of a bother. OK. And also, you think it's a good idea, but then you don't go ahead and enable it globally? Gee, why is that?

[energyman]

Regardless of whether it's a good choice, a KDE startup script is not the right place to make that choice for non-KDE apps.

have you checked that your distri does have the same entry? Or that it isn't set globally?

[energyman]

ORLY? A development/debugging setting that slows down execution of every application, sometimes up to 25% or more, is a good choice for end-users? If you have used Google yourself instead of only telling others to, you would have found that this is supposed to be enabled only for betas and snapshots of KDE, not for release canditates.



No, for RCs it is not.


Because of the runtime overhead that makes the whole system go slower? OK, your opinion is that KDE should enable this for Firefox, mplayer, VMWare, VirtualBox, and every other app I have installed and which isn't part of KDE itself. It's your opinion, and you're entitled to it. Me, I think it's a retarded opinion. And I'm entitled to it too.

ooh.. you are missing the point that for the env-variable to take effect there must be code in the apps to make use of it.

Hmmm...

and yes, for rcs it is a wise choice. Release Candidates are nothing but test releases. Debugging is THE reason to release them. So turning on an option to help debugging is a sane and wise choice.

You install test releases, you should be prepared to see debug overhead, bugs and crashes. And report them. The debug overhead disappears with the release. This is good release managment.

[RealNC]

ooh.. you are missing the point that for the env-variable to take effect there must be code in the apps to make use of it.

You're wrong. It checks all programs unconditionally. The program is not required to provide any kind of special code.

and yes, for rcs it is a wise choice. Release Candidates are nothing but test releases. Debugging is THE reason to release them. So turning on an option to help debugging is a sane and wise choice.

You install test releases, you should be prepared to see debug overhead, bugs and crashes. And report them. The debug overhead disappears with the release. This is good release managment.

You seem to have zero idea about what you're talking about:

http://web.archiveorange.com/archive/v/ZyOjP2htlRigNFJfp1QX

"trunk" is a long way from "RC".

Also, I don't see you comment on the fact that this enabled runtime checks for the whole system instead of only for KDE. Join my mental club of people with silly ideas.

[BlackStar]

Oh, so typing "env | grep MALLOC_CHECK_" is too much of a bother. OK. And also, you think it's a good idea, but then you don't go ahead and enable it globally? Gee, why is that?

Argumentative as always. I am using a stable release, so this is disabled as expected.

"trunk" is a long way from "RC".

Also, I don't see you comment on the fact that this enabled runtime checks for the whole system instead of only for KDE. Join my mental club of people with silly ideas.

You are just being silly now. He never mentioned "trunk" he said that release candidates are there for testing and it's a good idea to gather crash reports on those.

If you install a release candidate you are expected to report bugs. Enabling this option ensures that misbehaving applications will crash, exactly so you can report those bugs.

It is obvious that you installed a release candidate thinking it is a final release. In short, PEBKAC.

[RealNC]

If you install a release candidate you are expected to report bugs. Enabling this option ensures that misbehaving applications will crash so you can report these bugs.

So you're saying I'm expected to report VirtualBox crashes to bugs.kde.org? Because that's what happens if KDE enables this var globally.

It is obvious that you installed a release candidate thinking it is a final release. In short, PEBKAC.

Well, please show me where it says that this var is supposed to be enabled on non-developer versions of KDE (like non-debug builds of RCs). Because all info I can find says it's intended for trunk and snapshots. Also, please look up the meaning of "candidate" in a dictionary. "Release candidate" means an actual candidate for release. Candidate. To be released as-is in the (unlikely event) there are not bugs reported against it.

[Ex-Cyber]

have you checked that your distri does have the same entry? Or that it isn't set globally?

I'm not sure how that's relevant. The distro vendor legitimately does have that prerogative, just like they get to decide whether to e.g. ship a tickless kernel by default. If you think that's a potential confounding issue with the bug report (which is not mine), you should address it to the bug report.

[BlackStar]

So you're saying I'm expected to report VirtualBox crashes to bugs.kde.org? Because that's what happens if KDE enables this var globally.

Are you 100% certain the issue is not KDE-related? If yes, report it to VirtualBox. If not, report to KDE.

In both cases, *report it* so it can get fixed. Duh.

Well, please show me where it says that this var is supposed to be enabled on non-developer versions of KDE (like non-debug builds of RCs). Because all info I can find says it's intended for trunk and snapshots. Also, please look up the meaning of "candidate" in a dictionary. "Release candidate" means an actual candidate for release. Candidate. To be released as-is in the (unlikely event) there are not bugs reported against it.

Different projects have different approaches to the release process and "release candidate" is interpreted according to the selected approach. You are over-generalizing, as always.

Would KDE plan for two release candidates and 4+ weeks of testing a priori, if they thought the release candidate was bug-free and ready for release? No. They are expecting issues, which is why MALLOC_CHECK is enabled in the RC.

Contrast for instance with Opera: RC is out today and if no blocking bugs are reported then that RC is promoted to final *tomorrow*. One day. If bugs are found then another RC is released and this process is repeated as many times as necessary (5, 6 or more).

[RealNC]

Would KDE plan for two release candidates and 4+ weeks of testing a priori, if they thought the release candidate was bug-free and ready for release? No. They are expecting issues, which is why MALLOC_CHECK is enabled in the RC.

I already asked multiple times but you don't answer: Show me where it says that. "Which is why MALLOC_CHECK is enabled in the RC". WHERE does it say that? How do you know that? Where did you read that?