There's also a question of policy. Do we want to mandate a strict policy
of not allowing performance regressions (regressions backed out, no
questions asked), or do we consider each regression on a case by case
basis? The danger with the second approach is that if we leave the
regression in, and other code starts piling on top of those changes, it
can be hard to back out even if we wanted to. Personally I am slightly
in favor of a strict policy, but the other approach might also work well
if we have just a few regressions.
Mozilla has long maintained a very strict policy where regressions are
simply backed out. If you really wanted your fix/feature in, there were
two options: make a change such that performance does not regress, or
convince everyone that your change is so important it trumps performance.
I think it's still too early in the Chandler release cycle to run the project
as if it were Mozilla. Anything that makes development actually harder, that
introduces drag on getting features out is - at this time - not worth the
benefits of avoiding performance regressions.
Even though we've never been as good about performance tracking and fixing as
in the 0.6 release, there is still room for lots of improvement. For instance,
most of the performance tests used in 0.6 are too far from end user 'reality'
to make regressions an auto-backed out showstopper. A goal for 0.7 in the
performance tracking area should be to have more tests reflecting real
end-user situations.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
