Gnome bug 94684
A more-or-less frequent occurrence with gnome upgrades is that
something changes which causes preferences to get hosed. Each time I
notice such a problem, I have reported a bug report, and each time,
Christian Marillat has decided to ignore the issue.
This is a very significant user issue; people who upgrade from potato
to woody should not have their entire gnome preference structure
randomly fail. It's a real bug.
The latest issue was bug 94684; the Class for gnome-terminal windows
changed: it used to be Gnome-Terminal/Gnome-Terminal; the upstream
gnome developers decided to change it to Terminal/Terminal. The
result is that a sawfish customization which keys on
Gnome-Terminal/Gnome-Terminal fails, and has to be reset.
This is a typical sort of issue; other times the names of preference
options change when the preference dialog is upgraded, or other such
minor nits. Each of these is a real bug and should get reported.
The first time I reported one of these was right after Christian
become the gnome packages maintainer, and he said to me "why do you
bother me? you should report the bug upstream" and I had to point out
that the basic job of the Debian developer in that regard is to act as
the user's advocate and report the bug upstream.
The current bug (94684) he said "I can do nothing if upstream author
changes their API". Well, this has many problems:
1) Upstream author didn't change an API, they changed a direct user
issue.
2) He can do something: a clean upgrade solution could be provided,
either in sawfish, or in gnome-terminal.
3) He can report the problem to the gnome maintainers and mark the bug
forwarded.
I'm perfectly happy for him to just do (3). But what he wants to do
instead is declare real bugs non-bugs, on the grounds that he "can do
nothing". If he can't even forward bugs upstream, there is a serious
problem.
When he said "I can do nothing" he closed the bug. I replied "yes you
can do something" and reopened it, and he elected to mark it wontfix.
Now, wontfix is for specific reasons, and "I don't want to bother
forwarding the bug upstream" is just not an adequate reason.
Thomas
Reply to: