Attached is the outline I plan for the split docs.
Created attachment 65727 [details] plan.txt
What? I thought you had almost finished this split !!! *whapah* *whapah* work, minion *whapah*
Looks fine! ;)
Damn ChrisWhite, you have a brain!!!!! :p Plan looks good PUNK, let's put it into action :)
Chris? Any action on this?
Created attachment 77689 [details] bugzilla-howto.xml Done from 10:00PM to about 2:00AM. Ran through XMLINT/aspell because I suck in general at that. It's a rewrite because of how much differently bugzilla works. There are no images or flash animations, sorry guys :(. Anyways, it's a long long long long doc, so I guess rane wants it REALLY BADLY, DON'T YOU RANE! kthxbye.
Created attachment 77741 [details] bugzilla-howto.xml Fixed 2AM grammar. Fixed the title being the gdp template title, despite the fact I knew about it when writing the doc :P... CC's/CC'ing/CC-ing -> CCs/CCing/CCing.
02:08:38#gentoo-doc: < cpw> fox2mike: bugzilla guide bugzilla guide bugzilla guide bugzilla guide bugzilla guide bugzilla guide bugzilla guide bugzilla guide bugzilla guide bugzilla guide
Live from the IRC chat with jakub, some comments from me. 1. Don't use "here" as link text. The bugzilla homepage can be found at ... url. So users might even print the doc from their browser. Same for Component list. 2. You suggest searching by !!! lines while emerge tells the user not to report the !!! but rather the lines above it. 2. You definitely want to include DUPLICATES in the first run. If the result really gets cluttered, you can still leave it out in a second run. 3. You should add a word about the different search combinations, especially the difference between single string and multiple strings. 4. The "Where to file" section puts more emphasis on where it should not go than where it should go. You should start off with "Gentoo Linux", and maybe not even mention the others. 5. Add a suggestion that any open forum threads should point to the newly created bug. 6. You should give some details about parallel builds, that the actual error might be halfway up the screen by the time the ebuild finishes.
(In reply to comment #9) > Live from the IRC chat with jakub, some comments from me. > > 1. Don't use "here" as link text. The bugzilla homepage can be found at ... > url. So users might even print the doc from their browser. Same for Component > list. Will fix that > 2. You suggest searching by !!! lines while emerge tells the user not to report > the !!! but rather the lines above it. Which, the users will post those, and I've never seen anything that has EVER caused that method to not work, and even if it doesn't work, I describe other methods anyways. > 2. You definitely want to include DUPLICATES in the first run. If the result > really gets cluttered, you can still leave it out in a second run. Bugs that hit this are somewhat rare. In general most duplicates are rather obvious. > 3. You should add a word about the different search combinations, especially > the difference between single string and multiple strings. Can you go into more detail on that? I think I know where you're going with that, but am not quite sure. > 4. The "Where to file" section puts more emphasis on where it should not go > than where it should go. You should start off with "Gentoo Linux", and maybe > not even mention the others. We already emphasis it and people still don't listen. I put the explanations there because people are less likely to do it if they see what they think right there in front of them. > 5. Add a suggestion that any open forum threads should point to the newly > created bug. Kind of iffy, that's really up to the forums mods to handle, but if they want I'll toss some note in there. > 6. You should give some details about parallel builds, that the actual error > might be halfway up the screen by the time the ebuild finishes. Yes, but !!! errors don't change, and are always at the bottom. People are more likely to post those, which is why I use that method, and it's always worked for me.
(In reply to comment #10) > Bugs that hit this are somewhat rare. In general most duplicates are rather > obvious. I already did. And still a duped bug is more prominent, less easy to oversee, and likely the one they want. > Can you go into more detail on that? I think I know where you're going with > that, but am not quite sure. If you copy some string verbatim from your terminal window, you want to search for that string. If you enter some words that you would expect in any matching report, but that cannot be found in this exact combination on the screen, then you want to search for all these words. And if you are not sure at all but want to give a list of detailed words, any one of which might appear in a likely report, you want to search for any of those words. And as you usually search for words or strings alike, it does not matter if the term u use is in the middle of a word or not. > Yes, but !!! errors don't change, and are always at the bottom. People are > more likely to post those, which is why I use that method, and it's always > worked for me. It works for finding the bug, but as you want to solve it as well, you want to get the useful information along with the !!! lines. Bug reports are not only there to be found, are they?
(In reply to comment #9) > 5. Add a suggestion that any open forum threads should point to the newly > created bug. It's a good idea to mention it in the guide. Lots of people already do this and anytime we (mods and admins and regular users) find a bug that is relevant to the thread we usually try to post it.
This has been done ages ago. http://www.gentoo.org/doc/en/bugzilla-howto.xml
reopening since the idea of splitting bugzie guide was never fully implemented.
Reassigning as fox2mike is being retired
The bugzilla howto is now moved to the Gentoo wiki, which makes it much more accessible for others to contribute. https://wiki.gentoo.org/wiki/Bugzilla_HOWTO
