Bug 1114075

1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

I appreciate the enthusiasm you have for reporting issues, but they're typically already solved issues.

Bugzilla Preferences > Wrap comments by default > Turn it off

1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<160>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

(In reply to Michael Cronenworth from comment #3)
> I appreciate the enthusiasm you have for reporting issues, but they're
> typically already solved issues.
> 
> Bugzilla Preferences > Wrap comments by default > Turn it off

This preference applies only to logged users, so this is not a complete solution.

(In reply to poma from comment #5)
> This preference applies only to logged users, so this is not a complete
> solution.

Yes, a user's preferences can only be applied when the user is logged in.  That's not a bug.

Aside from that, I don't see anything resembling a valid bug report here.

If you can identify a problem with Red Hat Bugzilla that you'd like us to fix, you have two choices:

1. If the problem relates to the upstream public Bugzilla project, you should report the issue at https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla

2. If the problem relates to the customizations or extensions that Red Hat has added only to it's version of Bugzilla, you should report the issue at https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla

In either case, you will need to provide a full description of the problem, step-by-step instructions to reproduce the problem, and a description of what behaviour you expect to see instead.

Note also that the "urgent" Severity value should only be used for bugs that satisfy the following description (which is accessible by clicking on the label of the severity field):

"urgent: catastrophic issues which severely impact the mission-critical operations of an organization. This may mean that the operational servers, development systems or customer applications are down or not functioning and no procedural workaround exists."

It is very clearly explained in a short dialogue on this link, 
https://lists.fedoraproject.org/pipermail/devel/2014-June/200583.html

(In reply to poma from comment #7)
>
> It is very clearly explained in a short dialogue on this link, 

Is there any other use-case other screen-grabs? If not, I'll suggest filing them as attachments and restricting bug comments to comments about the bug in question.

Yeah, although I recommend textarea cols="120" & comment_text width: 100em
i.e.
rows="10" cols="120">[% Param(param.name) FILTER html %]</textarea>
&
.bz_comment_text {
     width: 100em;

https://bugzilla.mozilla.org/show_bug.cgi?id=11901#c264

Wrapped comment width per se ain't a problem, but the width of the comments containing the logs output is catafakinstrophically narrowed and unreadable.
Is it the way it is now actually readable for you, or are you joking!?

I still see nothing here that bears any resemblence to a valid bug report.

If you reread Comment #7 and follow the links therein, you'll see the kinds of information that are required to create a valid bug report.  Without that information, the Red Hat Bugzilla development team cannot determine what (if anything) needs to change and how best to make the required change.  If you reopen this bug again without providing the necessary information, it will be returned to CLOSED/INSUFFICIENT_DATA.

A few other points:

* Changing wrapping behaviour to make large volumes of log output easier to read is attacking the wrong problem. Logging output longer than a few lines should go into a bug attachment rather than a comment.  The output in the screenshots you pointed to is about the limit of what should generally go into a comment.

* The default wrapping behaviour for an anonymous (i.e. not logged in) user comes from the upstream Bugzilla project and was chosen as a reasonable default for the vast majority of users and use-cases.  Obviously a default cannot satisfy all users, which is why Bugzilla allows preferences for logged-in users.  If you want to suggest a new default beahviour that would satisfy more users than the current default, you should file a bug against the upstream Bugzilla project as described in Comment #7.

* If you really need a behaviour that's different from the default behaviour that's suitable for most users, you may be able to get what you need by using a browser plugin (such as Greasemonkey) to modify the .css on-the-fly. Bugzilla tries to make this easy by using css class names for many elements in its generated html.

* The MODIFIED status is defined in Bugzilla's online help as "This bug report has been fixed, unit tested and checked into source control by the Assigned Engineer."  When reopening a closed bug for which no changes have yet been made, NEW is a more appropriate status.  Developers often filter out bugs that have progressed through the lifecycle to MODIFIED or beyond, and a bug reopened into MODIFIED could easily be ignored for a long time.

(In reply to Jason McDonald from comment #10)
> * The default wrapping behaviour for an anonymous (i.e. not logged in) user
> comes from the upstream Bugzilla project and was chosen as a reasonable
> default for the vast majority of users and use-cases.  Obviously a default
> cannot satisfy all users, which is why Bugzilla allows preferences for
> logged-in users.  If you want to suggest a new default beahviour that would
> satisfy more users than the current default, you should file a bug against
> the upstream Bugzilla project as described in Comment #7.

No, actually that's Red Hat-specific code, so a bug should be filed against Red Hat Bugzilla.

:)
Thank you for your detailed explanation and your time for this.