bzr.dev performance, release performance, constraints and accommodations

John Arbash Meinel john at arbash-meinel.com
Thu Dec 6 12:27:58 GMT 2007


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

Martin Pool wrote:
> 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.

As long as their is a way to have it just complain, and another way to have it
actually stop.
> 
> *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.
> 

- -Developer is okay, but I would like a way to set up my system to have that
flag enabled, without having to pass it to every command.

John
=:->


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHV+rCJdeBCYSNAAMRAlq1AJ416AItGWU4oeuQP5/oeLa7JiWeZwCfaXsj
24FcTfex+wwri+4zZmMIrZw=
=Fo4E
-----END PGP SIGNATURE-----



More information about the bazaar mailing list