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

[Martin Pool]

2009/8/12 John Arbash Meinel <john at arbash-meinel.com>:

Thanks for looking at it straight away.

> ^- I'm pretty sure it should look at ENV vars. I also believe that there
> is part of the XDG spec to handle things on Windows as well.
>
>
> For example, this thread:
> http://markmail.org/message/tczsbl6y3lm3ss33#query:xdg%20windows+page:1+mid:tczsbl6y3lm3ss33+state:results
>
> Which suggests:
>  $APPDATA/XDG/ or if $APPDATA is empty, $HOME/XDG/ (or XDG_CONFIG_HOME)
>
> Anyway, getting slightly more XDG compliant is going to be a bit of
> figuring out what the spec really says.

Thanks.  I was writing it offline so I just put in the part I could remember.

>
> ...
>
> +def _open_crash_file():
>
> ^- I would probably like to see a big try/except around this in case
> something goes wrong while we are trying to report the crash, so we
> don't suppress the crash message.
>
> You could be simple, and make it try/except (IOError,OSError), but I'd
> probably prefer except: or except Exception:
>
> I realize that might suppress ^C, but we are already in a crash, and I
> think we'd still rather get the original failure reported.

I think you're right.

>
> ...
>
> +    try:
> +        from apport.report import Report
> +    except ImportError, e:
> +        trace.warning("couldn't find apport bug-reporting library: %s" % e)
> +        return False
>
> ^- Given that we won't have apport on many platforms, I'm not sure that
> we want this warning to be shown for all failures. Probably long term we
> will, but I don't think we'd want it short term.

True, maybe it should just mutter.  After all it will be fairly
obvious if you don't have it.

> I think a lot of this should have more direct tests than you've given it.

You're right, it should - I was just interactively trying it out.

> 'apport' is just a simple dependency at that point, and we can certainly
> have tests about what the results of "crash_dir()" return. (Probably
> platform specific.)
>
>
>
> I think the overall idea is good, and it is something I think we should
> land early in a cycle to have both bugs shaken out, and direct developer
> experience. It may be that apport is going to be too heavy handed when
> developing new code. I also think it likely that we would want a
> "debug_flags=noapport" or the equivalent for active development of bzr.

I think we might.

-- 
Martin <http://launchpad.net/~mbp/>