subject:"Re\: \[VOTE\] Apache CouchDB 1.2.0 release, second round"

Thanks Benoit!

* * *

As an update to the ongoing 1.2.0 release these issues were raised:

 - Performance regression (A thread on dev@)
 - Multiple Spidermonkey version detection (COUCHDB-1426)
 - R15B icu_driver compatibility (git branch R15B0-driver)
 - R15B make check hang on Mac OS X Lion (COUCHDB-1424)

I'd like to give a quick update on each of them and I'll propose a plan
of action. If you disagree with any of my updates or the conclusion,
please speak up :)

* Performance Regression

We started collecting a bunch of numbers for a few select scenarios,
some of which show a regression, most of which show an improvement
though. We haven't yet identified the variables that cause all this
(different Spidermonkey releases made a huge difference in one case). So
far the test cases don't cover much ground. E.g. we haven't had a chance
to reproduce one of the reports that we don't have direct access too.

I believe getting a better understanding of what is going on here will
take some more time. Time that we should absolutely spend, so we are
able to show some baseline performance numbers going forward to compare
improvements and future releases against.

* COUCHDB-1426

We are still discussing the intention and merits of the patch and I
believe there's definitely something to fix eventually, but I don't
think this should hold 1.2.0. Benoit, who reported it initially and made
it blocking, agrees under the condition that we ship 1.2.1 soonish that
includes a resolution for this ticket.

* R15B0-driver

This renders 1.2.0 as is incompatible with the latest Erlang R15B
release. The fix is trivial, but it didn't make the release artefact.

* COUCHDB-1424

I so far could show that this only happens on Mac OS X Lion and R15B but
nowhere else. I'm happy to conclude that this isn't a release blocking
issue. However, we should resolve it for the 1.2.1 release like
COUCHDB-1426.

* * *

Proposed Action:

I'd propose to release 1.2.0 as-is with the following points mentioned
in the release notes (the exact wording of which is to be done):

1. Note that this release is incompatible with Erlang R15B. A patch is
available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.

2. Also note that there are some reports of a performance regression in
view building. While initial and ad-hoc tests showed an improvement in
most cases, we'd like to ask our users to report any significant
differences to the Apache CouchDB 1.1.1 release.

* * *

I'm happy to alter the plan of action based on your feedback, I just
want to make sure we know which issues we are discussing and what their
respective states are to move this forward.

* * *

https://issues.apache.org/jira/browse/COUCHDB-1424
https://issues.apache.org/jira/browse/COUCHDB-1426
http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=b1af764b

Cheers
Jan
-- 


On Mar 2, 2012, at 13:48 , Benoit Chesneau wrote:

 On Thu, Mar 1, 2012 at 12:21 AM, Benoit Chesneau bchesn...@gmail.com wrote:
 
 
 Posted a patch fixing COUCHDB-1426.
 
 https://issues.apache.org/jira/browse/COUCHDB-1426
 
 After some discussions, I made the issue none blocking but critical.
 I'm now +0 I guess.
 
 - benoît

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-03-02 Thread Robert Newson

+1

On 2 March 2012 15:29, Jan Lehnardt j...@apache.org wrote:
 Thanks Benoit!

 * * *

 As an update to the ongoing 1.2.0 release these issues were raised:

  - Performance regression (A thread on dev@)
  - Multiple Spidermonkey version detection (COUCHDB-1426)
  - R15B icu_driver compatibility (git branch R15B0-driver)
  - R15B make check hang on Mac OS X Lion (COUCHDB-1424)

 I'd like to give a quick update on each of them and I'll propose a plan
 of action. If you disagree with any of my updates or the conclusion,
 please speak up :)

 * Performance Regression

 We started collecting a bunch of numbers for a few select scenarios,
 some of which show a regression, most of which show an improvement
 though. We haven't yet identified the variables that cause all this
 (different Spidermonkey releases made a huge difference in one case). So
 far the test cases don't cover much ground. E.g. we haven't had a chance
 to reproduce one of the reports that we don't have direct access too.

 I believe getting a better understanding of what is going on here will
 take some more time. Time that we should absolutely spend, so we are
 able to show some baseline performance numbers going forward to compare
 improvements and future releases against.

 * COUCHDB-1426

 We are still discussing the intention and merits of the patch and I
 believe there's definitely something to fix eventually, but I don't
 think this should hold 1.2.0. Benoit, who reported it initially and made
 it blocking, agrees under the condition that we ship 1.2.1 soonish that
 includes a resolution for this ticket.

 * R15B0-driver

 This renders 1.2.0 as is incompatible with the latest Erlang R15B
 release. The fix is trivial, but it didn't make the release artefact.

 * COUCHDB-1424

 I so far could show that this only happens on Mac OS X Lion and R15B but
 nowhere else. I'm happy to conclude that this isn't a release blocking
 issue. However, we should resolve it for the 1.2.1 release like
 COUCHDB-1426.

 * * *

 Proposed Action:

 I'd propose to release 1.2.0 as-is with the following points mentioned
 in the release notes (the exact wording of which is to be done):

 1. Note that this release is incompatible with Erlang R15B. A patch is
 available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.

 2. Also note that there are some reports of a performance regression in
 view building. While initial and ad-hoc tests showed an improvement in
 most cases, we'd like to ask our users to report any significant
 differences to the Apache CouchDB 1.1.1 release.

 * * *

 I'm happy to alter the plan of action based on your feedback, I just
 want to make sure we know which issues we are discussing and what their
 respective states are to move this forward.

 * * *

 https://issues.apache.org/jira/browse/COUCHDB-1424
 https://issues.apache.org/jira/browse/COUCHDB-1426
 http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=b1af764b

 Cheers
 Jan
 --


 On Mar 2, 2012, at 13:48 , Benoit Chesneau wrote:

 On Thu, Mar 1, 2012 at 12:21 AM, Benoit Chesneau bchesn...@gmail.com wrote:


 Posted a patch fixing COUCHDB-1426.

 https://issues.apache.org/jira/browse/COUCHDB-1426

 After some discussions, I made the issue none blocking but critical.
 I'm now +0 I guess.

 - benoît

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-03-02 Thread Dirkjan Ochtman

On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
 Proposed Action:

 I'd propose to release 1.2.0 as-is with the following points mentioned
 in the release notes (the exact wording of which is to be done):

 1. Note that this release is incompatible with Erlang R15B. A patch is
 available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.

 2. Also note that there are some reports of a performance regression in
 view building. While initial and ad-hoc tests showed an improvement in
 most cases, we'd like to ask our users to report any significant
 differences to the Apache CouchDB 1.1.1 release.

While I am usually cheering on the release process, taken together it
seems more prudent to abort this round, take the R15B driver and the
142{4,6} patches and then starting a new round.

Cheers,

Dirkjan

Re: [VOTE] Apache CouchDB 1.2.0 release, second round


On Mar 2, 2012, at 16:47 , Dirkjan Ochtman wrote:

 On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
 Proposed Action:
 
 I'd propose to release 1.2.0 as-is with the following points mentioned
 in the release notes (the exact wording of which is to be done):
 
 1. Note that this release is incompatible with Erlang R15B. A patch is
 available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.
 
 2. Also note that there are some reports of a performance regression in
 view building. While initial and ad-hoc tests showed an improvement in
 most cases, we'd like to ask our users to report any significant
 differences to the Apache CouchDB 1.1.1 release.
 
 While I am usually cheering on the release process, taken together it
 seems more prudent to abort this round, take the R15B driver and the
 142{4,6} patches and then starting a new round.

I'd agree if 142{4,6} were decided tickets, but they are still ongoing
and potentially, in the 24-case especially, for a while.

Cheers
Jan
--

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-03-02 Thread Noah Slater

I think we should, at a minimum:

* Abort this round
* Land the R15B patch
* Land COUCHDB-1426 (which seems easy)
* Start round three

I think we should try to:

* Try to land COUCHDB-1424
* Get clarification on the performance issues

For these last two items, I think we should impose a time limit. Let's say
a week.

I think we should also form some teams, to see if we can do some sprints to
get these issues fixed.


On Fri, Mar 2, 2012 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:


 On Mar 2, 2012, at 16:47 , Dirkjan Ochtman wrote:

  On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
  Proposed Action:
 
  I'd propose to release 1.2.0 as-is with the following points mentioned
  in the release notes (the exact wording of which is to be done):
 
  1. Note that this release is incompatible with Erlang R15B. A patch is
  available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.
 
  2. Also note that there are some reports of a performance regression in
  view building. While initial and ad-hoc tests showed an improvement in
  most cases, we'd like to ask our users to report any significant
  differences to the Apache CouchDB 1.1.1 release.
 
  While I am usually cheering on the release process, taken together it
  seems more prudent to abort this round, take the R15B driver and the
  142{4,6} patches and then starting a new round.

 I'd agree if 142{4,6} were decided tickets, but they are still ongoing
 and potentially, in the 24-case especially, for a while.

 Cheers
 Jan
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-03-02 Thread Dirkjan Ochtman

On Fri, Mar 2, 2012 at 17:02, Noah Slater nsla...@tumbolia.org wrote:
 I think we should, at a minimum:

 * Abort this round
 * Land the R15B patch
 * Land COUCHDB-1426 (which seems easy)
 * Start round three

 I think we should try to:

 * Try to land COUCHDB-1424
 * Get clarification on the performance issues

 For these last two items, I think we should impose a time limit. Let's say
 a week.

 I think we should also form some teams, to see if we can do some sprints to
 get these issues fixed.

+1 this is closer to what I feel would be the right thing.

Cheers,

Dirkjan

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-03-02 Thread Robert Newson

+1. Abort this, get the fixes we have in and start round 3. The
performance regression issue is elusive, we might, out of necessity,
have to defer action on that until post 1.2.0.


On 2 March 2012 16:02, Noah Slater nsla...@tumbolia.org wrote:
 I think we should, at a minimum:

 * Abort this round
 * Land the R15B patch
 * Land COUCHDB-1426 (which seems easy)
 * Start round three

 I think we should try to:

 * Try to land COUCHDB-1424
 * Get clarification on the performance issues

 For these last two items, I think we should impose a time limit. Let's say
 a week.

 I think we should also form some teams, to see if we can do some sprints to
 get these issues fixed.


 On Fri, Mar 2, 2012 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:


 On Mar 2, 2012, at 16:47 , Dirkjan Ochtman wrote:

  On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
  Proposed Action:
 
  I'd propose to release 1.2.0 as-is with the following points mentioned
  in the release notes (the exact wording of which is to be done):
 
  1. Note that this release is incompatible with Erlang R15B. A patch is
  available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.
 
  2. Also note that there are some reports of a performance regression in
  view building. While initial and ad-hoc tests showed an improvement in
  most cases, we'd like to ask our users to report any significant
  differences to the Apache CouchDB 1.1.1 release.
 
  While I am usually cheering on the release process, taken together it
  seems more prudent to abort this round, take the R15B driver and the
  142{4,6} patches and then starting a new round.

 I'd agree if 142{4,6} were decided tickets, but they are still ongoing
 and potentially, in the 24-case especially, for a while.

 Cheers
 Jan
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round


On Mar 2, 2012, at 17:02 , Noah Slater wrote:

 I think we should, at a minimum:
 
 * Abort this round
 * Land the R15B patch
 * Land COUCHDB-1426 (which seems easy)
 * Start round three
 
 I think we should try to:
 
 * Try to land COUCHDB-1424
 * Get clarification on the performance issues
 
 For these last two items, I think we should impose a time limit. Let's say
 a week.
 
 I think we should also form some teams, to see if we can do some sprints to
 get these issues fixed.


Sounds like a plan, let's go!

 
 
 On Fri, Mar 2, 2012 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:
 
 
 On Mar 2, 2012, at 16:47 , Dirkjan Ochtman wrote:
 
 On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
 Proposed Action:
 
 I'd propose to release 1.2.0 as-is with the following points mentioned
 in the release notes (the exact wording of which is to be done):
 
 1. Note that this release is incompatible with Erlang R15B. A patch is
 available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.
 
 2. Also note that there are some reports of a performance regression in
 view building. While initial and ad-hoc tests showed an improvement in
 most cases, we'd like to ask our users to report any significant
 differences to the Apache CouchDB 1.1.1 release.
 
 While I am usually cheering on the release process, taken together it
 seems more prudent to abort this round, take the R15B driver and the
 142{4,6} patches and then starting a new round.
 
 I'd agree if 142{4,6} were decided tickets, but they are still ongoing
 and potentially, in the 24-case especially, for a while.
 
 Cheers
 Jan
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-03-02 Thread Noah Slater

Vote aborted. Thanks to everyone who took part.

Five people have claimed ownership of the five remaining tasks:

* Bob Dionne will driving COUCHDB-1424
* Benoît Chesneau will be driving COUCHDB-1426
* Jan Lehnardt will be driving the R15B patch
* Robert Newson will be driving the performance work
* I will be driving round three, obviously

Let's kick some ass!

On Fri, Mar 2, 2012 at 4:05 PM, Robert Newson rnew...@apache.org wrote:

 +1. Abort this, get the fixes we have in and start round 3. The
 performance regression issue is elusive, we might, out of necessity,
 have to defer action on that until post 1.2.0.


 On 2 March 2012 16:02, Noah Slater nsla...@tumbolia.org wrote:
  I think we should, at a minimum:
 
  * Abort this round
  * Land the R15B patch
  * Land COUCHDB-1426 (which seems easy)
  * Start round three
 
  I think we should try to:
 
  * Try to land COUCHDB-1424
  * Get clarification on the performance issues
 
  For these last two items, I think we should impose a time limit. Let's
 say
  a week.
 
  I think we should also form some teams, to see if we can do some sprints
 to
  get these issues fixed.
 
 
  On Fri, Mar 2, 2012 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:
 
 
  On Mar 2, 2012, at 16:47 , Dirkjan Ochtman wrote:
 
   On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
   Proposed Action:
  
   I'd propose to release 1.2.0 as-is with the following points
 mentioned
   in the release notes (the exact wording of which is to be done):
  
   1. Note that this release is incompatible with Erlang R15B. A patch
 is
   available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.
  
   2. Also note that there are some reports of a performance regression
 in
   view building. While initial and ad-hoc tests showed an improvement
 in
   most cases, we'd like to ask our users to report any significant
   differences to the Apache CouchDB 1.1.1 release.
  
   While I am usually cheering on the release process, taken together it
   seems more prudent to abort this round, take the R15B driver and the
   142{4,6} patches and then starting a new round.
 
  I'd agree if 142{4,6} were decided tickets, but they are still ongoing
  and potentially, in the 24-case especially, for a while.
 
  Cheers
  Jan
  --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round


