Bug 78654

Created attachment 86645 [details]
Patch to fix the XTerm app-defaults file

The officially supported terminal emulation software in Red Hat Linux
includes "gnome-terminal" and "konsole".  xterm is provided for legacy
reasons as a convenience to users who like to have it available for
whatever their personal reasoning/needs.

It is impossible for any software in it's default configuration to 
work exactly to every single user's own personal preference, however
-some- default must be made.  Since xterm is no longer supported by
Red Hat, and has not been for quite some time now, we do not change
the default configuration.

I have discovered through trial and error that for every setting
in xterm that one user claims is wrong or breaks some application
for them, and asks me to change it to something else, that changing
that setting results in some other application breaking for some other
user in a completely different way.

It is simply not possible to have one default set of options work
for everyone everywhere in every possible situation, and any attempts
to try to improve things have resulted every single time, in making
things worse, and having more incoming bug reports - on something that
is explicitly not supported.

For example, for this specific bug report, if I were to apply your
attached patch, then I would be making bug #49315 reappear (as appears
in the comment in the file), and the solution to that recurrent
problem (bug 49315 requires that fix in place in order for
internationalization to function correctly), would be to remove your
patch.  As you see, it is not possible to make a one size fits all
default configuration.

Any problems with the default configuration of xterm in Red Hat Linux,
users are encouraged to modify their local xterm configuration to
their own personal needs for the software mixture that they are using
in their own local environment, or alternatively to use one of the
officially supported terminal emulators.

While this is not likely the solution that you had hoped for, I hope
that I have explained the situation clearly so you can understand our
perspective on xterm related problem reports.

Thank you for your prompt response.  While not the solution I hoped for, I
understand your position.  I did not realize that xterm was no longer supported.

I do, however, feel the need to point out that you *are* changing the default
configuration for XTerm, by adding the fix for the super-secret bug #49315 (why
is that bug not viewable, anyway?).

No big.  I've got my fix, and now I'll just maintain local XFree86 rpms so I
won't run into this again.

Yes, you are correct that the default xterm configuration that we ship
is not the stock XFree86 xterm configuration.  Even though we do not
officially support xterm, as long as we do ship it, it is fairly
important that it has a mostly default configuration that is fairly
close to XFree86.org's defaults, but which is also rather sane for
various users around the world regardless of what language they use
or location they're in.

Having it only work out of the box for native English speaking users,
but be mostly broken for Chinese, Japanese, Korean, or other users
would only result in a large amount of incoming bug reports from
those users.  As such, internationalization is a rather important
default setting for us to provide to Red Hat Linux users globally,
since we offer our product globally.  XFree86.org's defaults, like
various other software, do not always have the best generic defaults,
and most software out there tends to favour English speakers, even
though it could come with fairly sane defaults for a wider user base.

Super secret bug #49315 is not viewable to the general public because
Red Hat developers use bugzilla to file their own personal todo items
that are not really intended for anyone else to see, sort of like
a private notepad on their desk at work, only it is in bugzilla
instead, as many of us find it easier to track certain types of todo
items using bugzilla.  Also, sometimes we use bugzilla between each
other for similar todo-type things that relate between developers,
or between packages.  These items are as I said, like an electronic
version of an internal memo between two developers, and while many
of them do not contain any real "super secret" information, they are
generally not of interest to the general public and are merely developers
private notes.

Bugzilla is also used by other companies which Red Hat is partnered with
under contract, and bug reports may contain information which is under
non-disclosure agreement with various hardware and/or software companies.

Some bugs may contain information which includes private Red Hat information
on upcoming features that we have not publicized, or perhaps other details
that we need to discuss amongst ourselves during development or between
partners that contains private company information under NDA.

Other bugs yet, may be security related, and either filed internally,
or flagged by the reporter to be "for Red Hat development only" in order
to report and track a security issue privately.  Many security issues
are reported which we are not at liberty to disclose until the date
that the reporter or some other 3rd party has set.

As you can see, bugzilla is a tool which primarily is used by Red Hat
internally for defect management, and in many cases reports may have
one reason or another for not being publically visible.  I've outlined
a few of these reasons, however there are many more reasons other than
the above.  Bugzilla is ultimately an internal tool, however we believe
that it benefits both Red Hat, as well as our customers and users to
make it available to the general public as well, as we do receive
a lot of valuable bug reports and feedback this way.  It's easier for
us to have one single database, rather than to have multiple databases
for each different type of problem being reported or tracked, and
as such some bugs are flagged to be not visible to the general public.

Hopefully I've taken the mystery away from our super-secret bug
reports. ;o)

As a final note, since you mentioned maintaining your own rpms as a
workaround for this.  Another possibility you might find perhaps even
more useful, is to create just an xterm rpm package using the upstream
xterm sources since it is maintained outside of XFree86.  You could
keep it updated much easier, with your own custom defaults, and
have it install via rpm into /usr/local or /opt or somewhere and plop
in a script into /etc/profile.d that adds this directory to the path
first.  Just an option I thought of which might be useful to you.

Take care.




it is an internal Red Hat developer 

Dang cut-n-paste blunder at the bottom of my last comment there..
Time for me to file a private bug report, to have that fixed.  ;o)