I should clarify that I didn't mean "ignore", but a test on virtual machines, of unknown provenance, that are merely "similar" is enough to make me very suspicious of any benchmark. If anyone wanted to perform a more rigorous and diligent test (like, say, *only* changing the couchdb source code between identical test runs), then I'd certainly want to halt the release if the 1/10th result were confirmed.
b. On 23 February 2012 22:25, Bob Dionne <[email protected]> wrote: > sorry Noah, I'm in debug mode today so I don't care to start mucking with my > stack, recompiling erlang, etc... > > I did try using that build repeatedly and it crashes all the time. I find it > very odd and I had seen those before as I said on my older macbook. > > I do see the hangs Jan describes in the etaps, they have been there right > along, so I'm confident this just the SSL issue. Why it only happens on the > build is puzzling, any source build of any branch works just peachy. > > So I'd say I'm +1 based on my use of the 1.2.x branch but I'd like to hear > from Stefan, who reported the severe performance regression. BobN seems to > think we can ignore that, it's something flaky in that fellow's environment. > I tend to agree but I'm conservative > > On Feb 23, 2012, at 1:23 PM, Noah Slater wrote: > >> Can someone convince me this bus error stuff and segfaults is not a >> blocking issue. >> >> Bob tells me that he's followed the steps above and he's still experiencing >> the issues. >> >> Bob, you did follow the steps to install your own SSL right? >> >> On Thu, Feb 23, 2012 at 5:09 PM, Jan Lehnardt <[email protected]> wrote: >> >>> >>> On Feb 23, 2012, at 00:28 , Noah Slater wrote: >>> >>>> Hello, >>>> >>>> I would like call a vote for the Apache CouchDB 1.2.0 release, second >>> round. >>>> >>>> We encourage the whole community to download and test these >>>> release artifacts so that any critical issues can be resolved before the >>>> release is made. Everyone is free to vote on this release, so get stuck >>> in! >>>> >>>> We are voting on the following release artifacts: >>>> >>>> http://people.apache.org/~nslater/dist/1.2.0/ >>>> >>>> >>>> These artifacts have been built from the following tree-ish in Git: >>>> >>>> 4cd60f3d1683a3445c3248f48ae064fb573db2a1 >>>> >>>> >>>> Please follow the test procedure before voting: >>>> >>>> http://wiki.apache.org/couchdb/Test_procedure >>>> >>>> >>>> Thank you. >>>> >>>> Happy voting, >>> >>> Signature and hashes check out. >>> >>> Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.0, Erlang R14B04: make check >>> works fine, browser tests in Safari work fine. >>> >>> Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check >>> works fine, browser tests in Safari work fine. >>> >>> FreeBSD 9.0, 64bit, SpiderMonkey 1.7.0, Erlang R14B04: make check works >>> fine, browser tests in Safari work fine. >>> >>> CentOS 6.2, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works >>> fine, browser tests in Firefox work fine. >>> >>> Ubuntu 11.4, 64bit, SpiderMonkey 1.8.5, Erlang R14B02: make check works >>> fine, browser tests in Firefox work fine. >>> >>> Ubuntu 10.4, 32bit, SpiderMonkey 1.8.0, Erlang R13B03: make check fails in >>> - 076-file-compression.t: https://gist.github.com/1893373 >>> - 220-compaction-daemon.t: https://gist.github.com/1893387 >>> This on runs in a VM and is 32bit, so I don't know if there's anything in >>> the tests that rely on 64bittyness or the R14B03. Filipe, I think you >>> worked on both features, do you have an idea? >>> >>> I tried running it all through Erlang R15B on Mac OS X 1.7.3, but a good >>> way into `make check` the tests would just stop and hang. The last time, >>> repeatedly in 160-vhosts.t, but when run alone, that test finished in under >>> five seconds. I'm not sure what the issue is here. >>> >>> Despite the things above, I'm happy to give this a +1 if we put a warning >>> about R15B on the download page. >>> >>> Great work all! >>> >>> Cheers >>> Jan >>> -- >>> >>> >