On Mar 2, 2012, at 17:28 , Noah Slater wrote:

 Vote aborted. Thanks to everyone who took part.
 
 Five people have claimed ownership of the five remaining tasks:
 
 * Bob Dionne will driving COUCHDB-1424
 * Benoît Chesneau will be driving COUCHDB-1426
 * Jan Lehnardt will be driving the R15B patch

√

http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=776aa1d0

Landed in both 1.2.x and master. Thanks to Paul Davis for coming up with
the more canonical C version.

Cheers
Jan
-- 

 * Robert Newson will be driving the performance work
 * I will be driving round three, obviously
 
 Let's kick some ass!
 
 On Fri, Mar 2, 2012 at 4:05 PM, Robert Newson rnew...@apache.org wrote:
 
 +1. Abort this, get the fixes we have in and start round 3. The
 performance regression issue is elusive, we might, out of necessity,
 have to defer action on that until post 1.2.0.
 
 
 On 2 March 2012 16:02, Noah Slater nsla...@tumbolia.org wrote:
 I think we should, at a minimum:
 
 * Abort this round
 * Land the R15B patch
 * Land COUCHDB-1426 (which seems easy)
 * Start round three
 
 I think we should try to:
 
 * Try to land COUCHDB-1424
 * Get clarification on the performance issues
 
 For these last two items, I think we should impose a time limit. Let's
 say
 a week.
 
 I think we should also form some teams, to see if we can do some sprints
 to
 get these issues fixed.
 
 
 On Fri, Mar 2, 2012 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:
 
 
 On Mar 2, 2012, at 16:47 , Dirkjan Ochtman wrote:
 
 On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
 Proposed Action:
 
 I'd propose to release 1.2.0 as-is with the following points
 mentioned
 in the release notes (the exact wording of which is to be done):
 
 1. Note that this release is incompatible with Erlang R15B. A patch
 is
 available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.
 
 2. Also note that there are some reports of a performance regression
 in
 view building. While initial and ad-hoc tests showed an improvement
 in
 most cases, we'd like to ask our users to report any significant
 differences to the Apache CouchDB 1.1.1 release.
 
 While I am usually cheering on the release process, taken together it
 seems more prudent to abort this round, take the R15B driver and the
 142{4,6} patches and then starting a new round.
 
 I'd agree if 142{4,6} were decided tickets, but they are still ongoing
 and potentially, in the 24-case especially, for a while.
 
 Cheers
 Jan
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-03-02 Thread Noah Slater

Have you updated NEWS and CHANGES?

On Fri, Mar 2, 2012 at 5:47 PM, Jan Lehnardt j...@apache.org wrote:


 On Mar 2, 2012, at 17:28 , Noah Slater wrote:

  Vote aborted. Thanks to everyone who took part.
 
  Five people have claimed ownership of the five remaining tasks:
 
  * Bob Dionne will driving COUCHDB-1424
  * Benoît Chesneau will be driving COUCHDB-1426
  * Jan Lehnardt will be driving the R15B patch

 √

 http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=776aa1d0

 Landed in both 1.2.x and master. Thanks to Paul Davis for coming up with
 the more canonical C version.

 Cheers
 Jan
 --

  * Robert Newson will be driving the performance work
  * I will be driving round three, obviously
 
  Let's kick some ass!
 
  On Fri, Mar 2, 2012 at 4:05 PM, Robert Newson rnew...@apache.org
 wrote:
 
  +1. Abort this, get the fixes we have in and start round 3. The
  performance regression issue is elusive, we might, out of necessity,
  have to defer action on that until post 1.2.0.
 
 
  On 2 March 2012 16:02, Noah Slater nsla...@tumbolia.org wrote:
  I think we should, at a minimum:
 
  * Abort this round
  * Land the R15B patch
  * Land COUCHDB-1426 (which seems easy)
  * Start round three
 
  I think we should try to:
 
  * Try to land COUCHDB-1424
  * Get clarification on the performance issues
 
  For these last two items, I think we should impose a time limit. Let's
  say
  a week.
 
  I think we should also form some teams, to see if we can do some
 sprints
  to
  get these issues fixed.
 
 
  On Fri, Mar 2, 2012 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:
 
 
  On Mar 2, 2012, at 16:47 , Dirkjan Ochtman wrote:
 
  On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
  Proposed Action:
 
  I'd propose to release 1.2.0 as-is with the following points
  mentioned
  in the release notes (the exact wording of which is to be done):
 
  1. Note that this release is incompatible with Erlang R15B. A patch
  is
  available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.
 
  2. Also note that there are some reports of a performance regression
  in
  view building. While initial and ad-hoc tests showed an improvement
  in
  most cases, we'd like to ask our users to report any significant
  differences to the Apache CouchDB 1.1.1 release.
 
  While I am usually cheering on the release process, taken together it
  seems more prudent to abort this round, take the R15B driver and the
  142{4,6} patches and then starting a new round.
 
  I'd agree if 142{4,6} were decided tickets, but they are still ongoing
  and potentially, in the 24-case especially, for a while.
 
  Cheers
  Jan
  --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

Good catch, will do in the morning.

Cheers
Jan
--

On 02.03.2012, at 20:00, Noah Slater nsla...@tumbolia.org wrote:

 Have you updated NEWS and CHANGES?
 
 On Fri, Mar 2, 2012 at 5:47 PM, Jan Lehnardt j...@apache.org wrote:
 
 
 On Mar 2, 2012, at 17:28 , Noah Slater wrote:
 
 Vote aborted. Thanks to everyone who took part.
 
 Five people have claimed ownership of the five remaining tasks:
 
 * Bob Dionne will driving COUCHDB-1424
 * Benoît Chesneau will be driving COUCHDB-1426
 * Jan Lehnardt will be driving the R15B patch
 
 √
 
 http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=776aa1d0
 
 Landed in both 1.2.x and master. Thanks to Paul Davis for coming up with
 the more canonical C version.
 
 Cheers
 Jan
 --
 
 * Robert Newson will be driving the performance work
 * I will be driving round three, obviously
 
 Let's kick some ass!
 
 On Fri, Mar 2, 2012 at 4:05 PM, Robert Newson rnew...@apache.org
 wrote:
 
 +1. Abort this, get the fixes we have in and start round 3. The
 performance regression issue is elusive, we might, out of necessity,
 have to defer action on that until post 1.2.0.
 
 
 On 2 March 2012 16:02, Noah Slater nsla...@tumbolia.org wrote:
 I think we should, at a minimum:
 
 * Abort this round
 * Land the R15B patch
 * Land COUCHDB-1426 (which seems easy)
 * Start round three
 
 I think we should try to:
 
 * Try to land COUCHDB-1424
 * Get clarification on the performance issues
 
 For these last two items, I think we should impose a time limit. Let's
 say
 a week.
 
 I think we should also form some teams, to see if we can do some
 sprints
 to
 get these issues fixed.
 
 
 On Fri, Mar 2, 2012 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:
 
 
 On Mar 2, 2012, at 16:47 , Dirkjan Ochtman wrote:
 
 On Fri, Mar 2, 2012 at 16:29, Jan Lehnardt j...@apache.org wrote:
 Proposed Action:
 
 I'd propose to release 1.2.0 as-is with the following points
 mentioned
 in the release notes (the exact wording of which is to be done):
 
 1. Note that this release is incompatible with Erlang R15B. A patch
 is
 available at [LINK to DIFF]; it will appear in Apache CouchDB 1.2.1.
 
 2. Also note that there are some reports of a performance regression
 in
 view building. While initial and ad-hoc tests showed an improvement
 in
 most cases, we'd like to ask our users to report any significant
 differences to the Apache CouchDB 1.1.1 release.
 
 While I am usually cheering on the release process, taken together it
 seems more prudent to abort this round, take the R15B driver and the
 142{4,6} patches and then starting a new round.
 
 I'd agree if 142{4,6} were decided tickets, but they are still ongoing
 and potentially, in the 24-case especially, for a while.
 
 Cheers
 Jan
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-29 Thread Bob Dionne

Jan,

Sorry it took me a while to respond to this. As I said the db I was testing
with is about ~200K docs, with one large ddoc, about 10 views. It takes a
considerable long time to index, both on 1.1.x and 1.2.x but on 1.2.x it had
not made the same amount of progress after 45 minutes on 1.2.x as did the 1.1.x
run after 20 minutes, so I assumed that something has slowed, 40% maybe, that's
likely a number I pulled out of my hat from the chat and reports of others.

I understand this is hand-wavy, which is why I was reluctant to jump to
conclusions. Please note that I did not state we should stop this release, nor
did I state that any of the issues I enumerated were showstoppers. I stated,
with a -1 vote that the overall experience led me to conclude the release was
not sound. It's one vote and I always am happy to go with the majority.

I thought we were off to a good start on Sunday when I was digging in here. Yes
it's off topic as you and Noah agreed, but once you've pushed this out you
might want to revisit the release process. This slow_couchdb is definitely a
good smoke test, I like it, but beyond that it's sort of an instance of You're
doing it all wrong when it comes to performance. I'll be happy to elaborate on
this when we get to that.

Best Regards,

Bob

On Feb 27, 2012, at 8:15 AM, Jan Lehnardt wrote:

On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

Thanks for the clarification. I hope I'm not conflating things by continuing
the discussion here, I thought that's what you requested?

The discussion we had on IRC was regarding collecting more data items for the
performance regression before we start to draw conclusions.

My intention here is to understand what needs doing before we can release
1.2.0.

I'll reply inline for the other issues.

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

Just stops completely. This is on R15B which has been rebuilt to use the
recommended older SSL version. I haven't looked into this crashing too
closely but I'm suspicious that I only see it with couchdb and never with
bigcouch and never using the 1.2.x branch from source or any branch for that
matter

From the release you should run `make check`, not make distcheck. But I
assume you see a hang there too, as I have and others (yet not everybody),
too. I can't comment on BigCouch and what is different there. It is
interesting that 1.2.x won't hang. For me, `make check` in 1.2.x on R15B
hangs sometimes, in different places. I'm currently trying to gather more
information about this.

The question here is whether `make check` passing in R15B is a release
requirement. In my vote I considered no, but I am happy to go with a
community decision if it emerges. What is your take here?

In addition, this just shouldn't be a question, so we should investigate why
this happens at all and address the issue, hence COUCHDB-1424. Any insight
here would be appreciated as well.

In the command line tests, 2,7, 27, and 32 fail. but it differs from run to
run.

I assume you mean the JS tests. Again, this isn't supposed to work in 1.2.x.
I'm happy to backport my changes from master to 1.2.x to make that work, but
I refrained from that because I didn't want to bring too much change to a
release branch. I'm happy to reconsider, but I don't think a release vote is
a good place to discuss feature backports.

On Chrome attachment_ranges fails and it hangs on replicator_db

This one is an explaining away, but I think it is warranted. Chrome is
broken for attachment_ranges. I don't know if we reported this upstream
(Robert N?), but this isn't a release blocker. For the replicator_db test,
can you try running that in other browsers. I understand it is not the best
of situation (hence the move to the cli test suite for master), but if you
get this test to pass in at least one other browsers, this isn't a problem
that holds 1.2.x.

With respect to performance I think comparisons with 1.1.x are important. I
think almost any use case, contrived or otherwise should not be dismissed as
a pathological or edge case. Bob's script is as simple as it gets and to me
is a great smoke test. We need to figure out the reason 1.2 is clearly
slower in this case. If there are specific scenarios that 1.2.x is optimized
for then we should document that and provide reasons for the trade-offs

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-29 Thread Joan Touzet

On Sun, Feb 26, 2012 at 08:25:37PM +0100, Jan Lehnardt wrote:
 I ran Robert's test with a tiny doc and minimal view and saw the 25%
 performance drop, but using more realistic doc sizes and views show
 and improvement for 1.2.x (in one case 1k docs with a view that emits
 a complex key and an integer for the value).

On Debian testing, using all Debian-supplied packages except for Couch
itself, I do not see any performance regression. This is on spinning
platters, 24GB RAM, 4x Opteron processors split across a few vservers,
of which only one is running the couch test.

Because Jan's test case relies on bash and ruby, I've not been able to
run it on Windows, but I could attempt to run rnewson's approach via a
CMD/PowerShell script if desired.

IMO signs point to this being something OSX specific but it's just
speculation at this point.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-29 Thread Jan Lehnardt

Hi Bob,

thanks for your reply. I think this is a bit of a convoluted situation now and
I want to apologise for anything that might have upset you or anyone here. I
didn't mean to be insulting or anything.

I think the 1.2.0 release is very important for this community and the project,
so I am very interested in getting it out. I'm not interested in getting it out
at all costs but I do want to clarify what's needed to do the release.

In the process, your -1 turned out to trigger a hold on the 1.2.0 release, even
though you write you didn't intend that. Also in the process I confused your -1
to ask for the hold and as a result I got annoyed that you didn't provide more
information. I also asked for clarification on the other issues you raised
(e.g. running the test suite in Firefox/across multiple browsers) and you
haven't responded to yet (I understand time constraints, but I'd have
appreciated a gonna work on it sort of quick response).

I'm sorry I got annoyed and let it out on you.

All I want is to understand what it takes to release 1.2.0 and we need all your
(and everybody's) support to get there. So thanks for any contributions to this
discussion.

Cheers
Jan
--

On Feb 29, 2012, at 16:27 , Bob Dionne wrote:

Jan,

Sorry it took me a while to respond to this. As I said the db I was testing
with is about ~200K docs, with one large ddoc, about 10 views. It takes a
considerable long time to index, both on 1.1.x and 1.2.x but on 1.2.x it had
not made the same amount of progress after 45 minutes on 1.2.x as did the
1.1.x run after 20 minutes, so I assumed that something has slowed, 40%
maybe, that's likely a number I pulled out of my hat from the chat and
reports of others.

I understand this is hand-wavy, which is why I was reluctant to jump to
conclusions. Please note that I did not state we should stop this release,
nor did I state that any of the issues I enumerated were showstoppers. I
stated, with a -1 vote that the overall experience led me to conclude the
release was not sound. It's one vote and I always am happy to go with the
majority.

I thought we were off to a good start on Sunday when I was digging in here.
Yes it's off topic as you and Noah agreed, but once you've pushed this out
you might want to revisit the release process. This slow_couchdb is
definitely a good smoke test, I like it, but beyond that it's sort of an
instance of You're doing it all wrong when it comes to performance. I'll be
happy to elaborate on this when we get to that.

Best Regards,

Bob

On Feb 27, 2012, at 8:15 AM, Jan Lehnardt wrote:

On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

Thanks for the clarification. I hope I'm not conflating things by
continuing the discussion here, I thought that's what you requested?

The discussion we had on IRC was regarding collecting more data items for
the performance regression before we start to draw conclusions.

My intention here is to understand what needs doing before we can release
1.2.0.

I'll reply inline for the other issues.

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

The question here is whether `make check` passing in R15B is a release
requirement. In my vote I considered no, but I am happy to go with a
community decision if it emerges. What is your take here?

In addition, this just shouldn't be a question, so we should investigate why
this happens at all and address the issue, hence COUCHDB-1424. Any insight
here would be appreciated as well.

In the command line tests, 2,7, 27, and 32 fail. but it differs from run to
run.

On Chrome attachment_ranges fails and it hangs on replicator_db

This one is an explaining away, but

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-29 Thread Robert Newson

you might want to revisit the release process

You mean we here. :)

