Hi Chris, Chris White wrote: > Doc is still here: > > http://www.gentoo.org/doc/en/bugzilla-howto.xml
I've just read over it in full. It looks good - thanks for writing it. As you know, I've been meaning to write one of these for a while. I've been keeping a list of topics I think should be mentioned. Stripping out the ones you have covered, here's what I have left: maintainer-needed description maintainer-wanted description why isnt my bug being looked at why isnt my ebuild being looked at what are bug-wranglers never reassign a bug dont close as fixed just because you have a workaround if in doubt, let the developer close it link to how to go into the testing tree make sure you are using the latest version always try the testing package before reporting bug dont pollute existing bugs by posting unrelated or related problems. use one bug for one issue. always post "emerge info" always upload as plain text always attach large postings, never paste always use unified diff always post stuff on the bug, never in private email unless requested if you find a duplicate bug, instead of filing yours, tag onto the end of the existing one, even if the information you are adding does not differ debugging with dmesg never say "it doesnt work" or "it crashes" post config.log if it fails during configure why did you mark it as upstream instead of fixing it yourself how to apply patches in general how to apply patches in ebuilds Since the doc is already covering a lot of content, and adding some of these points to it will broaden it further, I think it makes sense to have 2 docs. One for "how to report a bug", and another for "how to give us lots of yummy info" in a bug report. Something like: How to report a bug: - Search, check that nobody has filed it already - Fill in the form under the right product - How to get "emerge info" output - General policy stuff: - If attaching, use plain text and never tarballs - Don't reassign bugs, leave that to devs - Don't close just because you have workarounds - What to do if your bug isnt getting attention - maintainer-needed/wanted description etc.... How to give us lots of yummy info: - How to apply patches - How to use strace - How to identify a configure failure - and how to upload config.log - How to use gdb, for C apps - Using valgrind? etc.... That way, most users will find all the information they need in the first doc, without being scared away by scary stuff. It would also serve as a document that you can read and understand in full before filing your first bug. Those who have the time and experience can go onto the second doc and learn how to help us debug the problem after the bug has been filed. It could also be used as a reference thing, e.g. on a kernel bug, I'll say "please try this patch", user says "how?", it would be nice if i could point them to a specific page on the tech doc. Daniel -- gentoo-dev@gentoo.org mailing list
