Merge lp:~mbp/bzr/417881-selftest-no-apport into lp:bzr

I think the specific layout can get a bit into bikeshedding, but if you like the look of this layout, then lets go with it.

I think I'll land this without the traceback changes and we can consider that separately.

So I realise this has landed already, but I think its the wrong
approach ;)

Specifically, we should IMO disable apport *anyway* for development
trees - where there is a .bzr dir. That way, for selftest:
 - as packaged, we get apport bug reports about selftest (good)
 - as a dev environment, we don't get apport in our way (good)

-Rob

On 3 February 2010 17:18, Robert Collins <email address hidden> wrote:
> So I realise this has landed already, but I think its the wrong
> approach ;)
>
> Specifically, we should IMO disable apport *anyway* for development
> trees - where there is a .bzr dir. That way, for selftest:
>  - as packaged, we get apport bug reports about selftest (good)
>  - as a dev environment, we don't get apport in our way (good)

It's easy to change. Where do you think we should specify that
something is a development environment?

I don't think "not from a package" or "running from home" is perfect
because there are users who regularly run that way. But perhaps it is
the best tradeoff.

Alternatively we can set "debug_flags = no_apport" ourselves and
simply reverse this patch.

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

On Wed, 2010-02-03 at 17:42 +0000, Martin Pool wrote:
> On 3 February 2010 17:18, Robert Collins <email address hidden> wrote:
> > So I realise this has landed already, but I think its the wrong
> > approach ;)
> >
> > Specifically, we should IMO disable apport *anyway* for development
> > trees - where there is a .bzr dir. That way, for selftest:
> > - as packaged, we get apport bug reports about selftest (good)
> > - as a dev environment, we don't get apport in our way (good)
>
> It's easy to change. Where do you think we should specify that
> something is a development environment?

I was thinking if we're running from source is a good heuristic - users
that run from source and aren't up to reporting good bugs are a small
portion of our userbase, I think.

> I don't think "not from a package" or "running from home" is perfect
> because there are users who regularly run that way. But perhaps it is
> the best tradeoff.
>
> Alternatively we can set "debug_flags = no_apport" ourselves and
> simply reverse this patch.

Or we could do that instead/too. Mainly I'm saying that a user on Ubuntu
with a packaged bzr that breaks loading tests should generate an apport
problem report.

-Rob

So shall we perhaps pull this out and just tell developers to set -Dno_apport?

On Wed, 2010-02-03 at 18:21 +0000, Martin Pool wrote:
> So shall we perhaps pull this out and just tell developers to set -Dno_apport?

Yes, I think so. Perhaps a note in HACKING noting this and suggesting a
bazaar.conf stanza for it?

-Rob

Martin Pool wrote:
> So shall we perhaps pull this out and just tell developers to set -Dno_apport?

FWIW, this developer already set -Dno_apport several weeks ago, so that plan
gets +1 from me :)

-Andrew.

Andrew Bennetts wrote:
> Martin Pool wrote:
>> So shall we perhaps pull this out and just tell developers to set -Dno_apport?
>
> FWIW, this developer already set -Dno_apport several weeks ago, so that plan
> gets +1 from me :)

Me too.

Ian C.

reversion landed