On 29 February 2012 16:23, Jan Lehnardt j...@apache.org wrote:
Hi Bob,

thanks for your reply. I think this is a bit of a convoluted situation now
and I want to apologise for anything that might have upset you or anyone
here. I didn't mean to be insulting or anything.

I think the 1.2.0 release is very important for this community and the
project, so I am very interested in getting it out. I'm not interested in
getting it out at all costs but I do want to clarify what's needed to do the
release.

In the process, your -1 turned out to trigger a hold on the 1.2.0 release,
even though you write you didn't intend that. Also in the process I confused
your -1 to ask for the hold and as a result I got annoyed that you didn't
provide more information. I also asked for clarification on the other issues
you raised (e.g. running the test suite in Firefox/across multiple browsers)
and you haven't responded to yet (I understand time constraints, but I'd have
appreciated a gonna work on it sort of quick response).

I'm sorry I got annoyed and let it out on you.

All I want is to understand what it takes to release 1.2.0 and we need all
your (and everybody's) support to get there. So thanks for any contributions
to this discussion.

Cheers
Jan
--

On Feb 29, 2012, at 16:27 , Bob Dionne wrote:

Jan,

Sorry it took me a while to respond to this. As I said the db I was testing
with is about ~200K docs, with one large ddoc, about 10 views. It takes a
considerable long time to index, both on 1.1.x and 1.2.x but on 1.2.x it had
not made the same amount of progress after 45 minutes on 1.2.x as did the
1.1.x run after 20 minutes, so I assumed that something has slowed, 40%
maybe, that's likely a number I pulled out of my hat from the chat and
reports of others.

I understand this is hand-wavy, which is why I was reluctant to jump to
conclusions. Please note that I did not state we should stop this release,
nor did I state that any of the issues I enumerated were showstoppers. I
stated, with a -1 vote that the overall experience led me to conclude the
release was not sound. It's one vote and I always am happy to go with the
majority.

I thought we were off to a good start on Sunday when I was digging in here.
Yes it's off topic as you and Noah agreed, but once you've pushed this out
you might want to revisit the release process. This slow_couchdb is
definitely a good smoke test, I like it, but beyond that it's sort of an
instance of You're doing it all wrong when it comes to performance. I'll
be happy to elaborate on this when we get to that.

Best Regards,

Bob

On Feb 27, 2012, at 8:15 AM, Jan Lehnardt wrote:

On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

Thanks for the clarification. I hope I'm not conflating things by
continuing the discussion here, I thought that's what you requested?

The discussion we had on IRC was regarding collecting more data items for
the performance regression before we start to draw conclusions.

My intention here is to understand what needs doing before we can release
1.2.0.

I'll reply inline for the other issues.

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

The question here is whether `make check` passing in R15B is a release
requirement. In my vote I considered no, but I am happy to go with a
community decision if it emerges. What is your take here?

In addition, this just shouldn't be a question, so we should investigate
why this happens at all and address the issue, hence COUCHDB-1424. Any
insight here would be appreciated as well.

In the command line tests, 2,7, 27, and 32 fail. but it differs from run
to run.

I assume you mean the JS tests. Again, this isn't supposed to work in
1.2.x. I'm happy to backport my changes from master to 1.2.x to make that
work, but I refrained from that because I didn't want to bring too much
change to a release branch. I'm happy to reconsider, but I don't think a
release vote is a good place to

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-29 Thread Benoit Chesneau

On Wed, Feb 29, 2012 at 7:30 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Fri, Feb 24, 2012 at 4:39 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Feb 23, 2012 at 12:28 AM, Noah Slater nsla...@tumbolia.org 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,

 N

 +1 make check , js tests  signatures ok

 erlang R14B04 - osx lion  snow leopard, ubuntu 11.04, 11.10, debian 6, fbsd 
 8.2

 - benoît

 While testing the reported issue I found COUCHDB-1426 which means we
 can't build couchdb with a different spidermonkey lib when another one
 is installed.

 I'm now -1 on this release.

 Also where can I set the icu lib path now ? The option doesn't appear
 any more in the ./configure command , only for windows.

 - benoît

Posted a patch fixing COUCHDB-1426.

https://issues.apache.org/jira/browse/COUCHDB-1426

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-28 Thread Filipe David Manana

Jason, made some more tests with larger documents (template is
https://gist.github.com/1930804) and a different map function:

function(doc) {
   emit([doc.type, doc.category], doc.nested.coords);
}

(patch http://friendpaste.com/5C99aqXocN6N6H1BAYIigs)

Here's the results I got ( https://gist.github.com/1930807 )


Before COUCHDB-1186

fdmanana 23:21:05 ~/git/hub/slow_couchdb (master) docs=50
batch=5000 ./bench.sh wow.tpl
Server: CouchDB/1.2.0a-a68a792-git (Erlang OTP/R14B03)
{couchdb:Welcome,version:1.2.0a-a68a792-git}

[INFO] Created DB named `db1'
[INFO] Uploaded 5000 documents via _bulk_docs
()
[INFO] Uploaded 5000 documents via _bulk_docs
Building view.
{total_rows:50,offset:0,rows:[
{id:00051ef7-d735-48d7-9ba8-5a21a86e8d57,key:[dwarf,assassin],value:[{x:31227.35,y:31529.73},{x:116667.85,y:82008.25},{x:224.11,y:36652.41},{x:128565.95,y:6780.2},{x:165230.43,y:176208.63}]}
]}

real5m6.676s
user0m0.009s
sys 0m0.010s


After COUCHDB-1186

fdmanana 23:50:07 ~/git/hub/slow_couchdb (master) docs=50
batch=5000 ./bench.sh wow.tpl
Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R14B03)
{couchdb:Welcome,version:1.2.0a-f023052-git}

[INFO] Created DB named `db1'
[INFO] Uploaded 5000 documents via _bulk_docs
()
[INFO] Uploaded 5000 documents via _bulk_docs
Building view.
{total_rows:50,offset:0,rows:[
{id:00051ef7-d735-48d7-9ba8-5a21a86e8d57,key:[dwarf,assassin],value:[{x:31227.35,y:31529.73},{x:116667.85,y:82008.25},{x:224.11,y:36652.41},{x:128565.95,y:6780.2},{x:165230.43,y:176208.63}]}
]}

real5m1.395s
user0m0.008s
sys 0m0.010s


After COUCHDB-1186 + better queueing patch (
http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w )

fdmanana 00:14:25 ~/git/hub/slow_couchdb (master) docs=50
batch=5000 ./bench.sh wow.tpl
Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R14B03)
{couchdb:Welcome,version:1.2.0a-f023052-git}

[INFO] Created DB named `db1'
[INFO] Uploaded 5000 documents via _bulk_docs
()
[INFO] Uploaded 5000 documents via _bulk_docs
Building view.
{total_rows:50,offset:0,rows:[
{id:00051ef7-d735-48d7-9ba8-5a21a86e8d57,key:[dwarf,assassin],value:[{x:31227.35,y:31529.73},{x:116667.85,y:82008.25},{x:224.11,y:36652.41},{x:128565.95,y:6780.2},{x:165230.43,y:176208.63}]}
]}

real4m48.175s
user0m0.008s
sys 0m0.009s


Disk model is APPLE SSD TS128C, quad core machine, 8Gb of ram.

Unfortunately I don't have access to the machine I used for the tests
in COUCHDB-1186 (spinning disk, Linux) before next week.


On Mon, Feb 27, 2012 at 7:49 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
 On Mon, Feb 27, 2012 at 7:18 PM, Filipe David Manana
 fdman...@apache.org wrote:
 Jason, can't reproduce those results, not even close:

 http://friendpaste.com/1L4pHH8WQchaLIMCWhKX9Z

 Before COUCHDB-1186

 fdmanana 16:58:02 ~/git/hub/slow_couchdb (master) docs=50
 batch=5 ./bench.sh small_doc.tpl
 Server: CouchDB/1.2.0a-a68a792-git (Erlang OTP/R14B03)
 {couchdb:Welcome,version:1.2.0a-a68a792-git}

 [INFO] Created DB named `db1'
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 Building view.
 {total_rows:50,offset:0,rows:[
 {id:doc1,key:1,value:1}
 ]}

 real    0m56.241s
 user    0m0.006s
 sys     0m0.005s


 After COUCHDB-1186

 fdmanana 17:02:02 ~/git/hub/slow_couchdb (master) docs=50
 batch=5 ./bench.sh small_doc.tpl
 Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R14B03)
 {couchdb:Welcome,version:1.2.0a-f023052-git}

 [INFO] Created DB named `db1'
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 Building view.
 {total_rows:50,offset:0,rows:[
 {id:doc1,key:1,value:1}
 ]}

 real    1m11.694s
 user    0m0.006s
 sys     0m0.005s
 fdmanana 17:06:01 ~/git/hub/slow_couchdb (master)


 1.2.0a-f023052-git with patch
 http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w  applied on top

 fdmanana 17:06:53 ~/git/hub/slow_couchdb (master) docs=50
 batch=5 ./bench.sh small_doc.tpl
 Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R14B03)
 {couchdb:Welcome,version:1.2.0a-f023052-git}

 [INFO] Created DB named `db1'
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-28 Thread Benoit Chesneau

On Tue, Feb 28, 2012 at 4:49 AM, Paul Davis paul.joseph.da...@gmail.com wrote

 Yeah, I've seen the btree behave quite differently on SSD's vs HDD's
 (same code had drastically different runtime characteristics).

 In other words, can we get a report of what type of disk everyone is running 
 on?

+ 1 .

We actually pollute this thread about vote, and the ticket about view
speedups which could be related or not :) Maybe we could open a ticket
to collect all the feedback and tests we have ?

Also noah, jan what is the status of this vote? Should we consider it
as aborted or paused?

- benoit

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-28 Thread Bob Dionne

Filipe,

This additional patch looks good, though I haven't tested it. Interesting
comment about R15B, I did notice a difference with BigCouch in terms of some of
the internal race conditions we see at times. Perhaps there are some
performance changes relating to that. I also recently upgraded from the Macbook
pro to a MBA so who knows.

I ran Jason and Bob's scripts a bit last night and saw similar slow downs
between 1.1 and 1.2, though as reported elsewhere with larger docs it's less of
an issue. In this patch[1] there's clearly a savings in avoiding the decode
call, but I wonder how often that case obtains compared to the others. If {cmd,
CMD} dominates then there is an additional overhead incurred however small it
might be. Perhaps this explains why the benefits appear for larger docs only.

Anyway, just speculation from the code.

Regards,

Bob

[1] https://github.com/fdmanana/couchdb/commit/cce325378723c863f05cca21

On Feb 27, 2012, at 11:33 AM, Filipe David Manana wrote:

I just tried Jason's script (modified it to use 500 000 docs instead
of 50 000) against 1.2.x and 1.1.1, using OTP R14B03. Here's my
results:

1.2.x:

$ port=5984 ./test.sh
none
Filling db.
done
HTTP/1.1 200 OK
Server: CouchDB/1.2.0 (Erlang OTP/R14B03)
Date: Mon, 27 Feb 2012 16:08:43 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 252
Cache-Control: must-revalidate

{db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:130494577,data_size:130490673,instance_start_time:1330358830830086,disk_format_version:6,committed_update_seq:51}
Building view.

real 1m5.725s
user 0m0.006s
sys 0m0.005s
done

1.1.1:

$ port=5984 ./test.sh

Filling db.
done
HTTP/1.1 200 OK
Server: CouchDB/1.1.2a785d32f-git (Erlang OTP/R14B03)
Date: Mon, 27 Feb 2012 16:15:33 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 230
Cache-Control: must-revalidate

{db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:122142818,instance_start_time:1330359233327316,disk_format_version:5,committed_update_seq:51}
Building view.

real 1m4.249s
user 0m0.006s
sys 0m0.005s
done

I don't see any significant difference there.

Regarding COUCHDB-1186, the only thing that might cause some non
determinism and affect performance is the queing/dequeing. Depending
on timings, it's possible the writer is dequeing less items per
dequeue operation and therefore inserting smaller batches into the
btree. The following small change ensures larger batches (while still
respecting the queue max size/item count):

http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

Running the test with this change:

$ port=5984 ./test.sh
none
Filling db.
done
HTTP/1.1 200 OK
Server: CouchDB/1.2.0 (Erlang OTP/R14B03)
Date: Mon, 27 Feb 2012 16:23:20 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 252
Cache-Control: must-revalidate

{db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:130494577,data_size:130490673,instance_start_time:1330359706846104,disk_format_version:6,committed_update_seq:51}
Building view.

real 0m49.762s
user 0m0.006s
sys 0m0.005s
done

If there's no objection, I'll push that patch.

Also, another note, I noticed sometime ago that with master, using OTP
R15B I got a performance drop of 10% to 15% compared to using master
with OTP R14B04. Maybe it applies to 1.2.x as well.

On Mon, Feb 27, 2012 at 5:33 AM, Robert Newson rnew...@apache.org wrote:
Bob D, can you give more details on the data set you're testing?
Number of docs, size/complexity of docs, etc? Basically, enough info
that I could write a script to automate building an equivalent
database.

I wrote a quick bash script to make a database and time a view build
here: http://friendpaste.com/7kBiKJn3uX1KiGJAFPv4nK

On 27 February 2012 13:15, Jan Lehnardt j...@apache.org wrote:

On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

Thanks for the clarification. I hope I'm not conflating things by
continuing the discussion here, I thought that's what you requested?

The discussion we had on IRC was regarding collecting more data items for
the performance regression before we start to draw conclusions.

My intention here is to understand what needs doing before we can release
1.2.0.

I'll reply inline for the other issues.

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-28 Thread Benoit Chesneau

