RFC: remove traceback from "newer branch format than your bzr"

[Stephen J. Turnbull]

Martin Pool writes:

 > $ bzr branch....
 > AbsentContentFactory has no attribute...
 > This probably indicates a bug in Bazaar.  Sorry.  For help or to
 > report a bug see http://bazaar-......

Urk.  Now you are going to get a bug report empty of useful
information, except that what you already "knew" (that Bazaar still
contains unfixed bugs) has been confirmed.  You have to go annoy the
user to get the traceback, but Mr. Murphy will ensure that it's not
reproducible.

A better strategy is to output

    AbsentContentFactory has no attribute ...
    This probably indicates a bug in Bazaar.  Please report this by
    going to http://bugs.bazaar-vcs.org/ and creating a bug report.

Then (1) if you have reason to believe that you still have a
functioning IO system, write the trace to a uniquely-named file and
output:

    Please attach the file /tmp/bzr.error.20090811.215559 to the
    report.  It contains information about the state of bzr at the
    time of the error that is often useful in debugging bzr.

or (2) if your only hope of reaching the user is stderr, output:

    Please include or attach the following output to the report (eg,
    by cut and paste).  It contains information about the state of bzr
    at the time of the error that is often useful in debugging bzr.
    qwerty
    qwerty
    qwerty
    No. 5 alive!
    Wall-E....

etc.

The real problem with backtraces is not that they cause secretaries to
worry about the reliability of bzr.  By now they already know that bzr
can seriously impede their work; you can't recover from that by hiding
the backtrace.  The problem is that a backtrace forces the user to
consider taking some responsibility for the issue by sending in a bug
report.

OK, I admit that in the world of secretaries and windows-washers,
maybe you don't even want to mention the r-word, but on the other
hand, making bzr more reliable is the real key to getting their
support.  The best way to do that is high-quality bug reports.

 > Also and separately, "we have a problem in streaming" should at least
 > say so, not just raise an AttributeError, but that's orthogonal.

See?