On 25 May 2011 05:25, Patrick Strasser <email@example.com>
Point 3). Still it's too hard for a real novice which would like to help
to get a bug report not at all out. The starting suggestion for this
thread was to add an HTTP based transport path to get around the MTA
thing. In the mid 90ies I was starting with a dial up connection, which
was expensive, and I was glad that I could queue my outgoing mail and
have them shipped together. I needed a working MTA in my box. Nowadays
for me there's no point in having a non-local MTA, I have DSL and alway
access to my ISPs mail transport system, which means I have direct
access to BTS.
I just second the proposal to have a backup to the mail transport in
form of a HTTP or some other direct connection transport. Nothing more.
Mail is fine, having a backup is even better.
Personally I have many Debian desktops and servers under my control. Some of them on private networks without public FQDN. Some of them laptops, which never plugged into the same network, and as such need a different SMTP setup everytime. Some don't even have Internet access.
It is impossible for me to recall which ones have working MTAs, working reportbug SMTP configurations, etc. reportbug needs to be run from the system that encountered the problem or it will generate bad debugging information. When I encounter a bug somewhere, if I get side tracked trying to test my MTA setup on a system that never sends emails under normal conditions, I will run out of time to fill a quality bug report. Or maybe the bug is with the MTA I am trying to configure.
It has happened that I have submitted quality bug reports, only to find they go down a black hole, never to be seen again. The fact the BTS takes a while to respond doesn't help. Sure, maybe this was due to an invalid From address or something, would rather focus on submitting a good quality bug report rather then debug my MTA setup for a computer that normally never sends email however.
As a result, I often end up sending bug reports by hand, using my email client.
Also a good quality web interface gives immediate feedback that (a) the command has been processed, (b) validates the command immediately and (c) outputs the results of the command. None of this resubmitting email after email after email (with considerable delay between each email waiting response) to firstname.lastname@example.org
trying to get a simple reassign command to do the right thing.
Sure, maybe if you are a heavy user of the BTS, these issues won't apply; as a light/occasional user however I find I am spending more time trying to use the BTS then being able to file/manipulate bugs in the BTS.