On Tue, Feb 28, 2012 at 11:05 AM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Tue, Feb 28, 2012 at 4:49 AM, Paul Davis paul.joseph.da...@gmail.com 
 wrote

 Yeah, I've seen the btree behave quite differently on SSD's vs HDD's
 (same code had drastically different runtime characteristics).

 In other words, can we get a report of what type of disk everyone is running 
 on?

 + 1 .

 We actually pollute this thread about vote, and the ticket about view
 speedups which could be related or not :) Maybe we could open a ticket
 to collect all the feedback and tests we have ?

N / Y ?

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-28 Thread Robert Newson

I'm running my script on a EC2 node with spinning media, the numbers
come out the same for 1.1.1 vs 1.2. The only time I've seen a slowdown
with a scripted approach is my original one which didn't use bulk
docs. :/

On 28 February 2012 11:33, Bob Dionne dio...@dionne-associates.com wrote:
Filipe,

This additional patch looks good, though I haven't tested it. Interesting
comment about R15B, I did notice a difference with BigCouch in terms of some
of the internal race conditions we see at times. Perhaps there are some
performance changes relating to that. I also recently upgraded from the
Macbook pro to a MBA so who knows.

I ran Jason and Bob's scripts a bit last night and saw similar slow downs
between 1.1 and 1.2, though as reported elsewhere with larger docs it's less
of an issue. In this patch[1] there's clearly a savings in avoiding the
decode call, but I wonder how often that case obtains compared to the others.
If {cmd, CMD} dominates then there is an additional overhead incurred however
small it might be. Perhaps this explains why the benefits appear for larger
docs only.

Anyway, just speculation from the code.

Regards,

Bob

[1] https://github.com/fdmanana/couchdb/commit/cce325378723c863f05cca21

On Feb 27, 2012, at 11:33 AM, Filipe David Manana wrote:

I just tried Jason's script (modified it to use 500 000 docs instead
of 50 000) against 1.2.x and 1.1.1, using OTP R14B03. Here's my
results:

1.2.x:

real 1m5.725s
user 0m0.006s
sys 0m0.005s
done

1.1.1:

$ port=5984 ./test.sh

real 1m4.249s
user 0m0.006s
sys 0m0.005s
done

I don't see any significant difference there.

http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

Running the test with this change:

{db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:130494577,data_size:130490673,instance_start_time:1330359706846104,disk_format_version:6,committed_update_seq:51}
Building view.

real 0m49.762s
user 0m0.006s
sys 0m0.005s
done

If there's no objection, I'll push that patch.

Also, another note, I noticed sometime ago that with master, using OTP
R15B I got a performance drop of 10% to 15% compared to using master
with OTP R14B04. Maybe it applies to 1.2.x as well.

I wrote a quick bash script to make a database and time a view build
here: http://friendpaste.com/7kBiKJn3uX1KiGJAFPv4nK

On 27 February 2012 13:15, Jan Lehnardt j...@apache.org wrote:

On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

Thanks for the clarification. I hope I'm not conflating things by
continuing the discussion here, I thought that's what you requested?

The discussion we had on IRC was regarding collecting more data items for
the performance regression before we start to draw conclusions.

My intention here is to understand what needs doing before we can release
1.2.0.

I'll reply inline for the other issues.

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-28 Thread Noah Slater

On Tue, Feb 28, 2012 at 10:05 AM, Benoit Chesneau bchesn...@gmail.comwrote:

 Also noah, jan what is the status of this vote? Should we consider it
 as aborted or paused?


As far as I can tell, we have not identified, for sure, a release blocking
issue. Once we are sure that there is a release blocking issue, I will
abort the vote. But I am not aborting it simply because it's taking a while
to get clear on the issues. :)

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Bob Dionne

Jan,

Thanks for the clarification. I hope I'm not conflating things by continuing
the discussion here, I thought that's what you requested?

I just downloaded the release candidate again to start fresh. make distcheck
hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

Just stops completely. This is on R15B which has been rebuilt to use the
recommended older SSL version. I haven't looked into this crashing too closely
but I'm suspicious that I only see it with couchdb and never with bigcouch and
never using the 1.2.x branch from source or any branch for that matter

In the command line tests, 2,7, 27, and 32 fail. but it differs from run to run.

On Chrome attachment_ranges fails and it hangs on replicator_db

With respect to performance I think comparisons with 1.1.x are important. I
think almost any use case, contrived or otherwise should not be dismissed as a
pathological or edge case. Bob's script is as simple as it gets and to me is a
great smoke test. We need to figure out the reason 1.2 is clearly slower in
this case. If there are specific scenarios that 1.2.x is optimized for then we
should document that and provide reasons for the trade-offs

Cheers,

Bob

On Feb 26, 2012, at 4:07 PM, Jan Lehnardt wrote:

Bob,

thanks for your reply

I wasn't implying we should try to explain anything away. All of these are
valid concerns, I just wanted to get a better understanding on where the bit
flips from +0 to -1 and subsequently, how to address that boundary.

Ideally we can just fix all of the things you mention, but I think it is
important to understand them in detail, that's why I was going into them.
Ultimately, I want to understand what we need to do to ship 1.2.0.

On Feb 26, 2012, at 21:22 , Bob Dionne wrote:

Jan,

I'm -1 based on all of my evaluation. I've spent a few hours on this release
now yesterday and today. It doesn't really pass what I would call the smoke
test. Almost everything I've run into has an explanation:

