Prohibit epic bug descriptions

Perhaps we could reject lengthly bug descriptions with the following error:

"The description may not exceed 1000 characters in length. If you have a large amount of text to add, add an attachment."

mpt: can you improve on this wording?

An alternative (more polite) suggestion:

"The description may not exceed 1000 characters in length. Please add an attachment if you wish to add anything longer."

For users with dynamic scripting, we could go further:

Next to the description box, render a dynamic message that reads "You have <n> characters remaining", where <n> is the difference between the maximum length and the current length. Add dynamic logic to prevent the message from exceeding the maximum length.

Twitteriffic! ;-) However, overlong bug descriptions are so rare, I think we needn't warn about them unless people have already gone over the limit. "Whoa there, that's too long. If you have lots of text to add, _attach a file_ instead." Making this text dynamic would be excellent, but disclosing the exact number of characters -- either current or allowed -- could be counterproductive. Development productivity is served by concise bug descriptions, but giving people exact numbers would encourage them to sneak just under the limit instead of excising further.

Two questions:

1. How large do we make our upper limit?
2. Should we have a different error message when filing a bug, as opposed to when altering a bug?

Currently it's not possible to add an attachment when filing a bug, so the link doesn't make sense here (unless we make it possible, of course!).

Submitting a bug description longer than 50,000 characters in length causes an OOPS.
So we should definitely fix that.

Test failed - I pasted the entire Alice in Wonderland as a description and got an OOPS.

The OOPS is a result of a DB check - did we only introduce that check into the DB or did we attempt to create a more meaningful warning in the UI? If the latter, than the bug hasn't been fixed.

whoops, didn't notice that this was marked `In Progress` - obviously this sneaked into the test plan but is not yet finished - jsk, don't forget to move it to the next milestone.

Ignore my last two comments.

During implementation, I'd like to request that the available length either be long enough to include all of 1) A fair description of the nature of the issue (Usually oughtn't be more than two or three paragraphs), 2) relevant notes from exterior sources (maybe up to three paragraphs), 3) A full test case descrption, including observed and expected results, and 4) A paragraph of additional notes that may be important to testers, or other subscribers waiting for input results.

I can easily imagine all of the above being more than 1000 characters, but would find implementation of some of the more complex StableReleaseUpdates more difficult to process without that information. Further, there may be lengthy comments that are useful in discussion of whether something is a bug, or related items that are of direct interest to bug subscribers, yet nonetheless larger than such a small numerical limit.

On the other hand, huge pastes of log files, debug output, etc. is essentially useless, as it makes it harder to extract than an attachment and detracts from understanding of the bug. Might it be possible to apply some heuristics to try to differentiate prose from log files? Further, if imposing a limit on bug descriptions, it may be useful to apply the same limit to bug comments, to discourage posting of logs as comments in an attempt to work around the description size limit (this may be more critical, as the description may at least be edited to a reasonable size).