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.