1. crashes out of the box - that's R15B, you need to recompile SSL and
Erlang (we'll note on release notes)

Have we spent any time on figuring out what the trouble here is?

2. etaps hang running make check. Known issue. Our etap code is out of date,
recent versions of etap don't even run their own unit tests

I have seen the etap hang as well, and I wasn't diligent enough to report it
in JIRA, I have done so now (COUCHDB-1424).

3. Futon tests fail. Some are known bugs (attachment ranges in Chrome) .
Both Chrome and Safari also hang

Do you have more details on where Chrome and Safari hang? Can you try their
private browsing features, double/triple check that caches are empty? Can you
get to a situation where you get all tests succeeding across all browsers,
even if individual ones fail on one or two others?

4. standalone JS tests fail. Again most of these run when run by themselves

Which ones?

5. performance. I used real production data *because* Stefan on user
reported performance degradation on his data set. Any numbers are
meaningless for a single test. I also ran scripts that BobN and Jason Smith
posted that show a difference between 1.1.x and 1.2.x

You are conflating an IRC discussion we've had into this thread. The
performance regression reported is a good reason to look into other scenarios
where we can show slowdowns. But we need to understand what's happening. Just
from looking at dev@ all I see is some handwaving about some reports some
people have done (Not to discourage any work that has been done on IRC and
user@, but for the sake of a release vote thread, this related information
needs to be on this mailing list).

As I said on IRC, I'm happy to get my hands dirty to understand the
regression at hand. But we need to know where we'd draw a line and say this
isn't acceptable for a 1.2.0.

6. Reviewed patch pointed to by Jason that may be the cause but it's hard to
say without knowing the code analysis that went into the changes. You can
see obvious local optimizations that make good sense but those are often the
ones that get you, without knowing the call counts.

That is a point that wasn't included in your previous mail. It's great that
there is progress, thanks for looking into this!

Many of these issues can be explained away, but I think end users will be
less forgiving. I think we already struggle with view performance. I'm
interested to see how others evaluate this regression.
I'll try this seatoncouch tool you mention later to see if I can construct
some more definitive tests.

Again, I'm not trying to explain anything away. I want to get a shared
understanding of the issues you raised and where we stand on solving them
squared against the ongoing 1.2.0 release.

And again: Thanks for doing this thorough review and

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Robert Newson

I think it's worth reminding everyone that the Futon test suite is
only supported on FireFox. The reports of Chrome failing on
attachment_ranges illuminates nothing; it's a Chrome bug. It would be
news if it *didn't* fail on Chrome. :)

The performance regression, I think, is the only thing holding up the
release, can we focus on that? Particularly, narrowing down the
commits that are suspected and a discussion on the methodology used to
measure this so far (is it a fair test? etc). My take is that Bob has
measured a significant regression on a real world data set and that
Jan has seem an improvement on a different real world data set.

On 27 February 2012 11:58, Bob Dionne dio...@dionne-associates.com wrote:
Jan,

Thanks for the clarification. I hope I'm not conflating things by continuing
the discussion here, I thought that's what you requested?

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

In the command line tests, 2,7, 27, and 32 fail. but it differs from run to
run.

On Chrome attachment_ranges fails and it hangs on replicator_db

With respect to performance I think comparisons with 1.1.x are important. I
think almost any use case, contrived or otherwise should not be dismissed as
a pathological or edge case. Bob's script is as simple as it gets and to me
is a great smoke test. We need to figure out the reason 1.2 is clearly slower
in this case. If there are specific scenarios that 1.2.x is optimized for
then we should document that and provide reasons for the trade-offs

Cheers,

Bob

On Feb 26, 2012, at 4:07 PM, Jan Lehnardt wrote:

Bob,

thanks for your reply

On Feb 26, 2012, at 21:22 , Bob Dionne wrote:

Jan,

I'm -1 based on all of my evaluation. I've spent a few hours on this
release now yesterday and today. It doesn't really pass what I would call
the smoke test. Almost everything I've run into has an explanation:

1. crashes out of the box - that's R15B, you need to recompile SSL and
Erlang (we'll note on release notes)

Have we spent any time on figuring out what the trouble here is?

2. etaps hang running make check. Known issue. Our etap code is out of
date, recent versions of etap don't even run their own unit tests

I have seen the etap hang as well, and I wasn't diligent enough to report it
in JIRA, I have done so now (COUCHDB-1424).

3. Futon tests fail. Some are known bugs (attachment ranges in Chrome) .
Both Chrome and Safari also hang

Do you have more details on where Chrome and Safari hang? Can you try their
private browsing features, double/triple check that caches are empty? Can
you get to a situation where you get all tests succeeding across all
browsers, even if individual ones fail on one or two others?

4. standalone JS tests fail. Again most of these run when run by themselves

Which ones?

You are conflating an IRC discussion we've had into this thread. The
performance regression reported is a good reason to look into other
scenarios where we can show slowdowns. But we need to understand what's
happening. Just from looking at dev@ all I see is some handwaving about some
reports some people have done (Not to discourage any work that has been done
on IRC and user@, but for the sake of a release vote thread, this related
information needs to be on this mailing list).

As I said on IRC, I'm happy to get my hands dirty to understand the
regression at hand. But we need to know where we'd draw a line and say this
isn't acceptable for a 1.2.0.

6. Reviewed patch pointed to by Jason that may be the cause but it's hard
to say without knowing the code analysis that went into the changes. You
can see obvious local optimizations that make good sense but those are
often the ones that get you, without

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

Thanks for the clarification. I hope I'm not conflating things by continuing
the discussion here, I thought that's what you requested?

The discussion we had on IRC was regarding collecting more data items for the
performance regression before we start to draw conclusions.

My intention here is to understand what needs doing before we can release 1.2.0.

I'll reply inline for the other issues.

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

From the release you should run `make check`, not make distcheck. But I assume
you see a hang there too, as I have and others (yet not everybody), too. I
can't comment on BigCouch and what is different there. It is interesting that
1.2.x won't hang. For me, `make check` in 1.2.x on R15B hangs sometimes, in
different places. I'm currently trying to gather more information about this.

The question here is whether `make check` passing in R15B is a release
requirement. In my vote I considered no, but I am happy to go with a community
decision if it emerges. What is your take here?

In addition, this just shouldn't be a question, so we should investigate why
this happens at all and address the issue, hence COUCHDB-1424. Any insight here
would be appreciated as well.

In the command line tests, 2,7, 27, and 32 fail. but it differs from run to
run.

I assume you mean the JS tests. Again, this isn't supposed to work in 1.2.x.
I'm happy to backport my changes from master to 1.2.x to make that work, but I
refrained from that because I didn't want to bring too much change to a release
branch. I'm happy to reconsider, but I don't think a release vote is a good
place to discuss feature backports.

On Chrome attachment_ranges fails and it hangs on replicator_db

This one is an explaining away, but I think it is warranted. Chrome is broken
for attachment_ranges. I don't know if we reported this upstream (Robert N?),
but this isn't a release blocker. For the replicator_db test, can you try
running that in other browsers. I understand it is not the best of situation
(hence the move to the cli test suite for master), but if you get this test to
pass in at least one other browsers, this isn't a problem that holds 1.2.x.

With respect to performance I think comparisons with 1.1.x are important. I
think almost any use case, contrived or otherwise should not be dismissed as
a pathological or edge case. Bob's script is as simple as it gets and to me
is a great smoke test. We need to figure out the reason 1.2 is clearly slower
in this case. If there are specific scenarios that 1.2.x is optimized for
then we should document that and provide reasons for the trade-offs

I want to make absolutely clear that I take any report of performance
regression very seriously. But I'm rather annoyed that no information about
this ends up on dev@. I understand that on IRC there's some shared
understanding of a few scenarios where performance regressions can be shown. I
asked three times now that these be posted to this mailing list. I'm not asking
for a comprehensive report, but anything really. I found Robert Newson's simple
test script on IRC and ran that to test a suspicion of mine which I posted in
an earlier mail (tiny docs - slower, bigger docs - faster). Nobody else
bothered to post this here. I see no discussion about what is observed, what is
expected, what would be acceptable for a release of 1.2.0 as is and what not.

As far as this list is concerned, we know that a few people claimed that things
are slower and it's very real and that we should hold the 1.2.0 release for it.
I'm more than happy to hold the release until we figured out the things I asked
for above and help out figuring it all out. But we need something to work with
here.

I also understand that this is a voluntary project and people don't have
infinite time to spend, but at least a message of we're collecting things,
will report when done, would be *great* to start. So far we only have a hold
the horses, there might be a something going on.

Please let me know if this request is unreasonable or whether I am overreacting.

Sorry for the rant.

To anyone who has been looking into performance regression, can you please send
to this list any info you have? If you have a comprehensive analysis, awesome,
if you just ran some script on a machine, just send us that, let's collect all
the data to get this situation solved! We need your help.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Robert Newson

Bob D, can you give more details on the data set you're testing?
Number of docs, size/complexity of docs, etc? Basically, enough info
that I could write a script to automate building an equivalent
database.

I wrote a quick bash script to make a database and time a view build
here: http://friendpaste.com/7kBiKJn3uX1KiGJAFPv4nK

On 27 February 2012 13:15, Jan Lehnardt j...@apache.org wrote:

On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

Thanks for the clarification. I hope I'm not conflating things by continuing
the discussion here, I thought that's what you requested?

The discussion we had on IRC was regarding collecting more data items for the
performance regression before we start to draw conclusions.

My intention here is to understand what needs doing before we can release
1.2.0.

I'll reply inline for the other issues.

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

The question here is whether `make check` passing in R15B is a release
requirement. In my vote I considered no, but I am happy to go with a
community decision if it emerges. What is your take here?

In addition, this just shouldn't be a question, so we should investigate why
this happens at all and address the issue, hence COUCHDB-1424. Any insight
here would be appreciated as well.

In the command line tests, 2,7, 27, and 32 fail. but it differs from run to
run.

On Chrome attachment_ranges fails and it hangs on replicator_db

I want to make absolutely clear that I take any report of performance
regression very seriously. But I'm rather annoyed that no information about
this ends up on dev@. I understand that on IRC there's some shared
understanding of a few scenarios where performance regressions can be shown.
I asked three times now that these be posted to this mailing list. I'm not
asking for a comprehensive report, but anything really. I found Robert
Newson's simple test script on IRC and ran that to test a suspicion of mine
which I posted in an earlier mail (tiny docs - slower, bigger docs -
faster). Nobody else bothered to post this here. I see no discussion about
what is observed, what is expected, what would be acceptable for a release of
1.2.0 as is and what not.

As far as this list is concerned, we know that a few people claimed that
things are slower and it's very real and that we should hold the 1.2.0
release for it. I'm more than happy to hold the release until we figured out
the things I asked for above and help out figuring it all out. But we need
something to work with here.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Filipe David Manana

I just tried Jason's script (modified it to use 500 000 docs instead
of 50 000) against 1.2.x and 1.1.1, using OTP R14B03. Here's my
results:

1.2.x:

$ port=5984 ./test.sh
none
Filling db.
done
HTTP/1.1 200 OK
Server: CouchDB/1.2.0 (Erlang OTP/R14B03)
Date: Mon, 27 Feb 2012 16:08:43 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 252
Cache-Control: must-revalidate

{db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:130494577,data_size:130490673,instance_start_time:1330358830830086,disk_format_version:6,committed_update_seq:51}
Building view.

real1m5.725s
user0m0.006s
sys 0m0.005s
done


1.1.1:

$ port=5984 ./test.sh

Filling db.
done
HTTP/1.1 200 OK
Server: CouchDB/1.1.2a785d32f-git (Erlang OTP/R14B03)
Date: Mon, 27 Feb 2012 16:15:33 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 230
Cache-Control: must-revalidate

{db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:122142818,instance_start_time:1330359233327316,disk_format_version:5,committed_update_seq:51}
Building view.

real1m4.249s
user0m0.006s
sys 0m0.005s
done


I don't see any significant difference there.

Regarding COUCHDB-1186, the only thing that might cause some non
determinism and affect performance is the queing/dequeing. Depending
on timings, it's possible the writer is dequeing less items per
dequeue operation and therefore inserting smaller batches into the
btree. The following small change ensures larger batches (while still
respecting the queue max size/item count):

http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

Running the test with this change:

$ port=5984 ./test.sh
none
Filling db.
done
HTTP/1.1 200 OK
Server: CouchDB/1.2.0 (Erlang OTP/R14B03)
Date: Mon, 27 Feb 2012 16:23:20 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 252
Cache-Control: must-revalidate

{db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:130494577,data_size:130490673,instance_start_time:1330359706846104,disk_format_version:6,committed_update_seq:51}
Building view.

real0m49.762s
user0m0.006s
sys 0m0.005s
done


If there's no objection, I'll push that patch.

Also, another note, I noticed sometime ago that with master, using OTP
R15B I got a performance drop of 10% to 15% compared to using master
with OTP R14B04. Maybe it applies to 1.2.x as well.


On Mon, Feb 27, 2012 at 5:33 AM, Robert Newson rnew...@apache.org wrote:
 Bob D, can you give more details on the data set you're testing?
 Number of docs, size/complexity of docs, etc? Basically, enough info
 that I could write a script to automate building an equivalent
 database.

 I wrote a quick bash script to make a database and time a view build
 here: http://friendpaste.com/7kBiKJn3uX1KiGJAFPv4nK

 B.

 On 27 February 2012 13:15, Jan Lehnardt j...@apache.org wrote:

 On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

 Thanks for the clarification. I hope I'm not conflating things by 
 continuing the discussion here, I thought that's what you requested?

 The discussion we had on IRC was regarding collecting more data items for 
 the performance regression before we start to draw conclusions.

 My intention here is to understand what needs doing before we can release 
 1.2.0.

 I'll reply inline for the other issues.

 I just downloaded the release candidate again to start fresh. make 
 distcheck hangs on this step:

 /Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
  . 6/?

 Just stops completely. This is on R15B which has been rebuilt to use the 
 recommended older SSL version. I haven't looked into this crashing too 
 closely but I'm suspicious that I only see it with couchdb and never with 
 bigcouch and never using the 1.2.x branch from source or any branch for 
 that matter

 From the release you should run `make check`, not make distcheck. But I 
 assume you see a hang there too, as I have and others (yet not everybody), 
 too. I can't comment on BigCouch and what is different there. It is 
 interesting that 1.2.x won't hang. For me, `make check` in 1.2.x on R15B 
 hangs sometimes, in different places. I'm currently trying to gather more 
 information about this.

 The question here is whether `make check` passing in R15B is a release 
 requirement. In my vote I considered no, but I am happy to go with a 
 community decision if it emerges. What is your take here?

 In addition, this just shouldn't be a question, so we should investigate why 
 this happens at all and address the issue, hence COUCHDB-1424. Any insight 
 here would be appreciated as well.


 In the command line tests, 2,7, 27, and 32 fail. but it differs from run to 
 run.

 I assume you mean the JS tests. Again, this isn't supposed to work in 1.2.x. 
 I'm happy to backport my changes from master to 1.2.x to make that

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Noah Slater

On Mon, Feb 27, 2012 at 1:15 PM, Jan Lehnardt j...@apache.org wrote:

 It is interesting that 1.2.x won't hang.


There is no difference between the files you have on your branch, and the
files in the release tarball.

You can verify this yourself by following the steps here:

http://wiki.apache.org/couchdb/Test_procedure

How may times have you tested this?

If you run make check on the branch 5 times, how many fail?

If you run make check from the tarball 5 times, how many file?

The question here is whether `make check` passing in R15B is a release
 requirement. In my vote I considered no, but I am happy to go with a
 community decision if it emerges. What is your take here?


Yes, this is a release blocker.


 In addition, this just shouldn't be a question, so we should investigate
 why this happens at all and address the issue, hence COUCHDB-1424. Any
 insight here would be appreciated as well.


Agreed.



  In the command line tests, 2,7, 27, and 32 fail. but it differs from run
 to run.

 I assume you mean the JS tests. Again, this isn't supposed to work in
 1.2.x. I'm happy to backport my changes from master to 1.2.x to make that
 work, but I refrained from that because I didn't want to bring too much
 change to a release branch. I'm happy to reconsider, but I don't think a
 release vote is a good place to discuss feature backports.


Jan, I am starting to think of our release vote rounds as release
candidates. In so much as, the activity they seem to kick-off seems to be
the sort of activity you hope to kick off with a regular release candidate.
Does that make sense? Within that context, I think it's fine to talk about
stuff like this. A release voting round is a prompt for people to get their
shit together.


  On Chrome attachment_ranges fails and it hangs on replicator_db

 This one is an explaining away, but I think it is warranted. Chrome is
 broken for attachment_ranges. I don't know if we reported this upstream
 (Robert N?), but this isn't a release blocker. For the replicator_db test,
 can you try running that in other browsers. I understand it is not the best
 of situation (hence the move to the cli test suite for master), but if you
 get this test to pass in at least one other browsers, this isn't a problem
 that holds 1.2.x.


We only support Firefox with the test suite. What am I missing?

Re: [VOTE] Apache CouchDB 1.2.0 release, second round


On Feb 27, 2012, at 18:19 , Noah Slater wrote:

 On Mon, Feb 27, 2012 at 1:15 PM, Jan Lehnardt j...@apache.org wrote:
 
 It is interesting that 1.2.x won't hang.
 
 
 There is no difference between the files you have on your branch, and the
 files in the release tarball.

For me both hang.


 You can verify this yourself by following the steps here:
 
 http://wiki.apache.org/couchdb/Test_procedure
 
 How may times have you tested this?
 
 If you run make check on the branch 5 times, how many fail?
 
 If you run make check from the tarball 5 times, how many file?

They all fail. Only occasionally it doesn't. I can't give it a number,
but maybe it is 1 in 10 runs.


 The question here is whether `make check` passing in R15B is a release
 requirement. In my vote I considered no, but I am happy to go with a
 community decision if it emerges. What is your take here?
 
 
 Yes, this is a release blocker.

See https://issues.apache.org/jira/browse/COUCHDB-1424 for details on
this. So far we haven't been able to show that this happens on systems
other than Mac OS X 10.7.3. If true, I wouldn't consider this a release
blocker.


 In the command line tests, 2,7, 27, and 32 fail. but it differs from run
 to run.
 
 I assume you mean the JS tests. Again, this isn't supposed to work in
 1.2.x. I'm happy to backport my changes from master to 1.2.x to make that
 work, but I refrained from that because I didn't want to bring too much
 change to a release branch. I'm happy to reconsider, but I don't think a
 release vote is a good place to discuss feature backports.
 
 
 Jan, I am starting to think of our release vote rounds as release
 candidates. In so much as, the activity they seem to kick-off seems to be
 the sort of activity you hope to kick off with a regular release candidate.
 Does that make sense? Within that context, I think it's fine to talk about
 stuff like this. A release voting round is a prompt for people to get their
 shit together.

That's a fair point of view, but I'm looking at this differently. A release
branch should be in good shape most of the time and signing off on a release
by a vote should be a formality, not start discussions what the scope of the
release is.

I'm actually thinking about introducing proper RC release to bridge the
attention / release gap, but that's a separate discussion.


 On Chrome attachment_ranges fails and it hangs on replicator_db
 
 This one is an explaining away, but I think it is warranted. Chrome is
 broken for attachment_ranges. I don't know if we reported this upstream
 (Robert N?), but this isn't a release blocker. For the replicator_db test,
 can you try running that in other browsers. I understand it is not the best
 of situation (hence the move to the cli test suite for master), but if you
 get this test to pass in at least one other browsers, this isn't a problem
 that holds 1.2.x.
 
 
 We only support Firefox with the test suite. What am I missing?

Many people don't use Firefox :)

Cheers
Jan
--

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Noah Slater

On Mon, Feb 27, 2012 at 5:41 PM, Jan Lehnardt j...@apache.org wrote:

 See https://issues.apache.org/jira/browse/COUCHDB-1424 for details on
 this. So far we haven't been able to show that this happens on systems
 other than Mac OS X 10.7.3. If true, I wouldn't consider this a release
 blocker.


This doesn't happen for me, or I would not have called the vote, and I am
using that exact platform.


 That's a fair point of view, but I'm looking at this differently. A release
 branch should be in good shape most of the time and signing off on a
 release
 by a vote should be a formality, not start discussions what the scope of
 the
 release is.

 I'm actually thinking about introducing proper RC release to bridge the
 attention / release gap, but that's a separate discussion.


Tabled.

Many people don't use Firefox :)


http://wiki.apache.org/couchdb/Test_procedure

Please note that the unit tests do not run properly under Safari.

If you report problems with Safari, you will be asked to test again using
Firefox.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round


On Feb 27, 2012, at 19:11 , Noah Slater wrote:

 On Mon, Feb 27, 2012 at 5:41 PM, Jan Lehnardt j...@apache.org wrote:
 
 See https://issues.apache.org/jira/browse/COUCHDB-1424 for details on
 this. So far we haven't been able to show that this happens on systems
 other than Mac OS X 10.7.3. If true, I wouldn't consider this a release
 blocker.
 
 
 This doesn't happen for me, or I would not have called the vote, and I am
 using that exact platform.

Yeah, sorry, I should have been more clear, it only happens for some Mac
users.

 Many people don't use Firefox :)
 
 http://wiki.apache.org/couchdb/Test_procedure
 
 Please note that the unit tests do not run properly under Safari.
 
 If you report problems with Safari, you will be asked to test again using
 Firefox.

I don't know why Bob D isn't testing in Firefox.

Cheers
Jan
--

Re: [VOTE] Apache CouchDB 1.2.0 release, second round


On Feb 23, 2012, at 18:09 , Jan Lehnardt wrote:

 I'm happy to give this a +1 if we put a warning about R15B on the download 
 page.

http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=b1af764b refers
to an issue that makes operation under R15B potentially dangerous. We haven't
seen a report about any issues, but the Erlang manual quote severe potential
issues:

 These changes are essential to not crash the emulator or worse cause 
 malfunction. Without them a driver may return garbage in the high 32 bits to 
 the emulator causing it to build a huge result from random bytes either 
 crashing on memory allocation or succeeding with a random result from the 
 driver call.

and

 The argument type change is from signed to unsigned which may cause problems 
 for e.g. loop termination conditions or error conditions if you just change 
 the types all over the place.

   — http://www.erlang.org/doc/man/erl_driver.html#rewrites_for_64_bits


The fix is simple enough (see the link above), but this makes me not feel
comfortable recommending this release for operation on R15B.

I'd be fine with releasing 1.2.0 as is* and make it clear in the release
notes that R15B support isn't there yet and ship a 1.2.1 soonish with the
fix.

* but if we are holding 1.2.0 for any of the other issues we are discussing,
I'd say we include this one.

What do you think?

Cheers
Jan
--

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Robert Newson

If the R15/64 bit fix is the only issue with round 2, then I vote with
Jan to defer it to 1.2.1. If we're opening up round 3 for any reason,
I'd like to see it go in.

b.

On 27 February 2012 19:09, Jan Lehnardt j...@apache.org wrote:

 On Feb 23, 2012, at 18:09 , Jan Lehnardt wrote:

 I'm happy to give this a +1 if we put a warning about R15B on the download 
 page.

 http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=b1af764b 
 refers
 to an issue that makes operation under R15B potentially dangerous. We haven't
 seen a report about any issues, but the Erlang manual quote severe potential
 issues:

 These changes are essential to not crash the emulator or worse cause 
 malfunction. Without them a driver may return garbage in the high 32 bits to 
 the emulator causing it to build a huge result from random bytes either 
 crashing on memory allocation or succeeding with a random result from the 
 driver call.

 and

 The argument type change is from signed to unsigned which may cause problems 
 for e.g. loop termination conditions or error conditions if you just change 
 the types all over the place.

   — http://www.erlang.org/doc/man/erl_driver.html#rewrites_for_64_bits


 The fix is simple enough (see the link above), but this makes me not feel
 comfortable recommending this release for operation on R15B.

 I'd be fine with releasing 1.2.0 as is* and make it clear in the release
 notes that R15B support isn't there yet and ship a 1.2.1 soonish with the
 fix.

 * but if we are holding 1.2.0 for any of the other issues we are discussing,
 I'd say we include this one.

 What do you think?

 Cheers
 Jan
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Noah Slater

If the fix is simple enough, I would prefer to see it in. The effects sound
moderately serious, and this effects the most recent Erlang, not some
legacy shit.

On Mon, Feb 27, 2012 at 8:18 PM, Robert Newson rnew...@apache.org wrote:

 If the R15/64 bit fix is the only issue with round 2, then I vote with
 Jan to defer it to 1.2.1. If we're opening up round 3 for any reason,
 I'd like to see it go in.

 b.

 On 27 February 2012 19:09, Jan Lehnardt j...@apache.org wrote:
 
  On Feb 23, 2012, at 18:09 , Jan Lehnardt wrote:
 
  I'm happy to give this a +1 if we put a warning about R15B on the
 download page.
 
  http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=b1af764brefers
  to an issue that makes operation under R15B potentially dangerous. We
 haven't
  seen a report about any issues, but the Erlang manual quote severe
 potential
  issues:
 
  These changes are essential to not crash the emulator or worse cause
 malfunction. Without them a driver may return garbage in the high 32 bits
 to the emulator causing it to build a huge result from random bytes either
 crashing on memory allocation or succeeding with a random result from the
 driver call.
 
  and
 
  The argument type change is from signed to unsigned which may cause
 problems for e.g. loop termination conditions or error conditions if you
 just change the types all over the place.
 
— http://www.erlang.org/doc/man/erl_driver.html#rewrites_for_64_bits
 
 
  The fix is simple enough (see the link above), but this makes me not feel
  comfortable recommending this release for operation on R15B.
 
  I'd be fine with releasing 1.2.0 as is* and make it clear in the release
  notes that R15B support isn't there yet and ship a 1.2.1 soonish with the
  fix.
 
  * but if we are holding 1.2.0 for any of the other issues we are
 discussing,
  I'd say we include this one.
 
  What do you think?
 
  Cheers
  Jan
  --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Jason Smith

Hi, Filipe. Most people seem to be holding their OTP build constant
for these tests.

If you have the time, would you please check out
https://github.com/jhs/slow_couchdb

It uses seatoncouch mixed with Bob's script to run a basic benchmark.
I expect more template types to grow to help create different data
profiles.

Anyway, here are my results with 500k documents. Note that I built
from your optimization commit, then its parent.

https://gist.github.com/1928169

tl;dr = 2:50 before your commit; 4:13 after.

On Mon, Feb 27, 2012 at 11:33 PM, Filipe David Manana
fdman...@apache.org wrote:
I just tried Jason's script (modified it to use 500 000 docs instead
of 50 000) against 1.2.x and 1.1.1, using OTP R14B03. Here's my
results:

