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.)

Comments

2.4.<bignum>

[epine]

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.

Slashdot

[allo]

And slashdot doesn't even try to describe the bug in the summary.

Re:Slashdot

[zenlessyank]

Description: When I change between files, the icons start changing position in my Kate toolbar. At first (starting with the save icon), they move from extreme right to extreme left. Then, they start to disappear. I waited 2 weeks to report this, on SadEagle advice. (Wait 2 weeks, if the problem persist, report it.) How to reproduce it: Open Kate. Open a two arbitrary files. Switch between them.

Re:2.4.

[Boronx]

Bad code is ugly code. There's zero reason not to swap the expression into something safer except "that's the way I think it in my head". Turn your head around.

Re:Typical KDE

[slacka]

Yes,
KDE fixes old bugs, while Gnome just lets the patches rot.

https://bugzilla.gnome.org/sho...

"no one ever found the time to fix it"

[MoarSauce123]

And I bet in the end it took 10 minutes to do the job. This is nothing but a testament of wrong priorities of project leadership. Fix the stuff that people are already using rather than cramming in more broken features that users did fine without so far. I guess users are fine with subpar quality even in FOSS projects.

Re:"no one ever found the time to fix it"

[dfaure]

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

Re:"no one ever found the time to fix it"

[Lotana]

Thank you.

Something went wrong with "Linus Law"

[williamyf]

" 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.

My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. [...] But the key point is that both parts of the process (finding and fixing) tend to happen rapidly." ESR CatB

So, 13 years, right? And is not the first time. Holes in hipervisors for 12 years, heartbleed, ...

I've said it before and I'll say it again:

One does not only need "Eyes". One needs QUALIFIED AND MOTIVATED EYES, along with adequated Q&A Process to tame the bugs.

Re:software woes

[Dutch Gun]

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".

Re:2.4.

[Kjella]

.dnuora daeh ruoy nruT ."daeh ym ni ti kniht I yaw eht s'taht" tpecxe refas gnihtemos otni noisserpxe eht paws ot ton nosaer orez s'erehT .edoc ylgu si edoc daB

You say it like "what's in your head" is some small insignificant function of source code. There's a reason it's not in binary like a computer would prefer, it's so we humans can work on it. Whenever you're given a problem like "solve for x" everybody in western countries ends up with "x = [value]" not "[value] = x". Sure you could learn to read backwards too, like the text above but it's extremely annoying unless you force yourself to learn it. Personally I'd rather have banned the "=" operator and made it ":=" for assignment, "==" for comparison. You could keep the complex operators like "+=" etc. but not just the equal sign. That we don't use for equality, I mean it should be obvious something's not all that smart here.