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.)
-- 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.)
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;
Other issues back in 2003 were burning up the Linux development intertubes.
The mind behind Linux
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.
It took me a full day of very intense and complex debugging to fix this.
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.
Thank you.