On Wed, Jan 26, 2011 at 4:42 PM, Stefan Sperling <s...@elego.de> wrote: > On Wed, Jan 26, 2011 at 11:25:59PM +0100, Stefan Fuhrmann wrote: >> Hi @all, >> >> I'm planning to merge said branch Monday 7th. >> Speak now or forever hold your peace. >> >> Rationale: >> >> I've been testing / using that code for a while now >> and am reasonably confident that it works. And it >> is not exactly rocket science, either. >> >> Because a large portion of my other performance >> work builds upon that low-latency caching feature, >> it would really like to see it being merged. Directly >> after the merge, I will make the feature strictly opt-in >> instead of defaulting to a 16 or 64 MB cache. > > I'd say merging to trunk is perfectly fine if you're confident that > there aren't any roadblock issues and it's not enabled by default anyway. > We've released optional new features in the past (e.g. libsvn_serf). > It's much more likely to get tested this way :)
It won't get tested very much if it's disabled (made "opt-in") directly after being merged back to trunk. :) I'd say merge to trunk, leave it enabled, and *if* we see some big problems, we can throw the kill switch prior to shipping. It's trunk, for goodness' sake, it doesn't have to be pristine. My $.02, -Hyrum
