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