1.2.x:

real 1m5.725s
user 0m0.006s
sys 0m0.005s
done

1.1.1:

$ port=5984 ./test.sh

real 1m4.249s
user 0m0.006s
sys 0m0.005s
done

I don't see any significant difference there.

http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

Running the test with this change:

{db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:130494577,data_size:130490673,instance_start_time:1330359706846104,disk_format_version:6,committed_update_seq:51}
Building view.

real 0m49.762s
user 0m0.006s
sys 0m0.005s
done

If there's no objection, I'll push that patch.

Also, another note, I noticed sometime ago that with master, using OTP
R15B I got a performance drop of 10% to 15% compared to using master
with OTP R14B04. Maybe it applies to 1.2.x as well.

I wrote a quick bash script to make a database and time a view build
here: http://friendpaste.com/7kBiKJn3uX1KiGJAFPv4nK

On 27 February 2012 13:15, Jan Lehnardt j...@apache.org wrote:

On Feb 27, 2012, at 12:58 , Bob Dionne wrote:

Thanks for the clarification. I hope I'm not conflating things by
continuing the discussion here, I thought that's what you requested?

The discussion we had on IRC was regarding collecting more data items for
the performance regression before we start to draw conclusions.

My intention here is to understand what needs doing before we can release
1.2.0.

I'll reply inline for the other issues.

I just downloaded the release candidate again to start fresh. make
distcheck hangs on this step:

/Users/bitdiddle/Downloads/apache-couchdb-1.2.0/apache-couchdb-1.2.0/_build/../test/etap/150-invalid-view-seq.t
. 6/?

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Filipe David Manana

Jason, can't reproduce those results, not even close:

http://friendpaste.com/1L4pHH8WQchaLIMCWhKX9Z

Before COUCHDB-1186

fdmanana 16:58:02 ~/git/hub/slow_couchdb (master) docs=50
batch=5 ./bench.sh small_doc.tpl
Server: CouchDB/1.2.0a-a68a792-git (Erlang OTP/R14B03)
{couchdb:Welcome,version:1.2.0a-a68a792-git}

[INFO] Created DB named `db1'
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
Building view.
{total_rows:50,offset:0,rows:[
{id:doc1,key:1,value:1}
]}

real0m56.241s
user0m0.006s
sys 0m0.005s


After COUCHDB-1186

fdmanana 17:02:02 ~/git/hub/slow_couchdb (master) docs=50
batch=5 ./bench.sh small_doc.tpl
Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R14B03)
{couchdb:Welcome,version:1.2.0a-f023052-git}

[INFO] Created DB named `db1'
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
Building view.
{total_rows:50,offset:0,rows:[
{id:doc1,key:1,value:1}
]}

real1m11.694s
user0m0.006s
sys 0m0.005s
fdmanana 17:06:01 ~/git/hub/slow_couchdb (master)


1.2.0a-f023052-git with patch
http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w  applied on top

fdmanana 17:06:53 ~/git/hub/slow_couchdb (master) docs=50
batch=5 ./bench.sh small_doc.tpl
Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R14B03)
{couchdb:Welcome,version:1.2.0a-f023052-git}

[INFO] Created DB named `db1'
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
[INFO] Uploaded 5 documents via _bulk_docs
Building view.
{total_rows:50,offset:0,rows:[
{id:doc1,key:1,value:1}
]}

real0m51.089s
user0m0.006s
sys 0m0.004s
fdmanana 17:10:29 ~/git/hub/slow_couchdb (master)


Can you try with R14B0x and also with the patch
http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w ?

Back then I made all testing on a machine with a spinning disk, so the
writer process was slower and likely dequeing more KV pairs from the
work queue on each dequeue operation. The tests I did just now are on
a machine with a ssd disk.


On Mon, Feb 27, 2012 at 4:40 PM, Jason Smith j...@apache.org wrote:
 Hi, Filipe. Most people seem to be holding their OTP build constant
 for these tests.

 If you have the time, would you please check out
 https://github.com/jhs/slow_couchdb

 It uses seatoncouch mixed with Bob's script to run a basic benchmark.
 I expect more template types to grow to help create different data
 profiles.

 Anyway, here are my results with 500k documents. Note that I built
 from your optimization commit, then its parent.

 https://gist.github.com/1928169

 tl;dr = 2:50 before your commit; 4:13 after.

 On Mon, Feb 27, 2012 at 11:33 PM, Filipe David Manana
 fdman...@apache.org wrote:
 I just tried Jason's script (modified it to use 500 000 docs instead
 of 50 000) against 1.2.x and 1.1.1, using OTP R14B03. Here's my
 results:

 1.2.x:

 $ port=5984 ./test.sh
 none
 Filling db.
 done
 HTTP/1.1 200 OK
 Server: CouchDB/1.2.0 (Erlang OTP/R14B03)
 Date: Mon, 27 Feb 2012 16:08:43 GMT
 Content-Type: text/plain; charset=utf-8
 Content-Length: 252
 Cache-Control: must-revalidate

 {db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:130494577,data_size:130490673,instance_start_time:1330358830830086,disk_format_version:6,committed_update_seq:51}
 Building view.

 real    1m5.725s
 user    0m0.006s
 sys     0m0.005s
 done


 1.1.1:

 $ port=5984 ./test.sh
 
 Filling db.
 done
 HTTP/1.1 200 OK
 Server: CouchDB/1.1.2a785d32f-git (Erlang OTP/R14B03)
 Date: Mon, 27 Feb 2012 16:15:33 GMT
 Content-Type: text/plain;charset=utf-8
 Content-Length: 230
 Cache-Control: must-revalidate

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-27 Thread Paul Davis

On Mon, Feb 27, 2012 at 7:18 PM, Filipe David Manana
fdman...@apache.org wrote:
 Jason, can't reproduce those results, not even close:

 http://friendpaste.com/1L4pHH8WQchaLIMCWhKX9Z

 Before COUCHDB-1186

 fdmanana 16:58:02 ~/git/hub/slow_couchdb (master) docs=50
 batch=5 ./bench.sh small_doc.tpl
 Server: CouchDB/1.2.0a-a68a792-git (Erlang OTP/R14B03)
 {couchdb:Welcome,version:1.2.0a-a68a792-git}

 [INFO] Created DB named `db1'
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 Building view.
 {total_rows:50,offset:0,rows:[
 {id:doc1,key:1,value:1}
 ]}

 real    0m56.241s
 user    0m0.006s
 sys     0m0.005s


 After COUCHDB-1186

 fdmanana 17:02:02 ~/git/hub/slow_couchdb (master) docs=50
 batch=5 ./bench.sh small_doc.tpl
 Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R14B03)
 {couchdb:Welcome,version:1.2.0a-f023052-git}

 [INFO] Created DB named `db1'
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 Building view.
 {total_rows:50,offset:0,rows:[
 {id:doc1,key:1,value:1}
 ]}

 real    1m11.694s
 user    0m0.006s
 sys     0m0.005s
 fdmanana 17:06:01 ~/git/hub/slow_couchdb (master)


 1.2.0a-f023052-git with patch
 http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w  applied on top

 fdmanana 17:06:53 ~/git/hub/slow_couchdb (master) docs=50
 batch=5 ./bench.sh small_doc.tpl
 Server: CouchDB/1.2.0a-f023052-git (Erlang OTP/R14B03)
 {couchdb:Welcome,version:1.2.0a-f023052-git}

 [INFO] Created DB named `db1'
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 [INFO] Uploaded 5 documents via _bulk_docs
 Building view.
 {total_rows:50,offset:0,rows:[
 {id:doc1,key:1,value:1}
 ]}

 real    0m51.089s
 user    0m0.006s
 sys     0m0.004s
 fdmanana 17:10:29 ~/git/hub/slow_couchdb (master)


 Can you try with R14B0x and also with the patch
 http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w ?

 Back then I made all testing on a machine with a spinning disk, so the
 writer process was slower and likely dequeing more KV pairs from the
 work queue on each dequeue operation. The tests I did just now are on
 a machine with a ssd disk.


Yeah, I've seen the btree behave quite differently on SSD's vs HDD's
(same code had drastically different runtime characteristics).

In other words, can we get a report of what type of disk everyone is running on?


 On Mon, Feb 27, 2012 at 4:40 PM, Jason Smith j...@apache.org wrote:
 Hi, Filipe. Most people seem to be holding their OTP build constant
 for these tests.

 If you have the time, would you please check out
 https://github.com/jhs/slow_couchdb

 It uses seatoncouch mixed with Bob's script to run a basic benchmark.
 I expect more template types to grow to help create different data
 profiles.

 Anyway, here are my results with 500k documents. Note that I built
 from your optimization commit, then its parent.

 https://gist.github.com/1928169

 tl;dr = 2:50 before your commit; 4:13 after.

 On Mon, Feb 27, 2012 at 11:33 PM, Filipe David Manana
 fdman...@apache.org wrote:
 I just tried Jason's script (modified it to use 500 000 docs instead
 of 50 000) against 1.2.x and 1.1.1, using OTP R14B03. Here's my
 results:

 1.2.x:

 $ port=5984 ./test.sh
 none
 Filling db.
 done
 HTTP/1.1 200 OK
 Server: CouchDB/1.2.0 (Erlang OTP/R14B03)
 Date: Mon, 27 Feb 2012 16:08:43 GMT
 Content-Type: text/plain; charset=utf-8
 Content-Length: 252
 Cache-Control: must-revalidate

 {db_name:db1,doc_count:51,doc_del_count:0,update_seq:51,purge_seq:0,compact_running:false,disk_size:130494577,data_size:130490673,instance_start_time:1330358830830086,disk_format_version:6,committed_update_seq:51}
 Building view.

 real    1m5.725s
 user    0m0.006s
 sys     0m0.005s
 done


 1.1.1:

 $ port=5984 ./test.sh
 
 Filling db.
 done
 HTTP/1.1 200 OK

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-26 Thread Bob Dionne

-1

R15B on OS X Lion

I rebuilt OTP with an older SSL and that gets past all the crashes (thanks 
Filipe). I still see hangs when running make check, though any particular etap 
that hangs will run ok by itself. The Futon tests never run to completion in 
Chrome without hanging and the standalone JS tests also have fails.

I tested the performance of view indexing, using a modest 200K doc db with a 
large complex view and there's a clear regression between 1.1.x and 1.2.x 
Others report similar results
 
On Feb 23, 2012, at 5:25 PM, Bob Dionne 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 j...@apache.org 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
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-26 Thread Jan Lehnardt


On Feb 26, 2012, at 13:43 , Robert Newson wrote:

 We're investigating a view indexing performance regression right now.
 I think it's still valuable to get community responses on whether the
 build artifact passes all the tests, though. If folks also want to try
 out building larger views, especially if they can compare the build
 time to CouchDB 1.1.1 that would be awesome.

I ran Robert's test with a tiny doc and minimal view and saw the 25%
performance drop, but using more realistic doc sizes and views show
and improvement for 1.2.x (in one case 1k docs with a view that emits
a complex key and an integer for the value).

Filipe's https://github.com/fdmanana/seatoncouch makes it really easy
to populate different sized docs and databases. If anyone could hack
up a version of Robert's script combined with seatoncouch to make
different sizes for documents, we can find out what to expect in
performance differences.

I'd say if we find one pathological case to be worse but prove across
the board, things are faster, that this isn't a blocker.

