bzr.dev performance, release performance, constraints and accommodations

Martin Pool mbp at sourcefrog.net
Thu Dec 6 07:03:47 GMT 2007


On Dec 5, 2007 5:37 PM, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
>
> <snip/>
>
>     Ian> Would it be acceptable to have the band-aids
>     Ian> enabled/disabled by a developer-only configuration
>     Ian> option? It would be off by default and enabled as part
>     Ian> of the release process.
>
> I agree with Robert that hiding the side-effects means, well, you
> don't see them so it doesn't itch. I thought about a switch to
> enable them too, but even that smells.

I was thinking about that too.  But for the goal of making us dogfood
most effectively, both developer-mode switches and changing formats
just before release are somewhat undesirable.

For me, this also connects to our use of warnings, assertions, and so
on.  I think we can categorize situations as:

*0* If an end user ever sees this, it's so surprising we want to ask
them to report it to us.  (Now most of these end up in a traceback,
but it's just conceivable the program could continue but still want to
report something - but maybe this is vanishingly rare.  "Hey, we found
a MD5 collision!" :-)

*1* If this happens to a user, nevermind, we can cope.  But if it
happens when a developer runs bzr, they should stop right away and fix
it, because it indicates their newly-added code is poor.

*2* Most of the time developers aren't interested in this, but it
might be useful if they're specifically trying to improve this area
and looking for known inefficiencies.

At the moment we do category 0 through warnings and assertions,
nothing for 1, and use -D flags for 2.

Maybe we should do almost nothing for 0: if it's really serious, raise
an error; if it's not, mutter and it might be found if they later
experience another problem.

For 1, we might want a -Developer flag (or config option), to cause
effectively more assertions to run.

For 2, trace statements are still good.

This might avoid end users seeing stipple about deprecated apis,
unreleased locks, and so on.

-- 
Martin



More information about the bazaar mailing list