[RFC] tweak merge-approval criterion: performance

[Robert Collins]

In HACKING the third gate for approval - 
improves bugs, features, speed, or code simplicity - seems to me that we
should set some broad priority amongst these.

How much speed will we pay for a feature? in what commands?

I think generally we don't want to accept performance regressions for
anything *without explicit discussion.

So I propose that we split performance out into a fourth gate of its own
- 'does not reduce performance of performance sensitive commands', and
start profiling any patch that looks likely to impact
commit/status/diff/log/push/pull/branch/merge on trees likely to show
scaling or constant time problems.

(The merge of the pre-commit hook without profiling is what has
triggered this suggestion)

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070904/102c2ca2/attachment-0001.pgp