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

[Russel Winder]

On Tue, 2009-08-11 at 15:14 +0200, Jelmer Vernooij wrote:

> Strack traces are the equivalent of segmentation faults in Bazaar,
> when they are displayed there is *always* a bug, never expected
> behaviour. I think hiding the detailed debug information here is a red
> herring, we should work on fixing those bugs instead.
> 
> The stack traces provide a lot of useful information. I fear without
> them we'll add another round trip to the interactions in bug reports
> trying to extract them.

Sorry but I am not going to even try and hide my grumpiness on this, as
underlying this comment is a lack of appreciation of the more or less
complete disinterest of users in anything of interest to developers.

Users do not care about core dumps, segmentation faults, stack traces,
etc., etc.  Nor do they care about logs or bug reports.  They actually
don't care that much about errors in computer-related things (*). What
they care about is getting the current job off their desk so they can
get paid and go home.

(*) M$ has managed to educate most users into believing that computers
are always prone to falling over and that rebooting is the correct way
of dealing with all errors.  Most users have little or no respect for
the computer, the software, or the people involved in creating it.

So how to deal with this complete discord?

Bazaar should trap any and all exceptions that are about to cause a user
visible stack trace.  The information that might then be relevant to the
developer should be prepared potentially for sending to a bug reporting
system -- in this case Launchpad.  The user should be informed that
there was a problem -- in language that they appreciate and can relate
to -- and then they should be offered the opportunity to send in the bug
information to help further development of the product.

Now the really sensible bit . . .

The user should be able to press Yes or No.

If they press No then they don't care and will likely just reboot their
computer.  Either that or they will think it a conspiracy to get hold of
personal data just as all the other error reporting systems are.  OK so
this is a sad side-effect of a prevalent attitude to current error
reporting, but that doesn't make it the wrong thing to do.

If they say yes then an bug report should be sent in to Launchpad
without the user having to deal with stack traces or actually a bug
report, they need never know what Launchpad is.

Just because M$ has this sort of a bug reporting strategy doesn't mean
it is a bad thing.

Leave users in control of doing feedback, but do not make them be an
integral part of all the detail.  Automate things.  Make things easy for
the user.  Minimize the hassle and the workload for the user.  Think
about how to make the user do the things you need them to do in order
for you to do your job, clear the work off your desk, get paid (**) and
go home.

(**) Except that in the FOSS community a lot of people don't get paid
for the work they are doing.

Now the hard bit . . .

With any luck there will be a steady stream of duplicate bug reports.
It cannot be outside the wit of clever developer to have a mechanism for
filtering the bug reports and folding duplicates.


OK I better stop grumping, and go and take some more pain killers . . .

-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel at russel.org.uk
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder at ekiga.net
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090811/341c13fc/attachment.pgp