Announcement

Collapse
No announcement yet.

KDE SC 4.7 Release Candidate Hits The Web

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    Originally posted by RealNC View Post
    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.

    Comment


    • #77
      Originally posted by BlackStar View Post
      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.

      Comment


      • #78
        Originally posted by energyman View Post
        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.

        Comment


        • #79
          Originally posted by RealNC View Post
          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).

          Comment


          • #80
            Originally posted by BlackStar View Post
            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?

            Comment


            • #81
              Originally posted by RealNC View Post
              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?
              Sorry, but the burden of proof lies with you. It was you who said that MALLOC_CHECK is erroneously enabled in the RC. Where's your source for that?

              Comment


              • #82
                Originally posted by BlackStar View Post
                Sorry, but the burden of proof lies with you. It was you who said that MALLOC_CHECK is erroneously enabled in the RC. Where's your source for that?
                http://lists.kde.org/?l=kde-devel&m=130979982709904&w=2

                Comment


                • #83
                  Ah then, it's official, release candidates shouldn't have the checks enabled.

                  Anybody else think that the KDE release process is a mess? The 4.6.4 tarballs contained 4.6.1 source (and other random stuff), now this. They needed a user to point out the issue! Maybe they should sit down, discuss and try to streamline things a bit.

                  Comment

                  Working...
                  X