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

Jelmer Vernooij jelmer at samba.org
Tue Aug 11 18:56:07 BST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Russel,

Russel Winder wrote:
> 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 .
> . .
I certainly agree offering the user to file a bug report for them
would be a lot neater than either of the alternatives (showing a
backtrace that can be copy-pasted into the bugreport or showing a
single line saying "an internal error occurred"). Your previous email
didn't mention any of this though, and only called for the backtrace
to be hidden - that's the bit I'm objecting to. I don't think users
who report bugs are helped if we end up having to mark them "incomplete".

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKgbCpAAoJEACAbyvXKaRXU44QAIO4/sy+F3ZBsqAa1vM/57o9
mnmv1qUKBZW0TQWi2JZCrNmzAY/cp0MavNyWNylErdaGqxy0EmZ3peoYe/q+qVFz
8n8+M0R7SGZcIlQ26rLvkP1cqwEhkRM5B4ndkLefFRmwskJ94GliYIueh0Zccb25
UOuQ4+jlHu4ZRKKY3unuENUAB3Bk+x5M5I8zuTu75EikeriuUG0FiHYggOyP7m7J
iQ4mF+UlPYFkntVPl8ZfQZ56LsMkDtyaVEiCZ4FpxqfaaOnlz2a7MktXdOtBec+Q
n7vsN+u5GZ1moBoEU1pfmfo0CJ2WmGKwSMXp8MjcPzjYIrkmMx6OrBLsK0qF/PBr
I17jfUmm2HASLczQVH1a6kgmkJmtr8Z7lDClZTnVc6YOcCm8M/SadfkujqAT8j4H
duKUGqUCBqVV/AZrDIdk0LeHgHmYntgYfuVO7kSoVS46euGn4xNon2sanvU5AJOx
2DblgHalczqQjoTprUC8axLPgKb+ToB/EL71eg4deSfa8BPTTytjFYJURay5z2Lm
Dvi2uuty3iT6BvHuxdnvOuQJ36T1FiqrzWv/CpxxTQWVqcl/oB6a4gkjSDgwK0sC
vqSl+NrCJmXuprfDPsImF0tk9PRK5MwS2+wGtAxCdZCo4NbkAG0ImxZLaAwiNRcS
gWC8wWWv1sHvWFq0CK20
=Kt1t
-----END PGP SIGNATURE-----




More information about the bazaar mailing list