Cheers
Jan
-- 




 
 B.
 
 On 24 February 2012 15:40, Benoit Chesneau bchesn...@gmail.com wrote:
 On Fri, Feb 24, 2012 at 4:39 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Feb 23, 2012 at 12:28 AM, Noah Slater nsla...@tumbolia.org 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,
 
 N
 
 +1 make check , js tests  signatures ok
 
 erlang R14B04 - osx lion  snow leopard, ubuntu 11.04, 11.10, debian 6, 
 fbsd 8.2
 
 - benoît
 
 q note: i had to buy my openssl to have it working with it on osx
 lion. Also I used spidermonkey 1.8.5.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-26 Thread Jan Lehnardt


On Feb 26, 2012, at 13:58 , Bob Dionne wrote:

 -1
 
 R15B on OS X Lion
 
 I rebuilt OTP with an older SSL and that gets past all the crashes (thanks 
 Filipe). I still see hangs when running make check, though any particular 
 etap that hangs will run ok by itself. The Futon tests never run to 
 completion in Chrome without hanging and the standalone JS tests also have 
 fails.

What part of this do you consider the -1? Can you try running the JS tests in 
Firefox and or Safari? Can you get all tests pass at least once across all 
browsers? The cli JS suite isn't supposed to work, so that isn't a criterion. 
I've seen the hang in make check for R15B while individual tests run as well, 
but I don't consider this blocking. While I understand and support the notion 
that tests shouldn't fail, period, we gotta work with what we have and master 
already has significant improvements. What would you like to see changed to not 
-1 this release?

 I tested the performance of view indexing, using a modest 200K doc db with a 
 large complex view and there's a clear regression between 1.1.x and 1.2.x 
 Others report similar results

What is a large complex view? The complexity of the map/reduce functions is 
rarely an indicator of performance, it's usually input doc size and 
output/emit()/reduce data size. How big are the docs in your test and how big 
is the returned data? I understand the changes for 1.2.x will improve 
larger-data scenarios more significantly.

Cheers
Jan
-- 




 
 On Feb 23, 2012, at 5:25 PM, Bob Dionne 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 j...@apache.org 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
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-26 Thread Bob Dionne

Jan,

I'm -1 based on all of my evaluation. I've spent a few hours on this release 
now yesterday and today. It doesn't really pass what I would call the smoke 
test. Almost everything I've run into has an explanation:

1. crashes out of the box - that's R15B, you need to recompile SSL and Erlang 
(we'll note on release notes)

2. etaps hang running make check. Known issue. Our etap code is out of date, 
recent versions of etap don't even run their own unit tests

3. Futon tests fail. Some are known bugs (attachment ranges in Chrome) . Both 
Chrome and Safari also hang

4. standalone JS tests fail. Again most of these run when run by themselves

5. performance. I used real production data *because* Stefan on user reported 
performance degradation on his data set. Any numbers are meaningless for a 
single test. I also ran scripts that BobN and Jason Smith posted that show a 
difference between 1.1.x and 1.2.x

6. Reviewed patch pointed to by Jason that may be the cause but it's hard to 
say without knowing the code analysis that went into the changes. You can see 
obvious local optimizations that make good sense but those are often the ones 
that get you, without knowing the call counts.

Many of these issues can be explained away, but I think end users will be less 
forgiving. I think we already struggle with view performance. I'm interested to 
see how others evaluate this regression.
I'll try this seatoncouch tool you mention later to see if I can construct some 
more definitive tests.

Best,

Bob
On Feb 26, 2012, at 2:29 PM, Jan Lehnardt wrote:

 
 On Feb 26, 2012, at 13:58 , Bob Dionne wrote:
 
 -1
 
 R15B on OS X Lion
 
 I rebuilt OTP with an older SSL and that gets past all the crashes (thanks 
 Filipe). I still see hangs when running make check, though any particular 
 etap that hangs will run ok by itself. The Futon tests never run to 
 completion in Chrome without hanging and the standalone JS tests also have 
 fails.
 
 What part of this do you consider the -1? Can you try running the JS tests in 
 Firefox and or Safari? Can you get all tests pass at least once across all 
 browsers? The cli JS suite isn't supposed to work, so that isn't a criterion. 
 I've seen the hang in make check for R15B while individual tests run as well, 
 but I don't consider this blocking. While I understand and support the notion 
 that tests shouldn't fail, period, we gotta work with what we have and master 
 already has significant improvements. What would you like to see changed to 
 not -1 this release?
 
 I tested the performance of view indexing, using a modest 200K doc db with a 
 large complex view and there's a clear regression between 1.1.x and 1.2.x 
 Others report similar results
 
 What is a large complex view? The complexity of the map/reduce functions is 
 rarely an indicator of performance, it's usually input doc size and 
 output/emit()/reduce data size. How big are the docs in your test and how big 
 is the returned data? I understand the changes for 1.2.x will improve 
 larger-data scenarios more significantly.
 
 Cheers
 Jan
 -- 
 
 
 
 
 
 On Feb 23, 2012, at 5:25 PM, Bob Dionne 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 j...@apache.org 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,

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-26 Thread Jan Lehnardt

Bob,

thanks for your reply

I wasn't implying we should try to explain anything away. All of these are 
valid concerns, I just wanted to get a better understanding on where the bit 
flips from +0 to -1 and subsequently, how to address that boundary. Ideally we 
can just fix all of the things you mention, but I think it is important to 
understand them in detail, that's why I was going into them. Ultimately, I want 
to understand what we need to do to ship 1.2.0.

On Feb 26, 2012, at 21:22 , Bob Dionne wrote:

 Jan,
 
 I'm -1 based on all of my evaluation. I've spent a few hours on this release 
 now yesterday and today. It doesn't really pass what I would call the smoke 
 test. Almost everything I've run into has an explanation:
 
 1. crashes out of the box - that's R15B, you need to recompile SSL and Erlang 
 (we'll note on release notes)

Have we spent any time on figuring out what the trouble here is?


 2. etaps hang running make check. Known issue. Our etap code is out of date, 
 recent versions of etap don't even run their own unit tests

I have seen the etap hang as well, and I wasn't diligent enough to report it in 
JIRA, I have done so now (COUCHDB-1424).


 3. Futon tests fail. Some are known bugs (attachment ranges in Chrome) . Both 
 Chrome and Safari also hang

Do you have more details on where Chrome and Safari hang? Can you try their 
private browsing features, double/triple check that caches are empty? Can you 
get to a situation where you get all tests succeeding across all browsers, even 
if individual ones fail on one or two others?


 4. standalone JS tests fail. Again most of these run when run by themselves

Which ones?


 5. performance. I used real production data *because* Stefan on user reported 
 performance degradation on his data set. Any numbers are meaningless for a 
 single test. I also ran scripts that BobN and Jason Smith posted that show a 
 difference between 1.1.x and 1.2.x

You are conflating an IRC discussion we've had into this thread. The 
performance regression reported is a good reason to look into other scenarios 
where we can show slowdowns. But we need to understand what's happening. Just 
from looking at dev@ all I see is some handwaving about some reports some 
people have done (Not to discourage any work that has been done on IRC and 
user@, but for the sake of a release vote thread, this related information 
needs to be on this mailing list).

As I said on IRC, I'm happy to get my hands dirty to understand the regression 
at hand. But we need to know where we'd draw a line and say this isn't 
acceptable for a 1.2.0.


 6. Reviewed patch pointed to by Jason that may be the cause but it's hard to 
 say without knowing the code analysis that went into the changes. You can see 
 obvious local optimizations that make good sense but those are often the ones 
 that get you, without knowing the call counts.

That is a point that wasn't included in your previous mail. It's great that 
there is progress, thanks for looking into this!


 Many of these issues can be explained away, but I think end users will be 
 less forgiving. I think we already struggle with view performance. I'm 
 interested to see how others evaluate this regression.
 I'll try this seatoncouch tool you mention later to see if I can construct 
 some more definitive tests.

Again, I'm not trying to explain anything away. I want to get a shared 
understanding of the issues you raised and where we stand on solving them 
squared against the ongoing 1.2.0 release.

And again: Thanks for doing this thorough review and looking into performance 
issue. I hope with your help we can understand all these things a lot better 
very soon :)

Cheers
Jan
-- 


 
 Best,
 
 Bob
 On Feb 26, 2012, at 2:29 PM, Jan Lehnardt wrote:
 
 
 On Feb 26, 2012, at 13:58 , Bob Dionne wrote:
 
 -1
 
 R15B on OS X Lion
 
 I rebuilt OTP with an older SSL and that gets past all the crashes (thanks 
 Filipe). I still see hangs when running make check, though any particular 
 etap that hangs will run ok by itself. The Futon tests never run to 
 completion in Chrome without hanging and the standalone JS tests also have 
 fails.
 
 What part of this do you consider the -1? Can you try running the JS tests 
 in Firefox and or Safari? Can you get all tests pass at least once across 
 all browsers? The cli JS suite isn't supposed to work, so that isn't a 
 criterion. I've seen the hang in make check for R15B while individual tests 
 run as well, but I don't consider this blocking. While I understand and 
 support the notion that tests shouldn't fail, period, we gotta work with 
 what we have and master already has significant improvements. What would you 
 like to see changed to not -1 this release?
 
 I tested the performance of view indexing, using a modest 200K doc db with 
 a large complex view and there's a clear regression between 1.1.x and 1.2.x 
 Others report similar results
 
 What is a large complex view? The complexity of the

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Sebastian Cohnen

OS X 10.7.3, Erlang R15B, Spidermonkey 1.8.5, tests run in Chrome 19.0.1049.3 
dev

* signatures okay
* make check okay
* test suite okay (the attachment_ranges test constantly fails [1] in Chrome, 
but works fine in FF 10.0)


So I'm +1


[1]:
expected 'bytes 0-28/29', got 'bytes 0-29/29'
expected '29', got '30'

On 23.02.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,
 
 N

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Robert Newson

attachment_ranges is expected to fail on Chrome because Chrome is wrong.

to prove this more clearly, change line 29 of the test to Range:
bytes=0-1000 and run it again, Chrome will tell you it
fetched 1001 bytes of the 28 byte attachment. A neat trick.

B.

On 24 February 2012 09:03, Sebastian Cohnen
sebastiancoh...@googlemail.com wrote:
 OS X 10.7.3, Erlang R15B, Spidermonkey 1.8.5, tests run in Chrome 19.0.1049.3 
 dev

 * signatures okay
 * make check okay
 * test suite okay (the attachment_ranges test constantly fails [1] in 
 Chrome, but works fine in FF 10.0)


 So I'm +1


 [1]:
 expected 'bytes 0-28/29', got 'bytes 0-29/29'
 expected '29', got '30'

 On 23.02.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,

 N

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Dirkjan Ochtman

On Thu, Feb 23, 2012 at 00:28, Noah Slater nsla...@tumbolia.org wrote:
 We are voting on the following release artifacts:

 http://people.apache.org/~nslater/dist/1.2.0/

Gentoo Linux 64-bits, Erlang 13B4, Spidermonkey 1.8.5.

Signatures check out, make check passes.

Browser tests pass in Firefox 12.0a2, although replicator_db_security
failed once before it succeeded.

+1 on release.

Cheers,

Dirkjan

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Jonathan Porta

Fedora 15 64bit, Erlang 14B04, Spidermonkey 1.8.5

Everything checks out!

Jonathan Porta



On Fri, Feb 24, 2012 at 3:44 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
 On Thu, Feb 23, 2012 at 00:28, Noah Slater nsla...@tumbolia.org wrote:
 We are voting on the following release artifacts:

 http://people.apache.org/~nslater/dist/1.2.0/

 Gentoo Linux 64-bits, Erlang 13B4, Spidermonkey 1.8.5.

 Signatures check out, make check passes.

 Browser tests pass in Firefox 12.0a2, although replicator_db_security
 failed once before it succeeded.

 +1 on release.

 Cheers,

 Dirkjan

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Sebastian Cohnen

Jonathan, you forgot to cast your vote! (Which needs to be either +1 or −1)

On 24.02.2012, at 14:50, Jonathan Porta wrote:

 Fedora 15 64bit, Erlang 14B04, Spidermonkey 1.8.5
 
 Everything checks out!
 
 Jonathan Porta
 
 
 
 On Fri, Feb 24, 2012 at 3:44 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
 On Thu, Feb 23, 2012 at 00:28, Noah Slater nsla...@tumbolia.org wrote:
 We are voting on the following release artifacts:
 
 http://people.apache.org/~nslater/dist/1.2.0/
 
 Gentoo Linux 64-bits, Erlang 13B4, Spidermonkey 1.8.5.
 
 Signatures check out, make check passes.
 
 Browser tests pass in Firefox 12.0a2, although replicator_db_security
 failed once before it succeeded.
 
 +1 on release.
 
 Cheers,
 
 Dirkjan

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Jason Smith

On Wed, Feb 22, 2012 at 11:28 PM, Noah Slater nsla...@tumbolia.org 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

+1

Good build, make check, browser tests pass:

* Fedora 16, R15B
* Ubuntu 11.10, R15B
* Ubuntu 10.04 LTS, R15B
* OS X Lion, R15B, no crashes or hangs either

-- 
Iris Couch

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Jonathan Porta

+1!

Jonathan Porta



On Fri, Feb 24, 2012 at 7:07 AM, Sebastian Cohnen
sebastiancoh...@googlemail.com wrote:
 Jonathan, you forgot to cast your vote! (Which needs to be either +1 or -1)

 On 24.02.2012, at 14:50, Jonathan Porta wrote:

 Fedora 15 64bit, Erlang 14B04, Spidermonkey 1.8.5

 Everything checks out!

 Jonathan Porta



 On Fri, Feb 24, 2012 at 3:44 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
 On Thu, Feb 23, 2012 at 00:28, Noah Slater nsla...@tumbolia.org wrote:
 We are voting on the following release artifacts:

 http://people.apache.org/~nslater/dist/1.2.0/

 Gentoo Linux 64-bits, Erlang 13B4, Spidermonkey 1.8.5.

 Signatures check out, make check passes.

 Browser tests pass in Firefox 12.0a2, although replicator_db_security
 failed once before it succeeded.

 +1 on release.

 Cheers,

 Dirkjan

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Benoit Chesneau

On Thu, Feb 23, 2012 at 12:28 AM, Noah Slater nsla...@tumbolia.org 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,

 N

+1 make check , js tests  signatures ok

erlang R14B04 - osx lion  snow leopard, ubuntu 11.04, 11.10, debian 6, fbsd 8.2

- benoît

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-24 Thread Benoit Chesneau

On Fri, Feb 24, 2012 at 4:39 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Feb 23, 2012 at 12:28 AM, Noah Slater nsla...@tumbolia.org 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,

 N

 +1 make check , js tests  signatures ok

 erlang R14B04 - osx lion  snow leopard, ubuntu 11.04, 11.10, debian 6, fbsd 
 8.2

 - benoît

q note: i had to buy my openssl to have it working with it on osx
lion. Also I used spidermonkey 1.8.5.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Robert Newson

+1

md5, sha, sig verified.
make check passes.
futon fully passes in FF 10.0. fully passes in Chrome 17 (except
attachment_ranges).

OS X 10.7.3, spidermonkey 1.8.5, icu 4.8.1.1.

B.

On 23 February 2012 04:39, Brian Mitchell binar...@gmail.com wrote:
 Same result as last vote on OS X 10.7.3 using Erlang OTP R15B and 
 spidermonkey 1.8.5 . `make check` hangs on 076-file-compression.t and passes 
 in the browser as long as I'm in private browsing mode or have the cache 
 disabled. I'll do a test on Linux tomorrow with R14B04 before I +1.

 Brian.


 On Wednesday, February 22, 2012 at 18: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,

 N

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Robert Newson

omitted to say this was R14B04, sorry.

On 23 February 2012 11:33, Robert Newson rnew...@apache.org wrote:
 +1

 md5, sha, sig verified.
 make check passes.
 futon fully passes in FF 10.0. fully passes in Chrome 17 (except
 attachment_ranges).

 OS X 10.7.3, spidermonkey 1.8.5, icu 4.8.1.1.

 B.

 On 23 February 2012 04:39, Brian Mitchell binar...@gmail.com wrote:
 Same result as last vote on OS X 10.7.3 using Erlang OTP R15B and 
 spidermonkey 1.8.5 . `make check` hangs on 076-file-compression.t and passes 
 in the browser as long as I'm in private browsing mode or have the cache 
 disabled. I'll do a test on Linux tomorrow with R14B04 before I +1.

 Brian.


 On Wednesday, February 22, 2012 at 18: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,

 N

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Benoit Chesneau

On Thu, Feb 23, 2012 at 3:51 AM, Paul Davis paul.joseph.da...@gmail.com wrote:
 More than likely this is the SSL issue that Erlang has had issues
 with. Perhaps its time that I go in and see if I can't patch Erlang to
 use the newer OS X functions. Filipe had more details but IIRC the fix
 was basically to compile your own SSL and get Erlang to link against
 that.

Yes smth like:

https://github.com/refuge/refuge/wiki/Refuge-Build-on-MacOSX-Lion


- benoît

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Noah Slater

Bob,

When I was suffering this, I would get bus errors or segmentation faults at
random. They are non-deterministic, as far as I can tell. As I said at the
start of this thread, I got a segfault on my first run through, and not my
second or third.

On Thu, Feb 23, 2012 at 3:06 AM, Bob Dionne dio...@dionne-associates.comwrote:

 perhaps, oddly if I try it without running make distcheck first I get a
 different error:

 Segmentation fault: 11

 dependencies are fun
 On Feb 22, 2012, at 9:51 PM, Paul Davis wrote:

  More than likely this is the SSL issue that Erlang has had issues
  with. Perhaps its time that I go in and see if I can't patch Erlang to
  use the newer OS X functions. Filipe had more details but IIRC the fix
  was basically to compile your own SSL and get Erlang to link against
  that.
 
  On Wed, Feb 22, 2012 at 8:07 PM, Bob Dionne
  dio...@dionne-associates.com wrote:
  I've been doing that all along, master branch, 1.0.x, any source build
 is fine. I saw these occasionally before on the Mackbook Pro, this is the
 first one I've seen on the MBA
 
  It is odd that I'm only seeing it on this build, the only diff being I
 hardly ever run make distcheck. I'll try it without running that.
 
 
  On Feb 22, 2012, at 8:02 PM, Noah Slater wrote:
 
  Could you try again a few times maybe, try testing the source directly
 from
  your checkout?
 
  On Thu, Feb 23, 2012 at 12:26 AM, Bob Dionne
  dio...@dionne-associates.comwrote:
 
  I've seen this page before Noah, and something like these Bus errors.
 I
  think it might be the use of R15B
 
  What's odd is that I don't have any problems withe the 1.2 branch, or
 any
  branch for that matter
 
  On Feb 22, 2012, at 6:55 PM, Noah Slater wrote:
 
  Can you try this and report back please:
 
 
 
 http://wiki.apache.org/couchdb/Troubleshooting#Segmentation_faults_and_bus_errors
 
  On Wed, Feb 22, 2012 at 11:51 PM, Bob Dionne
  dio...@dionne-associates.comwrote:
 
  make distcheck ran ok
 
  server keeps crashing with:
 
  Bus error: 10
 
  On Feb 22, 2012, at 6:29 PM, Noah Slater wrote:
 
  I might add that I got a segfault on the first try with the test
 suite,
  but
  was unable to reproduce it with two further runs. I would
 appreciate
  some
  feedback on this to assure me that it's nothing to worry about.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Noah Slater

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 j...@apache.org 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
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Filipe David Manana

On Thu, Feb 23, 2012 at 9:09 AM, Jan Lehnardt j...@apache.org 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?

The compression fails because snappy NIF needs R13B04+ (forgot to
update the test to work with R13B03 and below).

For the compaction one, on ubuntu/debian you need to install the
package 'erlang-os-mon'


 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
 --




-- 
Filipe David Manana,

Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Jan Lehnardt


On Feb 23, 2012, at 19:47 , Filipe David Manana wrote:

 On Thu, Feb 23, 2012 at 9:09 AM, Jan Lehnardt j...@apache.org 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?
 
 The compression fails because snappy NIF needs R13B04+ (forgot to
 update the test to work with R13B03 and below).
 
 For the compaction one, on ubuntu/debian you need to install the
 package 'erlang-os-mon'

Thanks for the update Filipe! My +1 stands :)

