| 1 |
Hi Chris, |
| 2 |
|
| 3 |
Chris White wrote: |
| 4 |
> Doc is still here: |
| 5 |
> |
| 6 |
> http://www.gentoo.org/doc/en/bugzilla-howto.xml |
| 7 |
|
| 8 |
I've just read over it in full. It looks good - thanks for writing it. |
| 9 |
|
| 10 |
As you know, I've been meaning to write one of these for a while. I've been |
| 11 |
keeping a list of topics I think should be mentioned. Stripping out the ones |
| 12 |
you have covered, here's what I have left: |
| 13 |
|
| 14 |
maintainer-needed description |
| 15 |
maintainer-wanted description |
| 16 |
why isnt my bug being looked at |
| 17 |
why isnt my ebuild being looked at |
| 18 |
what are bug-wranglers |
| 19 |
never reassign a bug |
| 20 |
dont close as fixed just because you have a workaround |
| 21 |
if in doubt, let the developer close it |
| 22 |
link to how to go into the testing tree |
| 23 |
make sure you are using the latest version |
| 24 |
always try the testing package before reporting bug |
| 25 |
dont pollute existing bugs by posting unrelated or related problems. use one |
| 26 |
bug for one issue. |
| 27 |
always post "emerge info" |
| 28 |
always upload as plain text |
| 29 |
always attach large postings, never paste |
| 30 |
always use unified diff |
| 31 |
always post stuff on the bug, never in private email unless requested |
| 32 |
if you find a duplicate bug, instead of filing yours, tag onto the end of the |
| 33 |
existing one, even if the information you are adding does not differ |
| 34 |
debugging with dmesg |
| 35 |
never say "it doesnt work" or "it crashes" |
| 36 |
post config.log if it fails during configure |
| 37 |
why did you mark it as upstream instead of fixing it yourself |
| 38 |
how to apply patches in general |
| 39 |
how to apply patches in ebuilds |
| 40 |
|
| 41 |
Since the doc is already covering a lot of content, and adding some of these |
| 42 |
points to it will broaden it further, I think it makes sense to have 2 docs. |
| 43 |
One for "how to report a bug", and another for "how to give us lots of yummy |
| 44 |
info" in a bug report. |
| 45 |
|
| 46 |
Something like: |
| 47 |
|
| 48 |
How to report a bug: |
| 49 |
- Search, check that nobody has filed it already |
| 50 |
- Fill in the form under the right product |
| 51 |
- How to get "emerge info" output |
| 52 |
- General policy stuff: |
| 53 |
- If attaching, use plain text and never tarballs |
| 54 |
- Don't reassign bugs, leave that to devs |
| 55 |
- Don't close just because you have workarounds |
| 56 |
- What to do if your bug isnt getting attention |
| 57 |
- maintainer-needed/wanted description |
| 58 |
etc.... |
| 59 |
|
| 60 |
How to give us lots of yummy info: |
| 61 |
- How to apply patches |
| 62 |
- How to use strace |
| 63 |
- How to identify a configure failure |
| 64 |
- and how to upload config.log |
| 65 |
- How to use gdb, for C apps |
| 66 |
- Using valgrind? |
| 67 |
etc.... |
| 68 |
|
| 69 |
That way, most users will find all the information they need in the first doc, |
| 70 |
without being scared away by scary stuff. It would also serve as a document |
| 71 |
that you can read and understand in full before filing your first bug. Those |
| 72 |
who have the time and experience can go onto the second doc and learn how to |
| 73 |
help us debug the problem after the bug has been filed. |
| 74 |
|
| 75 |
It could also be used as a reference thing, e.g. on a kernel bug, I'll say |
| 76 |
"please try this patch", user says "how?", it would be nice if i could point |
| 77 |
them to a specific page on the tech doc. |
| 78 |
|
| 79 |
Daniel |
| 80 |
-- |
| 81 |
gentoo-dev@g.o mailing list |
Archives