bzr.dev performance, release performance, constraints and accommodations

Ian Clatworthy ian.clatworthy at internode.on.net
Tue Dec 4 23:42:05 GMT 2007


Robert Collins wrote:

> bzr.dev should not have performance-band-aids merged to it. Such
> band-aids should only go to release branches.
> 
> There are two primary reasons for this. One is social - I have a theory
> that unless the accommodations made by bzrlib are exposed, developers
> will not actually fix them.

> The other reason is to do with design quality:

I think Robert makes a compelling case here for his side of the debate.
The main comments I have are:

* there are some risks associated with having our users with
  one experience while everyone running on bzr.dev has another

* this implies there is no 'best' branch for benchmarking except
  immediately after a release.

* Code that only exists in release branches and needs to be
  remerged each time a new release comes along smells bad to me.

Would it be acceptable to have the band-aids enabled/disabled by a
developer-only configuration option? It would be off by default and
enabled as part of the release process. When benchmarking or looking at
performance issues for users, core developers could enable it for short
periods of time.

Rob's on leave for a few weeks now and I don't think we should decide on
this in his absence. We ought to continue discussing it though.

Ian C.



More information about the bazaar mailing list