Try to reduce of the amount of LONG comments

Putting backtraces to comments make easier to search for duplicate and make the bug easier to read. 100 lines is a bit low and you should rather ask for confirmation that force people to use attachments for that

Right, I agree with that.

We could use JavaScript to detect whether a comment was getting really long, and put a friendly hint under the comment field.

This is a genuine problem, not a wishlist request. We have bugs in malone with attachments over 100k, which makes the bug page slow to download and difficult to read (bug #26117 for example).

100 lines sounds fairly reasonable to me, considering that's about 4 screens of text in my browser. Sebastien, what would you consider to be an appropriate hard limit?

100 is probably short, most useful backtrace are longer than that. The question is to know if you want the backtraces copied directly to the comment. Backtrace are usually copied to a comment on bugzilla.gnome.org because it makes much easier to find duplicates (by a query or with the dupfinder they have)

On Thu, Apr 27, 2006 at 04:33:24PM -0000, Sebastien Bacher wrote:
> 100 is probably short, most useful backtrace are longer than that. The
> question is to know if you want the backtraces copied directly to the
> comment. Backtrace are usually copied to a comment on bugzilla.gnome.org
> because it makes much easier to find duplicates (by a query or with the
> dupfinder they have)

How about 8k? Would that be sufficient for backtraces?

--
 - mdz

looking on some backtraces on my disk 8k might be short, 16k would be fine though. For reference bugzilla.gnome.org uses a 64k limit

With regard to the concern about searching, wouldn't it be better to teach Malone to be able to search within attachments?

Very large comments often wedge my browser such that I find it difficult to work for minutes while it copes with the huge page (perhaps I have less memory in my laptop than you).

Colin, I don't think that 16k is enough to be an issue for your browser. I still prefer a reasonable backtrace to a comment because it's easier to read the bug than to navigates between pages to have a view of the backtrace and a description of the issue, not to mention than if you work with mails it forces you to open your browser on the attachment

@Sebastian, if you wish that malone searches within text attachments, why not implement that?

(I was expecting a limit between 25 and 50 lines, and people here talking about 64K, XD )

I guess gnome bugzilla has another layout and characteristics. In Malone, long lines in comments typical from logs are hardly readable (they get broken unless they contain a link).

because having attachments force you to switch between different pages to read the bug and is not really convenient for mails too

I may be a very rare person. I don't see why switching tabs in a browser or windows in an email client could be more problematic than scrolling and scrolling and scrolling ....and scrolling to find the end of one log and the beginning of the other. Plus the burden of applying grep or diff to logs that are in comments. Of course, this is assuming that the breaking of long lines is not unbearable for the reader.

Obviously, if this is a difference of opinion between you (Sebastian) and me, your opinion should prevail, since your work in malone is far more important than mine. I am not requesting the change, just stating the problems I have with the current situation.

We now truncate the comments when displaying it on the bug page, with a link to view the whole comment. See https://staging.launchpad.net/distros/ubuntu/+source/gnome-terminal/+bug/29350 for an example of how it looks like.

What is the threshold? The first comment in bug #49294 is far too long

On Wed, Aug 23, 2006 at 08:54:05AM -0000, Matt Zimmerman wrote:
> What is the threshold?

It's around 40-50 lines.

> The first comment in bug #49294 is far too long

That's not a comment, it's the description. You could edit it, removing
the traceback. The original description would still be accessible. If
you think it's worth doing something about long descriptions, please
file a new bug.