Making the right sort of difference
          Bugs and what to do with them


                Telsa Gwynne
               Perth  LCA2003

Why am I the one to give this talk?

	They asked me.
	I have met and reported an awful lot of bugs.
	Some measureable fraction of http://bugs.gnome.org/ was my fault.
	Somehow, people seem to expect me to break things.


What is a bug? 

	Something you don't like?
	Something you don't expect?
	Something which causes a core dump?
	Something which is not in the manual?
	Something which is different from the manual?
	A feature?


Where do bugs live?

	The kernel.
	XFree86.
	GNOME and KDE and every window manager in existence.
	Distributions and their packages.
	Command-line apps
	The web
	Documentation and webpages.

       Whatever app you are actively trying to use, not just to tinker about with.


Finding them (1)

	I just fall over them.
	Stop and investigate as soon as you see them. 
	If you think you will come back to them, they will hide.
	Make notes at the time.

	Don't write them on the machine in question.
	Paper is very handy and rarely crashes.


Finding them (2)

	Anywhere you can input things.
	For numbers, feed it 9999999, zero, negative numbers, and words.
	For words, feed it non-ascii letters, semi-colons, numbers, and huge strings.
	Change your locale, your theme or your font.
	Daylight saving - Real time


Finding them (3)

	Install and/or run it with a quota of 5kb, or no disc space.
	Load the box.
	Run the app over a network.
		NFS is particularly good here: you can get NFS and app bugs at once!
		Pull out your ethernet card mid-session: hours of fun.
	Document the application.
	Follow the documentation precisely.


Breaking graphical apps

	Resize it to 1x1 or smaller.
	Run at 1600x1200 and try to click on tiny boxes with a bad mouse
	Run at 640x480 and try to find the box to click on
	xnest
	Back - back - back - bang


So you have a bug. Woo! Now what?

	Reproducible?
	Run it from command-line and/or with debugging on.
	Redirect errors to a file.
	Debugging builds.
	gdb.
 

Cool tools (1)

	Package management
	strace
	ltrace
	ldd
	lspci -v(v(v))
	xnest
	script
	startx 2>&1 > bang-log


Cool tools (2)

	Your wits
	Pen and paper
	Tape recorder
	Digital camera
		(Send the URL. Not the picture)
	A network of some description 
		(for telling the difference between X and kernel)


If it's not documented, it is a bug

	man pages
	in-application help system
	the dreaded info node
	/usr/share/doc/appname*/*
	website
	FAQ
	Changelog
	bug tracker


Gathering information

	Whatever the documentation says you need 
		(everything from mutt to the kernel has a list)
	The package(s) involved.
	The version number. 
	Does it happen on: 
		Your box,
		A test account, 
		An account with default settings
		Other distros, other versions of same distros
		Other OSes?

People on IRC are amazingly responsive to "I think this crashes any browser/GNOME desktop/VM subsystem" and will disappear and then reappear and add "yup, crashes my box too!"


Sending information.

	bug-buddy, the debian bug tool, bashbug and friends
	Remove core files. 
	Trim down screenshots.
		No screenshot should be half a meg. Really.
	Unless you really have a "Mozilla can't render this adult site picture bug", stick to "work-viewable" pictures. 
	However cool your stiles.com background is, there are people who won't want to see it.


The trackers

	Bugzilla
	Debbugs
	Jitterbug
	GNATS
	Mailing lists at gnu.org, xfree86.org
	Sourceforge (allegedly)


Stop right there! Binary apps and modules.

	nVidia
	Lucent's winmodems (drivers)
	Clearcase and Veritas filesystem extras (modules)
	VMware have a module with source which interacts with their binary-only code
	Netscape
	Plugins for Netscape or Mozilla: Real and Flash particularly
	StarOffice


Some projects are friendlier than others.

	If you are running a plain distribution, report it to the distribution. They will send them upstream.
	XFree86 don't want bugs against X installations more than six months old.
	mplayer don't want bugs against anything other than current CVS.
	If you think it's a security bug there are often special arrangements for this.

But do file it somewhere.


I found a HUGE security hole!

If it's anything related to lilo and "someone can reboot my computer if they're at the keyboard", think twice before continuing. Read the Linux FAQ.
Otherwise, security@project.org often works.


Terminology is hard

	Is it 
		The bar. 
		The panel. 
		The start bar. 
		The toolbar. 
		The grey bit. 
	"root window".
	"workspace", "virtual desktop".
	threads. ugh. Don't say "threads" to a programmer.

If you are not sure, say so. 


Some ways to get your report ignored

	Send it to the wrong place.
	Swear a lot.
	Assume the reader of the bug report is personally responsible for your woes.
	Announce that you are removing the package from your system and never using it again
	Provide no way to contact you.


Developers! Cut down on those pesky bug reports!

	Laugh at your users
	Ignore the reports
	Berate your users
	Assume anything about your users' intelligence or experience
	Write FAQs which make it blatently clear that you really aren't interested in the experience of those who can't edit Makefiles.
	Flame your bug-reporter.

The GNU Maintainers Guidelines say "Thank every user for their bug report, even when it is not a bug".


Filed. Now what?

	50% chance of nothing happening until long after you have forgotten about it.
	20% chance of someone saying "Fixed in CVS".
	30% chance of a NEEDINFO and anything from "Were you playing an mpeg at the time and was it a Tuesday?" to "Was the binmangler compiled with the tomato chipset dicing options?" 

Or then again, someone might fix it.


By this time, you have generally upgraded.

And found another bug.
See slide one :)