The CADT Model

Today a bunch of the outstanding bugs I'd reported to the Gnome propellerheads in the last couple of years were closed as follows:

Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If y0u feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...

This is, I think, the most common way for my bug reports to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.

I'm so totally impressed at this Way New Development Paradigm. Let's call it the "cascade of attention-deficit teenagers" model.

Tags: , ,

23 Responses:

  1. ivorjawa says:

    Just think how well a 17" powerbook would complement the decor of the DNA lounge.

  2. sachmet says:

    On the other hand, at what point does this become an acceptable response? If someone writes a module that blows chunks, and 250 distinct bug reports get filed against it, is it that dev's responsiblity to verify each and every one, refiling as necessary? How about at 500? 1000? More?

    Look at bugzilla for mozilla - all the UNCONF reports that are in there. While there is a horde there to do dupe checking wherever possible, does or should a dev, especially one giving his free time, care to wade through 2500 bug reports and refile the <1% that still matter, if they rewrite a module? Or is it safe at some point to depend on regression testing by users to determine if a problem still exists?

    Don't get me wrong, I'm not saying it's OK to ignore old bug reports. But your reports (assumption: they were filed for 1.4) - and everyone else's reports on 1.4 - who is going to sit there and re-test every bug forward for verification?

    Not enough hours in the day.

    • jwz says:

      It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?

    • thesliver says:

      There's an awful lot of WONTFIX as well where WONTFIX means its politically incorrect (in mozilla's terms) to fix them.

      • Since it's open source ... can't you just fix it yourself? I mean, sheesh ;)

        jwz: In any practical sense, is there that much of a difference between waiting 2.75 years for a security bug to get fixed ( and never getting it fixed at all? (Unlike the first paragraph, that wasn't sarcasm; I'd like to know your opinion.)

        • grahams says:

          I wouldn't consider it a security bug, but I agree it seems like it took too long to fix...

        • thesliver says:

          The problem with fixing something that the drivers don't care about or explicitly don't want is that you create your very own fork with all the junk that entails. Sometimes WONTFIX is fine, sometimes though its just a synonym for DONTCARE.

        • jwz says:

          is there that much of a difference between waiting 2.75 years for a security bug to get fixed, and never getting it fixed at all?

          There may not be an immediate practical difference to the user, but the attitude behind it matters: maybe the developer thinks it's ok to just ignore old bugs: that's often true, and that's really bad. But then, maybe the developer doesn't think that, but instead, the project is just totally floundering: that's also often true, and easier to forgive. In the latter case, at least they'll be trying to fix the problem; in the former case, they don't think there is a problem.

    • rpkrajewski says:

      We're all told that the Open Source paradigm favors a path that fixes bugs over one that adds flashy new features. Ha ! Really, I think only getting paid for fixing bugs fixes bugs.

      I happen to be working on a product which is is a complete rewrite, and I'm actually looking forward to marking all kinds of old stuff "resolved" in the new version. But only because I'm getting paid, I admit.

      • jlindquist says:

        We're all told that the Open Source paradigm favors a path that fixes bugs over one that adds flashy new features.

        No, Open Source enables a path that fixes old bugs. If it's important enough to you, you can fix it yourself. I think the core of Jamie's complaint is the Gnome folks seem almost totally disinterested in fixing bugs, to the point it seems irrelevant that they even have a bug-tracking database. Bad project management is endemic to no particular development paradigm.

  3. guyver3 says:

    More or less why i ignore the gnome/kde crap and run an windowmanager like WindowMaker.
    It does what I need, as I don't need some Windows emulation gui like gnome/kde. with annoying libraries and dependancies.
    I'm hoping LainOS makes some more progress.

    Just my 2 zorkmids

  4. fflewddur says:

    If you'd bother to read the GNOME mailing list that discussed this move, you'd know that the only bugs closed were ones which had not been modified since GNOME 1.x days and were not only reported on esoteric hardware.

    • jwz says:

      Oh please, why should I bother to read the Gnome mailing list? I'm not a Gnome developer, I'm just a user. And I report bugs, like a good little user, and then they get ignored.

      "Not been modified since" equals "had been silently ignored since."

      If it's not a bug, or if it was fixed, they should have closed it long ago, with a comment explaining why. Instead, all these bugs were just ignored. That's kwality.

      • grahams says:

        Oh please, why should I bother to read the Gnome mailing list? I'm not a Gnome developer, I'm just a user. And I report bugs, like a good little user, and then they get ignored.


        And this attitude (on the part of the developers) is what prevents from X from actually being useful on John Q's desktop. Every software project solicits bug reports from their end users but if the developers are going to toss the reports aside what is my motivation as a user to continue to waste my time.

        The argument for "ignoring enduser bugs" is that the developers are largely volunteers and if they don't want to be bothered going thru a mountain old reports that is their prerogative.. While it is true that this software is still under development, it is being pushed like it is ready for prime-time by both it's developers and those companies distributing it.

        The problem with that argument is that in order for X to succeed on the desktop the developers are going to need real-user feedback regarding their UI decisions, and by tossing out all the old bug reports, you're ignoring their feedback. If you ignore the feedback of the users, you are damning yourself to second or third class status in the market... Microsoft may be able to ignore their customers out of momentum, but GNOME can't.

        Refiling a bunch of old bugs into /dev/null without checking them might work in a corporation, where you can judge the QA cost... By canning those bugs, the developers have said that they don't just want the end user to report bugs, they want them to be the QA staff responsible for tracking that bug and reopening it if necessary...

        jwz's right, this development model is bullshit.

        • flipzagging says:

          You guys are postulating a dedication to the buglist that I've not seen in any project, commercial or open source.

          I used to work for ActiveState. Take ActivePerl, a somewhat souped-up distribution of Perl -- it's the standard distribution with various patches, extra modules, some utilities and easier installers. It's very widely installed. In particular, Windows ActivePerl is practically the standard on that platform.

          Every advantage to bug-fixing is here; the developers are paid AND the source is open AND the users are often developers, who submit good bug reports. But there's like 2 or 3 developers handling it, and over 13,000 items in bugzilla. You have to prioritize or you won't get anywhere.

          jwz appears to be irritated because his bug wasn't a priority, and was closed rather summarily. Yes, that sucks. At the very least they should have posted something on that bug that said "sorry, your hardware is too exotic and we're moving on to 2.x anyway."

          But the fundamental problem? I don't see how open source or teenagers or whatever is the problem here.

          Any concrete suggestions are welcome. It seems that developers will write features for free, but the bug lists are less of a priority. Should bug fixing be paid? Should you be able to bribe them to fix your bug first?

  5. altamira16 says:

    So they actually let you know when they close out crap. I upgraded to RedHat 8.0 recently because I have a great fear of installing OSes for whatever reason. And Pan repeatedly crashed when I tried to post. Being that Pan is a usenet newsreader, I thought this was an important bug. But it could be not a bug at all. It could be that I am a stupid user. That is what most people tell me when I find bugs in their code. "You stupid user, that is not how it is supposed to work." I think that is why I hate many of the programmers I know. If it can't be used, how is it working exactly?

    • dingodonkey says:

      "You stupid user, that is not how it is supposed to work."

      Well, clearly, what kind of idiot would expect a news program to post messages. Why would you think the post button did something like that? Augh, I hate such stupid users.

    • bitwise says:

      Well, good thing you didn't post it to redhat's bugzilla. There, most of the bugs don't even get looked at, much less resolved (even with WONTFIX). They simply stay in the NEW state... forever. If it's not a security hole or a kernel crash, forget about it.

      • altamira16 says:

        I did. I did. I just got a response too. They said that something is wrong with the libpspell_aspell, and it sends PAN a bug that it cannot handle when I try to post. Their recommended temporary fix was to go use a version of PAN before spellcheck was implemented. They said in version 0.14 or something, they will try to make it not use that particular library.

  6. mhat says:

    It seems to me at least part of the problem is bound to be the number of bugs. A project like Gnome or KDE is going to have a insane number of people submit the same bug using considerably different words. Almost nobody searches to see if the bug they are reporting has already been filed. Not that it matter if they did because it's almost impossible to find someone else's bug report describing the bug you are seeing.

    I guess volume is an inherent problem with big open source projects. It almost seems as if Gnome/KDE would be better off if a majority of people did not submit bug reports. Then at least the volume might go down enough that they could look at the bug reports that were submitted.

    Then there is the "must rewrite" (aka make it suck even more) problem.