Cheers
Jan
--

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Brian Mitchell

+1

(checks passed on Arch Linux 3.2.6 64bit,  R14B04, Spidermonkey 1.8.5)


On Wednesday, February 22, 2012 at 23:39 , Brian Mitchell wrote:

 Same result as last vote on OS X 10.7.3 using Erlang OTP R15B and 
 spidermonkey 1.8.5 . `make check` hangs on 076-file-compression.t and passes 
 in the browser as long as I'm in private browsing mode or have the cache 
 disabled. I'll do a test on Linux tomorrow with R14B04 before I +1.
 
 Brian. 
 
 On Wednesday, February 22, 2012 at 18: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,
  
  N

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Bob Dionne

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 j...@apache.org 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
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Robert Newson

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 dio...@dionne-associates.com 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 j...@apache.org 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
 --

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Dave Cottlehuber

 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

+1

md5, sha, sig OK
diff OK

Windows 7 Enterprise x64  firefox 6.01
  both R14B04 and R15B
  OpenSSL 0.9.8r
  SpiderMonkey 1.8.5
  ICU 4.6.1
  curl 7.23.1
- make check n/a
binaries from https://people.apache.org/~dch/dist/1.2.0/
- both sigs OK
- no malware found
- user verification OK
- futon OK

Linux Mint LMDE x64
  R14B03
  ICU 4.4.2
  OpenSSL 1.0.0d
  Spidermonkey libmozjs5d (JavaScript-C 1.8.0 pre-release 1 2007-10-03)
- make distcheck OK
- make check OK
  Firefox 9.0.1
- user verification OK
- futon OK

A+
Dave

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-23 Thread Noah Slater

Are you going to call a separate vote on these Dave?

On Thu, Feb 23, 2012 at 11:07 PM, Dave Cottlehuber d...@muse.net.nz 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

 +1

 md5, sha, sig OK
 diff OK

 Windows 7 Enterprise x64  firefox 6.01
  both R14B04 and R15B
  OpenSSL 0.9.8r
  SpiderMonkey 1.8.5
  ICU 4.6.1
  curl 7.23.1
 - make check n/a
 binaries from https://people.apache.org/~dch/dist/1.2.0/
 - both sigs OK
 - no malware found
 - user verification OK
 - futon OK

 Linux Mint LMDE x64
  R14B03
  ICU 4.4.2
  OpenSSL 1.0.0d
  Spidermonkey libmozjs5d (JavaScript-C 1.8.0 pre-release 1 2007-10-03)
- make distcheck OK
- make check OK
  Firefox 9.0.1
- user verification OK
- futon OK

 A+
 Dave

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-22 Thread Noah Slater

I might add that I got a segfault on the first try with the test suite, but
was unable to reproduce it with two further runs. I would appreciate some
feedback on this to assure me that it's nothing to worry about.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

make distcheck ran ok

server keeps crashing with:

Bus error: 10

On Feb 22, 2012, at 6:29 PM, Noah Slater wrote:

 I might add that I got a segfault on the first try with the test suite, but
 was unable to reproduce it with two further runs. I would appreciate some
 feedback on this to assure me that it's nothing to worry about.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-22 Thread Noah Slater

Can you try this and report back please:

http://wiki.apache.org/couchdb/Troubleshooting#Segmentation_faults_and_bus_errors

On Wed, Feb 22, 2012 at 11:51 PM, Bob Dionne
dio...@dionne-associates.comwrote:

 make distcheck ran ok

 server keeps crashing with:

 Bus error: 10

 On Feb 22, 2012, at 6:29 PM, Noah Slater wrote:

  I might add that I got a segfault on the first try with the test suite,
 but
  was unable to reproduce it with two further runs. I would appreciate some
  feedback on this to assure me that it's nothing to worry about.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

I've seen this page before Noah, and something like these Bus errors. I think 
it might be the use of R15B

What's odd is that I don't have any problems withe the 1.2 branch, or any 
branch for that matter

On Feb 22, 2012, at 6:55 PM, Noah Slater wrote:

 Can you try this and report back please:
 
 http://wiki.apache.org/couchdb/Troubleshooting#Segmentation_faults_and_bus_errors
 
 On Wed, Feb 22, 2012 at 11:51 PM, Bob Dionne
 dio...@dionne-associates.comwrote:
 
 make distcheck ran ok
 
 server keeps crashing with:
 
 Bus error: 10
 
 On Feb 22, 2012, at 6:29 PM, Noah Slater wrote:
 
 I might add that I got a segfault on the first try with the test suite,
 but
 was unable to reproduce it with two further runs. I would appreciate some
 feedback on this to assure me that it's nothing to worry about.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-22 Thread Noah Slater

Could you try again a few times maybe, try testing the source directly from
your checkout?

On Thu, Feb 23, 2012 at 12:26 AM, Bob Dionne
dio...@dionne-associates.comwrote:

 I've seen this page before Noah, and something like these Bus errors. I
 think it might be the use of R15B

 What's odd is that I don't have any problems withe the 1.2 branch, or any
 branch for that matter

 On Feb 22, 2012, at 6:55 PM, Noah Slater wrote:

  Can you try this and report back please:
 
 
 http://wiki.apache.org/couchdb/Troubleshooting#Segmentation_faults_and_bus_errors
 
  On Wed, Feb 22, 2012 at 11:51 PM, Bob Dionne
  dio...@dionne-associates.comwrote:
 
  make distcheck ran ok
 
  server keeps crashing with:
 
  Bus error: 10
 
  On Feb 22, 2012, at 6:29 PM, Noah Slater wrote:
 
  I might add that I got a segfault on the first try with the test suite,
  but
  was unable to reproduce it with two further runs. I would appreciate
 some
  feedback on this to assure me that it's nothing to worry about.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

I've been doing that all along, master branch, 1.0.x, any source build is fine. 
I saw these occasionally before on the Mackbook Pro, this is the first one I've 
seen on the MBA

It is odd that I'm only seeing it on this build, the only diff being I hardly 
ever run make distcheck. I'll try it without running that.


On Feb 22, 2012, at 8:02 PM, Noah Slater wrote:

 Could you try again a few times maybe, try testing the source directly from
 your checkout?
 
 On Thu, Feb 23, 2012 at 12:26 AM, Bob Dionne
 dio...@dionne-associates.comwrote:
 
 I've seen this page before Noah, and something like these Bus errors. I
 think it might be the use of R15B
 
 What's odd is that I don't have any problems withe the 1.2 branch, or any
 branch for that matter
 
 On Feb 22, 2012, at 6:55 PM, Noah Slater wrote:
 
 Can you try this and report back please:
 
 
 http://wiki.apache.org/couchdb/Troubleshooting#Segmentation_faults_and_bus_errors
 
 On Wed, Feb 22, 2012 at 11:51 PM, Bob Dionne
 dio...@dionne-associates.comwrote:
 
 make distcheck ran ok
 
 server keeps crashing with:
 
 Bus error: 10
 
 On Feb 22, 2012, at 6:29 PM, Noah Slater wrote:
 
 I might add that I got a segfault on the first try with the test suite,
 but
 was unable to reproduce it with two further runs. I would appreciate
 some
 feedback on this to assure me that it's nothing to worry about.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round

2012-02-22 Thread Paul Davis

More than likely this is the SSL issue that Erlang has had issues
with. Perhaps its time that I go in and see if I can't patch Erlang to
use the newer OS X functions. Filipe had more details but IIRC the fix
was basically to compile your own SSL and get Erlang to link against
that.

On Wed, Feb 22, 2012 at 8:07 PM, Bob Dionne
dio...@dionne-associates.com wrote:
 I've been doing that all along, master branch, 1.0.x, any source build is 
 fine. I saw these occasionally before on the Mackbook Pro, this is the first 
 one I've seen on the MBA

 It is odd that I'm only seeing it on this build, the only diff being I hardly 
 ever run make distcheck. I'll try it without running that.


 On Feb 22, 2012, at 8:02 PM, Noah Slater wrote:

 Could you try again a few times maybe, try testing the source directly from
 your checkout?

 On Thu, Feb 23, 2012 at 12:26 AM, Bob Dionne
 dio...@dionne-associates.comwrote:

 I've seen this page before Noah, and something like these Bus errors. I
 think it might be the use of R15B

 What's odd is that I don't have any problems withe the 1.2 branch, or any
 branch for that matter

 On Feb 22, 2012, at 6:55 PM, Noah Slater wrote:

 Can you try this and report back please:


 http://wiki.apache.org/couchdb/Troubleshooting#Segmentation_faults_and_bus_errors

 On Wed, Feb 22, 2012 at 11:51 PM, Bob Dionne
 dio...@dionne-associates.comwrote:

 make distcheck ran ok

 server keeps crashing with:

 Bus error: 10

 On Feb 22, 2012, at 6:29 PM, Noah Slater wrote:

 I might add that I got a segfault on the first try with the test suite,
 but
 was unable to reproduce it with two further runs. I would appreciate
 some
 feedback on this to assure me that it's nothing to worry about.

Re: [VOTE] Apache CouchDB 1.2.0 release, second round