Slashdot Mirror


KDE Bug Fixed After 13 Years (kate-editor.org)

About 50 KDE developers met this week in the Swiss Alps for the annual Randa Meetings, "seven days of intense in-person work, pushing KDE technologies forward and discussing how to address the next-generation demands for software systems." Christoph Cullmann, who maintains the Kate editor, blogs that during this year's sprint, they finally fixed a 13-year-old bug. He'd filed the bug report himself -- back in 2003 -- and writes that over the next 13 years, no one ever found the time to fix it. (Even though the bug received 333 "importance" votes...) After finally being marked Resolved, the bug's tracking page at KDE.org began receiving additional comments marveling at how much time had passed. Just think, when this bug was first reported:
-- The current Linux Kernel was 2.6.31...
-- Windows XP was the most current desktop verison. Vista was still 3 years away.
-- Top 2 Linux verions? Mandrake and Redhat (Fedora wouldn't be released for another 2 months, Ubuntu's first was more than a year away.)

4 of 118 comments (clear)

  1. 2.4.<bignum> by epine · · Score: 3, Interesting

    17 December 2003 — release of Linux kernel 2.6.0 (5,929,913 lines of code)

    If we're all feeling nostalgic, this should do the trick:

    The Linux Backdoor Attempt of 2003

    if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
          retval = -EINVAL;

    But on Nov. 5, 2003, Larry McVoy noticed that there was a code change in the CVS copy that did not have a pointer to a record of approval. Investigation showed that the change had never been approved and, stranger yet, that this change did not appear in the primary BitKeeper repository at all.

    Other issues back in 2003 were burning up the Linux development intertubes.

    The mind behind Linux

    16:00

    To me, the sign of people I really want to work with is that they have good taste, which is how ... I sent you this stupid example that is not relevant because it's too small. Good taste is much bigger than this. Good taste is about really seeing the big patterns and kind of instinctively knowing what's the right way to do things.

    The following is my idea of good taste (since the 1980s), whenever a comparison involves a constant term:

    if ((options == (__WCLONE|__WALL)) && (0 = current->uid))
          retval = -EINVAL;

    This does not achieve root. It won't even compile.

  2. Re:"no one ever found the time to fix it" by dfaure · · Score: 5, Interesting

    It took me a full day of very intense and complex debugging to fix this.

  3. Re:software woes by Dutch+Gun · · Score: 3, Interesting

    At my former employer (I'd consider them the best place I'd worked at), we had "embedded QA". They'd sit right next to the developers, would be at our status meetings, would often develop specialties related to what that dev was working on, and would immediately provide either unofficial or official feedback on new features. As annoying as it is to have someone point out mistakes you've made, as a dev, you need to get over it and realize it's better for one QA member to point out your stupid mistakes than for the entire world to see them after you shipped.

    For QA to be effective, I'm convinced they need to be working as part of the dev team, not as some standalone team the devs don't think about except when they get a bug report. This helps to prevent a lot of the problems with QA filing bug reports on things that aren't actually bugs since perhaps they're simply unfinished, or because they're something they don't understand about how things are supposed to work, etc. More importantly, this specialized QA person can vet other bugs from people on the team to make sure they're not dupes, etc. It can actually save the devs a lot of work.

    I'm not sure how you could apply this lesson with open source development. The best is probably to release detail patch notes detailing what you worked on, so people can keep on eye on those features for any breakage, and to have an active and helpful team willing to help test out alpha or beta builds. And of course, the devs need to be willing to actually *listen* to feedback, which can unfortunately be a stumbling block when the feedback clashes with their "vision".

    --
    Irony: Agile development has too much intertia to be abandoned now.
  4. Re:"no one ever found the time to fix it" by Lotana · · Score: 3, Interesting

    Thank you.