Warning: Frustration rant follows.
More and more over time, I am noticing a tendency of bug reporters adding log files, config files and other large files to bug reports by cutting and pasting these massive files into the comment box, instead of attaching them as proper bugzilla file attachements.
As a developer, this is very irritating because it makes the bug report incredibly long to view. You have to scroll forever to get from one comment to the next, with this massive file pasted in the middle, making it very hard to follow, and thus making it more difficult to provide help for the problem being reported.
It also causes bugzilla's word-wrap to affect the text being pasted, which generally breaks patches, making them no longer apply cleanly, until they're reattached properly as file attachment by the person who has the original, or causing the developer more work manually recreating the patch from scratch by hand editing the source and regenerating it with diff/gendiff. This also can cause config files pasted into comments to be distorted and no longer machine parseable, depending on the syntax of the file, and how the parser that reads it handles things that have moved from one line to another due to wordwrapping in bugzilla.
Bugzilla has a file attachment feature, labeled "Create a file attachment". If you can not find it, please use your web browser's search feature to find the link on the bugzilla page, and _always_ attach these files directly as individual uncompressed text files, so that developers such as myself can bring the file attachments up in another web browser tab/window with a simple single mouse click, while still following the bug report.
Bugzilla used to also have a "Create a file attachment" hyperlink directly under the "Add a comment" window in red font, which the majority of users seemed to find right away. Back then, we got very few 1Mb log files pasted into bug reports making them unreadable, however nowadays bugzilla has reverted to the old behaviour, and an ever mounting number of bugs are getting these massive files pasted into them.
This is very very irritating. Please help us (developers) to help you (bug reporters/testers), by using bugzilla properly, and thinking about what it is like to be on the receiving end of 500 bug reports and get 30 like this. </rant>
Feature request filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184481
On Thu, 2006-03-09 at 02:08 -0500, Mike A. Harris wrote:
Warning: Frustration rant follows.
More and more over time, I am noticing a tendency of bug reporters adding log files, config files and other large files to bug reports by cutting and pasting these massive files into the comment box, instead of attaching them as proper bugzilla file attachements.
On the other hand, I like inline stack traces as a bugzilla comment search can find similar bugs pretty easy. If we had a "search attachments" option (or does this happen already ?) that would be neat.
Or a better alternative stack-trace database submission/search system.
C.
Caolan McNamara wrote:
On Thu, 2006-03-09 at 02:08 -0500, Mike A. Harris wrote:
Warning: Frustration rant follows.
More and more over time, I am noticing a tendency of bug reporters adding log files, config files and other large files to bug reports by cutting and pasting these massive files into the comment box, instead of attaching them as proper bugzilla file attachements.
On the other hand, I like inline stack traces as a bugzilla comment search can find similar bugs pretty easy.
Sure, stack traces are usually small, and aren't really file attachments per se. An strace or ltrace captured to a file though, should be a file attachment (and if it is large enough, compressed with gzip).
If we had a "search attachments" option (or does this happen already ?) that would be neat.
You can search attachments for as long as I can remember. Use the "Advanced" form (doesn't everyone?), and go to the very bottom to "Advanced Searching Using Boolean Charts". Not only can you search attachments, but you can search:
- Attachment description - Attachment data - Attachment filename - Attachment mime type
and attachment flags:
- Attachment patch - Attachment obsolete - Attachment private
and Attachment status
Or a better alternative stack-trace database submission/search system.
Stack traces as comments are fine with me, as it doesn't matter much if bugzilla wordwraps them or changes their whitespace. They're only read by humans, not by software expecting specific parsing of the stack trace.
I'm more concerned that if data being attached is very large amount of text, that it gets attached as an attachment so it can be viewed out of line instead of disrupting normal bug review flow. Also, that file attachments that are textual, which are going to be machine parsed later (patches, config files, etc.) get attached as file attachments, so that they are kept 100% in tact, and do not have any whitespace modification added in by bugzilla. Generally these files are often large as well, causing the large-file rule to kick in as well.
Can bugzilla limit the line or character count? That way RedHat/Fedora developers can sit down, and come to a consensus as to what is "too much", and kick back an error when people try to post huge comments, stating that they need to include information over x number of lines as an attachment, or reduce the size of their comment? I say this, because we already have one developer that seems to want virtually any sort of output as an attachment, and another stating that he likes seeing strace output put into the comments. Another developer is going to write in a minute and say strace output is too long, but lspci output should be in the comment (as an example), and then the whole thing once again boils down to user/developer preference....
----- Original Message ----- From: "Caolan McNamara" caolanm@redhat.com To: fedora-test-list@redhat.com Sent: Thursday, March 09, 2006 5:56 PM Subject: Re: Please "attach" files to bugzilla, instead of pasting into amassive comment
On Thu, 2006-03-09 at 02:08 -0500, Mike A. Harris wrote:
Warning: Frustration rant follows.
More and more over time, I am noticing a tendency of bug reporters adding log files, config files and other large files to bug reports by cutting and pasting these massive files into the comment box, instead of attaching them as proper bugzilla file attachements.
On the other hand, I like inline stack traces as a bugzilla comment search can find similar bugs pretty easy. If we had a "search attachments" option (or does this happen already ?) that would be neat.
Or a better alternative stack-trace database submission/search system.
C.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Jason Montleon wrote:
Can bugzilla limit the line or character count? That way RedHat/Fedora developers can sit down, and come to a consensus as to what is "too much", and kick back an error when people try to post huge comments, stating that they need to include information over x number of lines as an attachment, or reduce the size of their comment?
I'm not sure, but that wouldn't be a really viable solution either, because there are times in which a real comment can be larger than what a config file might be. So limiting the text length would not solve the problem, at least not for all cases, and it would impose a new restriction that could create a problem for a reasonable use case.
I say this, because we already have one developer that seems to want virtually any sort of output as an attachment, and another stating that he likes seeing strace output put into the comments.
You misunderstood the message I think. A stack backtrace and an strace are two different things. A backtrace tends to be 8-20 lines or less and is generally useful to read right in a comment, and does not generally distract from the bug.
An strace however traces system calls and signals, and are generally text files that are megabytes in size. That type of info is something you don't ever want in-line in a bug comment no matter who you are. You want to open an strace in a new browser window as a text attachment if it is small enough (use judgement when attaching as to what small enough is. I'd say < 250Kb). If it's larger than "small enough", gzip it so bugzilla's poor database isn't 6 billion terabytes.
Another developer is going to write in a minute and say strace output is too long, but lspci output should be in the comment (as an example), and then the whole thing once again boils down to user/developer preference....
What it boils down to is common sense. If something is a _file_, then _always_ attach it as a file. If it is the output of a command, and it is large, output redirect it to a file and attach the file as a file attachment. If it is a small number of lines of output from lspci or something and isn't going to distract from reading the bug comment to comment, put it inline.
Nobody wants to come to a bug they haven't seen for a few weeks/months and try to skim/review it to see what the deal is, to have to scroll over 2 or 3 500 line X server log files that were pasted into a massive comment.
If someone does want that, let me know who they are and I'll gladly reassign all bugs that come in like that to them.
On Thursday 09 March 2006 2:08 am, Mike A. Harris wrote:
Warning: Frustration rant follows.
More and more over time, I am noticing a tendency of bug reporters adding log files, config files and other large files to bug reports by cutting and pasting these massive files into the comment box, instead of attaching them as proper bugzilla file attachements.
As a developer, this is very irritating because it makes the bug report incredibly long to view....
I have been following this mail list and trying to help with testing since I now have some time and resources available. In more than a year's time, I have filed, perhaps, 2 bug reports. From my perspective, it is hard to know what information is required, necessary, useful. If I have asked on the list, and sometimes been answered, sometimes not. While I use computers, an occasional bash script is the depth of my programming ability on Linux. When trying to specify hardware, I am not sure if there are a set of diagnostic commands to run, or if I need a screwdriver and a magnifying glass to identify part numbers and revision levels.
.....
This is very very irritating. Please help us (developers) to help you (bug reporters/testers), by using bugzilla properly, and thinking about what it is like to be on the receiving end of 500 bug reports and get 30 like this.
</rant>
<request> Sir,
A style guide, a one page document of what you need for system identification, a set of suggested queries to obtain the information, and a suggested placement of the information would be very useful.
</request>
My desk is littered with post-it notes, but I don't know if lspci -v or lspci -vv is the preferred choice.
Feature request filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184481
-- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian.
-Jpearson