date:20111020

If anyone is currently using SpiderMonkey 1.7.0 I would be very
interested if you could try a (non-builtin) filtered replication after
first performing a view build (for the same database).

B.

On 20 October 2011 13:15, Filipe David Manana fdman...@apache.org wrote:
 +1

 Mac OS X Lion,
 Google Chrome,
 all test pass, signatures match

 On Thu, Oct 20, 2011 at 11:55 AM, Klaus Trainer klaus_trai...@posteo.de 
 wrote:
 Ubuntu 10.10 (Maverick) amd64 with Erlang R14B01, Firefox 8.0,
 xulrunner-1.9.2.23 (configure
 --with-js-lib=/usr/lib/xulrunner-devel-1.9.2.23/lib
 --with-js-include=/usr/lib/xulrunner-devel-1.9.2.23/include)

 * `diff -r` between release and git tag 1.1.1
 (https://git-wip-us.apache.org/repos/asf/couchdb.git): ok
 * gpg, md5, sha1 signatures: ok
 * make check: ok
 * Futon tests: ok

 +1


 Thanks all!

 - Klaus


 On Wed, 2011-10-19 at 15:27 +0100, Robert Newson wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.





 --
 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.1.1 Release

2011-10-20 Thread Andrey Syrokomskiy

Ubuntu 11.10 x86_64

Signatures - OK
make check - OK
make install - OK
Browsers - some FAILURES, see below

Cache and cookies is cleared, test dbs is removed before start tests (first
run). Running all.


**Firefox 7.0.1**
  First run - all OK
  Second run - 4 FAILURES
attachments - Assertion failed: xhr.responseText == lorem; Exception 
raised: {}
auth_cache - Assertion failed: misses_after === misses_before + 1; Assertion
failed: hits_after === hits_before
list_views - Assertion 'xhr.status == 200, standard get should be 200'
failed: standard get should be 200; Assertion failed:
/head0123456789tail/.test(xhr.responseText)
rev_stemming - Assertion failed: db.open(bar, {revs:
true})._revisions.ids.length == newLimit + 1; Assertion failed: db.open(bar,
{revs: true})._revisions.ids.length == newLimit + 1


**Opera 11.51**
  First run - 37 failures, see links below
http://i080.radikal.ru/1110/ab/a35a598a8922.png
http://s001.radikal.ru/i193/1110/cb/57e1ef6dd74a.png
  Second run - 39 failures, added
auth_cache - Assertion failed: misses_after === (misses_before + 1)
Assertion failed: hits_after === hits_before
replication - Exception raised: {message:JSON.parse: Unable to parse
value: }

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


make check pass, but when running js tests I got the following error
(reproducible from time to time) :

[info] [0.1915.0] Stopping all ongoing replications because the
replicator database was deleted or changed
Apache CouchDB 1.1.1 (LogLevel=info) is starting.
Segmentation fault: 11

configuration : rb1404, osx lion (last update)

- benoit

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
and the crypto application was loaded (CouchDB's case) the VM crashes
with either a bus error, segmentation fault or no error message at
all.

Have you tried building OTP like in https://gist.github.com/1199903 ?

I had exactly the same issue.


 - benoit




-- 
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.1.1 Release

On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


Shouldn't it be fixed in r144b04? ALso I don't reproduce it at all on
refuge when running tests, s it may be due to the way we compile
couch.

- benoit

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Thu, Oct 20, 2011 at 3:28 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


 Shouldn't it be fixed in r144b04? ALso I don't reproduce it at all on
 refuge when running tests, s it may be due to the way we compile
 couch.

 - benoit


just after typed that I realised that refuge is also based on current trunk...

- benoit

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Thu, Oct 20, 2011 at 2:28 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


 Shouldn't it be fixed in r144b04?

Nop, not fixed in r14b04 unfortunately.
And it's independent of the couch codebase, since all start the crypto
application.

 ALso I don't reproduce it at all on
 refuge when running tests, s it may be due to the way we compile
 couch.

 - benoit




-- 
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.1.1 Release

On Thu, Oct 20, 2011 at 3:29 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:28 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com 
 wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


 Shouldn't it be fixed in r144b04? ALso I don't reproduce it at all on
 refuge when running tests, s it may be due to the way we compile
 couch.

 - benoit


 just after typed that I realised that refuge is also based on current trunk...

 - benoit

which means there's maybe a problem on 1.1.1 . Did anyone tried withe same conf?

- benoît

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Thu, Oct 20, 2011 at 3:47 PM, Filipe David Manana
fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:28 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com 
 wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


 Shouldn't it be fixed in r144b04?

 Nop, not fixed in r14b04 unfortunately.
 And it's independent of the couch codebase, since all start the crypto
 application.

 ALso I don't reproduce it at all on
 refuge when running tests, s it may be due to the way we compile
 couch.

 - benoit




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


Like I said i've no problem on refuge though. Yes all apps starts
crypt but here:


2 crypto:start().
ok
3 init:restart().
ok
4 Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4]
[async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.5  (abort with ^G)
1


works. So it maybe  not related to crypto or openssl.

- benoit

[jira] [Created] (COUCHDB-1313) Support JSONP in externals

2011-10-20 Thread Robert Newson (Created) (JIRA)

Support JSONP in externals
--

 Key: COUCHDB-1313
 URL: https://issues.apache.org/jira/browse/COUCHDB-1313
 Project: CouchDB
  Issue Type: New Feature
Reporter: Robert Newson
Assignee: Robert Newson
 Fix For: 1.2




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-1313) Support JSONP in externals

2011-10-20 Thread Robert Newson (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131690#comment-13131690
 ] 

Robert Newson commented on COUCHDB-1313:


The proposed patch is here;

https://github.com/rnewson/couchdb/compare/master...1313-jsonp-externals


 Support JSONP in externals
 --

 Key: COUCHDB-1313
 URL: https://issues.apache.org/jira/browse/COUCHDB-1313
 Project: CouchDB
  Issue Type: New Feature
Reporter: Robert Newson
Assignee: Robert Newson
 Fix For: 1.2




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Thu, Oct 20, 2011 at 2:57 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:47 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:28 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com 
 wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty 
 ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


 Shouldn't it be fixed in r144b04?

 Nop, not fixed in r14b04 unfortunately.
 And it's independent of the couch codebase, since all start the crypto
 application.

 ALso I don't reproduce it at all on
 refuge when running tests, s it may be due to the way we compile
 couch.

 - benoit




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


 Like I said i've no problem on refuge though. Yes all apps starts
 crypt but here:


 2 crypto:start().
 ok
 3 init:restart().
 ok
 4 Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4]
 [async-threads:0] [hipe] [kernel-poll:false]

 Eshell V5.8.5  (abort with ^G)
 1


 works. So it maybe  not related to crypto or openssl.

The openssl issue didn't happen always, only sometimes.
Try running the following bash loop against trunk/refuge:

$ for i in `seq 1 1000`; do curl -s -H 'Content-Type:
application/json' -X POST http://localhost:5984/_restart ; sleep 1;
done

Se then if you get a bus error, seg fault or the vm simply doesn't
restart and no error gets sent to the console.


 - benoit




-- 
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.1.1 Release

On Thu, Oct 20, 2011 at 6:05 PM, Filipe David Manana
fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:57 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:47 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:28 PM, Benoit Chesneau bchesn...@gmail.com 
 wrote:
 On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com 
 wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org 
 wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty 
 ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


 Shouldn't it be fixed in r144b04?

 Nop, not fixed in r14b04 unfortunately.
 And it's independent of the couch codebase, since all start the crypto
 application.

 ALso I don't reproduce it at all on
 refuge when running tests, s it may be due to the way we compile
 couch.

 - benoit




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


 Like I said i've no problem on refuge though. Yes all apps starts
 crypt but here:


 2 crypto:start().
 ok
 3 init:restart().
 ok
 4 Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4]
 [async-threads:0] [hipe] [kernel-poll:false]

 Eshell V5.8.5  (abort with ^G)
 1


 works. So it maybe  not related to crypto or openssl.

 The openssl issue didn't happen always, only sometimes.
 Try running the following bash loop against trunk/refuge:

 $ for i in `seq 1 1000`; do curl -s -H 'Content-Type:
 application/json' -X POST http://localhost:5984/_restart ; sleep 1;
 done

 Se then if you get a bus error, seg fault or the vm simply doesn't
 restart and no error gets sent to the console.


 - benoit



I will trust you on that one, I can't test right now, I'm at ogdcamp
and no more battery on my lappy. Old erlang was given me an error each
time, not sure what changed since. If this is the case I think we
should provide a warning during compilation anyway. Like for couchjs 
spidermonkey, I think  it's our responsibility to warn the user that
something can happen on this platform,

Re: [VOTE] Apache CouchDB 1.1.1 Release

Hi All,

Thanks for all the responses so far. Unfortunately I am aborting this round.

It turns out there is a serious bug in this 1.1.1 candidate when using
SpiderMonkey 1.7.0. Instead of sealing the 'doc' parameter to views,
we seal the object that defines the seal function, which then causes
all kinds of 'X is read-only' events.

It's a one word fix, so a new 1.1.1 candidate will be out very soon,
and it should not invalidate any of these results.

B.

On 20 October 2011 14:57, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:47 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:28 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com 
 wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty 
 ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


 Shouldn't it be fixed in r144b04?

 Nop, not fixed in r14b04 unfortunately.
 And it's independent of the couch codebase, since all start the crypto
 application.

 ALso I don't reproduce it at all on
 refuge when running tests, s it may be due to the way we compile
 couch.

 - benoit




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


 Like I said i've no problem on refuge though. Yes all apps starts
 crypt but here:


 2 crypto:start().
 ok
 3 init:restart().
 ok
 4 Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4]
 [async-threads:0] [hipe] [kernel-poll:false]

 Eshell V5.8.5  (abort with ^G)
 1


 works. So it maybe  not related to crypto or openssl.

 - benoit

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Thu, Oct 20, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote:
 Hi All,

 Thanks for all the responses so far. Unfortunately I am aborting this round.

 It turns out there is a serious bug in this 1.1.1 candidate when using
 SpiderMonkey 1.7.0. Instead of sealing the 'doc' parameter to views,
 we seal the object that defines the seal function, which then causes
 all kinds of 'X is read-only' events.

 It's a one word fix, so a new 1.1.1 candidate will be out very soon,
 and it should not invalidate any of these results.

 B.


:(

It would worth to look at this erlang warning too imo. Hopefully i
will have some wifi at the hotel tonight.I will see if I can make it.

- benoit

[jira] [Reopened] (COUCHDB-860) Futon appends wrong version number to files

2011-10-20 Thread Randall Leeds (Reopened) (JIRA)


 [ 
https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randall Leeds reopened COUCHDB-860:
---


Thanks. I couldn't find where this happened. I tried grepping around for 0.11.0 
but didn't find that somehow.

 Futon appends wrong version number to files
 ---

 Key: COUCHDB-860
 URL: https://issues.apache.org/jira/browse/COUCHDB-860
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 1.0.1
Reporter: Volker Mische
Priority: Minor

 Futon appends the CouchDB version number to the JavaScript files it loads. In 
 1.0.1 it still appends 0.11

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-860) Futon appends wrong version number to files

2011-10-20 Thread J. Lee Coltrane (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131806#comment-13131806
 ] 

J. Lee Coltrane commented on COUCHDB-860:
-

./share/www/database.html
./share/www/custom_test.html
./share/www/couch_tests.html
./share/www/status.html
./share/www/replicator.html
./share/www/document.html
./share/www/index.html
./share/www/session.html
./share/www/config.html



 Futon appends wrong version number to files
 ---

 Key: COUCHDB-860
 URL: https://issues.apache.org/jira/browse/COUCHDB-860
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 1.0.1
Reporter: Volker Mische
Priority: Minor

 Futon appends the CouchDB version number to the JavaScript files it loads. In 
 1.0.1 it still appends 0.11

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)

On Wed, Oct 19, 2011 at 10:38 PM, J. Lee Coltrane
l...@projectmastermind.com wrote:

 For what it's worth, a CLI based test system is what I was imagining
 as well. Take Futon out of the mix and test CouchDB.

 IMO, If CouchDB is intended to be a server that can be accessed from
 the browser directly, then there should continue to be some kind of
 browser-based test suite that would serve to confirm this capability.


CouchDB is intended to be a server that can be accessed from HTTP
clients. Browsers are but one of a huge range of clients. I do agree
that there should be a browser based test suite, but I'm proposing
that these browser based tests should be testing the browser and not
testing CouchDB internals.


 I have been looking closely at the Futon tests in 1.1.0 for the last
 several days, with the idea that I might begin to clean them up a bit
 as time permits.

 I have found that, while some of these test failures are totally bogus,
 *some* of them actually do stem from real issues -- minor
 incompatibilities between CouchDB's http interface, and the internal
 mechanisms of modern browsers (XHR, caching, etc).

 These are problems that we're not going to catch with a stateless,
 cache-less http client running on the CLI.  (I can provide examples)


And I can provide examples where having a stateful caching client
merely exists to confound the test code. The issue is that using a
stateful caching client means that all tests have to account for this,
even tests that have nothing to do with such things.

 These issues have the potential to cause real problems for
 developers of real browser-based apps in the wild.  That means,
 there's valuable info to be gathered from the browser tests, Iff we
 can clean them up, and make them behave consistently; so that
 when they fail or succeed, we can actually trust the results.


 After digging around a good bit, I can see no reason why the existing
 tests couldn't be cleaned up and made to work correctly in all current
 versions of major browsers.  I also see no reason why the same tests
 couldn't be used successfully from the CLI and `make check` as well.


There are some tests that make use of XHR directly which are incapable
of being run from the CLI test runner for one. There are also issues
in differences of caching implementations. There are even differences
of caching against localhost vs a remote server. I consider every time
I've had to diagnose a difference in browser behavior as an example of
precisely why (most of) these tests do not belong in a browser. Not
only is this a waste of time, it merely serves to make the test suite
less trustable when an error occurs.

We can hand wave about cleaning up the tests to make them more
reliable, but that's ignoring the fact that we're running the test
suite in huge monolithic environments that have a decades long history
of maddeningly subtle different semantics.

 I do see significant benefits to using the same javascript test code in
 all environments we test.


What's the benefit to maintaing assertions in the browser about view
output according to the UCA. Or whether or not the database is leaking
file descriptors. Or couch_os_process is properly caching couchjs
processes?

 -Lee
 (irc: coltr)


I don't mean to be cranky at you directly, but I am quite tired of
dealing with browsers to test a database. It was a bad idea to start
with and I've been trying to argue for the change for years now.

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)

On Thu, Oct 20, 2011 at 1:38 AM, Randall Leeds rand...@apache.org wrote:
 On Wed, Oct 19, 2011 at 23:38, J. Lee Coltrane 
 l...@projectmastermind.comwrote:


  For what it's worth, a CLI based test system is what I was imagining
  as well. Take Futon out of the mix and test CouchDB.

 IMO, If CouchDB is intended to be a server that can be accessed from
 the browser directly, then there should continue to be some kind of
 browser-based test suite that would serve to confirm this capability.


 I have been looking closely at the Futon tests in 1.1.0 for the last
 several days, with the idea that I might begin to clean them up a bit
 as time permits.

 I have found that, while some of these test failures are totally bogus,
 *some* of them actually do stem from real issues -- minor
 incompatibilities between CouchDB's http interface, and the internal
 mechanisms of modern browsers (XHR, caching, etc).

 These are problems that we're not going to catch with a stateless,
 cache-less http client running on the CLI.  (I can provide examples)

 These issues have the potential to cause real problems for
 developers of real browser-based apps in the wild.  That means,
 there's valuable info to be gathered from the browser tests, Iff we
 can clean them up, and make them behave consistently; so that
 when they fail or succeed, we can actually trust the results.


 After digging around a good bit, I can see no reason why the existing
 tests couldn't be cleaned up and made to work correctly in all current
 versions of major browsers.  I also see no reason why the same tests
 couldn't be used successfully from the CLI and `make check` as well.

 I do see significant benefits to using the same javascript test code in
 all environments we test.

 -Lee
 (irc: coltr)


  +1
 Verify Installation could grow into a suite of browser/futon tests that
 verify that futon (and apps in general) work, including interactions with
 proxies and the like.

Sure. Client tests that test the client are fine.

 The test suite for developers should run cleanly from the CLI as part of
 make check, but continue to be exposed in futon. We should work to be sure
 they function as well as possible, for the reasons you provide.


Blargh no. Server tests should be testing the server. The entire point
of moving to the command line is so that we don't have to maintain the
Futon test suite. Just look at the 1.1.1 thread (or damn near any
release thread) and the wildly varying reports of test output. The
situation is just a waste of time for everyone involved.

 I think the JS testing situation is a great place for people to jump in and
 help out, especially with the browser environment diversity.


Sure, but I don't see what this has to do with browsers.

[VOTE] Apache CouchDB 1.1.1 Release, Round 2

This is the second release vote for Apache CouchDB 1.1.1

Changes since round 1;

* Fix object sealing with SpiderMonkey 1.7.0
* Update CHANGES/NEWS to reflect COUCHDB-1129
* Fix JavaScript CLI test runner

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. Please report your
results and vote to this thread.

We are voting on the following release artifacts:

 http://people.apache.org/~rnewson/dist/1.1.1/

Instructions for validating the release tarball can be found here:

 http://people.apache.org/~rnewson/dist/

Instructions for testing the build artefacts can be found here:

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

These artifacts have been built from the 1.1.1 tag in Git:

apache-couchdb-1.1.1.tar.gz
apache-couchdb-1.1.1.tar.gz.md5
apache-couchdb-1.1.1.tar.gz.asc
apache-couchdb-1.1.1.tar.gz.sha

Test ALL the things.

B.

Re: Tweaking the release procedure

On Wed, Oct 19, 2011 at 10:10 PM, Adam Kocoloski
adam.kocolo...@gmail.com wrote:
 On Oct 19, 2011, at 10:53 PM, Dustin Sallings dus...@spy.net wrote:


 On Oct 19, 2011, at 6:56 PM, Adam Kocoloski wrote:

 I think you might be reading a bit too much into what Noah is saying here.  
 I believe he's just taking issue with the two separate rc/ and rel/ paths 
 in the tag names.  For what it's worth I agree with him on that front, 
 though I'd consider going even further (as Paul suggested earlier in the 
 thread) and just prevent rewriting of any tag pushed to the ASF remote.  
 Then there's no need for any tag prefix at all.  Best,


    I don't think that's different from what I said.  Tags don't generally 
 have paths (it's 1.4rc1 or it isn't) and git makes it hard to overwrite 
 them because it's a bad idea and will only lead to confusion.

    IMO, there just isn't room or need to innovate here.  Code's cooked in 
 various dev branches.  That gets rolled up into an official branch towards 
 a feature or release.  Once a release is almost ready, alpha, beta and RC 
 tags get dropped in aligned with the same version numbers the server will 
 report.  Once it's done, you can retag a commit with a newer tag that calls 
 it done and it's shipped.

 --
 dustin sallings

 Git makes it hard, but by no means impossible.  The whole reason these 
 paths are even on the table is to add some immutability to the official ASF 
 repo.  A little less convention, a little more configuration.  Best,

 Adam

Yes, the path prefixes (path probably was a bard word in my original
email) exists merely as a way to distinguish between these are
official releases and are immutable and the this is a temporary tag
that I can fix if I screw up.

I'm trying to consider all the cases here (in the context of my OCD).
Do we necessarily care about the rc tags once a release has been made?
In a perfect world I would expect one tag per release and everything
would be neat and tidy. If so, then we need to be able to remove old
tags once they have been usurped by actual releases.

Consider it from the POV of a user as well. If you have 5-10 tags for
a release (not out of the question) then each user looking for that
release has to spend time figuring out which is the right tag. Which
means that either our naming conventions have to be extremely clear
(even then I've seen enough to know that we'll still get questions) or
we need to have procedure to narrow down the set of tags once the
release is made. I prefer procedure because it will minimize the
number of times in the future that i have to spend time debugging the
fact that someone downloaded 1.1.1-rc1 instead of 1.1.1 which has that
bug related to SpiderMonkey 1.7 and sealing.

Re: [VOTE] Apache CouchDB 1.1.1 Release

2011-10-20 Thread J. Lee Coltrane


FWIW, the patch attached to COUCHDB-1310 
  (https://issues.apache.org/jira/browse/COUCHDB-1310)

will fix a great many (all, afaik) of the futon test hangs (the cases where
the tests get stuck, and never complete).  Without this patch, I was 
never able to get a complete run through the browser tests in 1.1.1 RC1.
With the patch, I still get test failures, but at least I can get through all 
the 
tests without restarting the browser.

The patch is tiny -- it just swaps the order of two lines of code, in the 
'/_restart' handler, so that the http response gets written *before* the server 
is restarted (rather than after).

As test instability continues to be a hot topic, maybe this patch is worth 
considering for inclusion in the next 1.1.1 RC?  

-Lee



On Oct 20, 2011, at 12:25 PM, Benoit Chesneau wrote:

 On Thu, Oct 20, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote:
 Hi All,
 
 Thanks for all the responses so far. Unfortunately I am aborting this round.
 
 It turns out there is a serious bug in this 1.1.1 candidate when using
 SpiderMonkey 1.7.0. Instead of sealing the 'doc' parameter to views,
 we seal the object that defines the seal function, which then causes
 all kinds of 'X is read-only' events.
 
 It's a one word fix, so a new 1.1.1 candidate will be out very soon,
 and it should not invalidate any of these results.
 
 B.
 
 
 :(
 
 It would worth to look at this erlang warning too imo. Hopefully i
 will have some wifi at the hotel tonight.I will see if I can make it.
 
 - benoit

Re: [VOTE] Apache CouchDB 1.1.1 Release

Too late.

I'm inclined to work with Paul Davis and make 1.1.1 the last time that
there *is* a Futon test suite.

B.

On 20 October 2011 18:54, J. Lee Coltrane l...@projectmastermind.com wrote:

 FWIW, the patch attached to COUCHDB-1310
  (https://issues.apache.org/jira/browse/COUCHDB-1310)

 will fix a great many (all, afaik) of the futon test hangs (the cases where
 the tests get stuck, and never complete).  Without this patch, I was
 never able to get a complete run through the browser tests in 1.1.1 RC1.
 With the patch, I still get test failures, but at least I can get through all 
 the
 tests without restarting the browser.

 The patch is tiny -- it just swaps the order of two lines of code, in the
 '/_restart' handler, so that the http response gets written *before* the 
 server
 is restarted (rather than after).

 As test instability continues to be a hot topic, maybe this patch is worth
 considering for inclusion in the next 1.1.1 RC?

 -Lee



 On Oct 20, 2011, at 12:25 PM, Benoit Chesneau wrote:

 On Thu, Oct 20, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote:
 Hi All,

 Thanks for all the responses so far. Unfortunately I am aborting this round.

 It turns out there is a serious bug in this 1.1.1 candidate when using
 SpiderMonkey 1.7.0. Instead of sealing the 'doc' parameter to views,
 we seal the object that defines the seal function, which then causes
 all kinds of 'X is read-only' events.

 It's a one word fix, so a new 1.1.1 candidate will be out very soon,
 and it should not invalidate any of these results.

 B.


 :(

 It would worth to look at this erlang warning too imo. Hopefully i
 will have some wifi at the hotel tonight.I will see if I can make it.

 - benoit

Re: [VOTE] Apache CouchDB 1.1.1 Release, Round 2

2011-10-20 Thread Dirkjan Ochtman

On Thu, Oct 20, 2011 at 19:44, Robert Newson rnew...@apache.org wrote:
 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. Please report your
 results and vote to this thread.

Ran it through the Gentoo packaging system again. Mixed bag: make
check is now clean, but the browser test suite has three reproducible
failures:

http://couchdb.couchdb.org/_utils/document.html?test_suite_reports/39e9ee253b2c269761c75c9049809d86

Linux, Erlang 13B04, SpiderMonkey from xulrunner-1.9.2.15, Firefox 9.0a2.

Cheers,

Dirkjan

Re: [VOTE] Apache CouchDB 1.1.1 Release

2011-10-20 Thread Robert Dionne

Interesting, this patch seems like a worthwhile thing to do regardless of the 
tests, if I understand it correctly. If restart cause the response to not be 
sent, then sending a 202 first will help at least the caller to know the 
restart was initiated.




On Oct 20, 2011, at 1:54 PM, J. Lee Coltrane wrote:

 
 FWIW, the patch attached to COUCHDB-1310 
  (https://issues.apache.org/jira/browse/COUCHDB-1310)
 
 will fix a great many (all, afaik) of the futon test hangs (the cases where
 the tests get stuck, and never complete).  Without this patch, I was 
 never able to get a complete run through the browser tests in 1.1.1 RC1.
 With the patch, I still get test failures, but at least I can get through all 
 the 
 tests without restarting the browser.
 
 The patch is tiny -- it just swaps the order of two lines of code, in the 
 '/_restart' handler, so that the http response gets written *before* the 
 server 
 is restarted (rather than after).
 
 As test instability continues to be a hot topic, maybe this patch is worth 
 considering for inclusion in the next 1.1.1 RC?  
 
 -Lee
 
 
 
 On Oct 20, 2011, at 12:25 PM, Benoit Chesneau wrote:
 
 On Thu, Oct 20, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote:
 Hi All,
 
 Thanks for all the responses so far. Unfortunately I am aborting this round.
 
 It turns out there is a serious bug in this 1.1.1 candidate when using
 SpiderMonkey 1.7.0. Instead of sealing the 'doc' parameter to views,
 we seal the object that defines the seal function, which then causes
 all kinds of 'X is read-only' events.
 
 It's a one word fix, so a new 1.1.1 candidate will be out very soon,
 and it should not invalidate any of these results.
 
 B.
 
 
 :(
 
 It would worth to look at this erlang warning too imo. Hopefully i
 will have some wifi at the hotel tonight.I will see if I can make it.
 
 - benoit

Re: [VOTE] Apache CouchDB 1.1.1 Release, Round 2

The list_views and attachments error are symptoms of not clearing your
browser cache before starting. I'm not sure about the rev_stemming
one.

Please include all information within the text of your post. These are
all archived and form a historical record of the release process.

B.


On 20 October 2011 19:31, Dirkjan Ochtman dirk...@ochtman.nl wrote:
 On Thu, Oct 20, 2011 at 19:44, Robert Newson rnew...@apache.org wrote:
 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. Please report your
 results and vote to this thread.

 Ran it through the Gentoo packaging system again. Mixed bag: make
 check is now clean, but the browser test suite has three reproducible
 failures:

 http://couchdb.couchdb.org/_utils/document.html?test_suite_reports/39e9ee253b2c269761c75c9049809d86

 Linux, Erlang 13B04, SpiderMonkey from xulrunner-1.9.2.15, Firefox 9.0a2.

 Cheers,

 Dirkjan

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)

2011-10-20 Thread Randall Leeds

On Thu, Oct 20, 2011 at 13:42, Paul Davis paul.joseph.da...@gmail.comwrote:

 On Thu, Oct 20, 2011 at 1:38 AM, Randall Leeds rand...@apache.org wrote:
  On Wed, Oct 19, 2011 at 23:38, J. Lee Coltrane 
 l...@projectmastermind.comwrote:
 
 
   For what it's worth, a CLI based test system is what I was imagining
   as well. Take Futon out of the mix and test CouchDB.
 
  IMO, If CouchDB is intended to be a server that can be accessed from
  the browser directly, then there should continue to be some kind of
  browser-based test suite that would serve to confirm this capability.
 
 
  I have been looking closely at the Futon tests in 1.1.0 for the last
  several days, with the idea that I might begin to clean them up a bit
  as time permits.
 
  I have found that, while some of these test failures are totally bogus,
  *some* of them actually do stem from real issues -- minor
  incompatibilities between CouchDB's http interface, and the internal
  mechanisms of modern browsers (XHR, caching, etc).
 
  These are problems that we're not going to catch with a stateless,
  cache-less http client running on the CLI.  (I can provide examples)
 
  These issues have the potential to cause real problems for
  developers of real browser-based apps in the wild.  That means,
  there's valuable info to be gathered from the browser tests, Iff we
  can clean them up, and make them behave consistently; so that
  when they fail or succeed, we can actually trust the results.
 
 
  After digging around a good bit, I can see no reason why the existing
  tests couldn't be cleaned up and made to work correctly in all current
  versions of major browsers.  I also see no reason why the same tests
  couldn't be used successfully from the CLI and `make check` as well.
 
  I do see significant benefits to using the same javascript test code in
  all environments we test.
 
  -Lee
  (irc: coltr)
 
 
   +1
  Verify Installation could grow into a suite of browser/futon tests that
  verify that futon (and apps in general) work, including interactions with
  proxies and the like.

 Sure. Client tests that test the client are fine.

  The test suite for developers should run cleanly from the CLI as part of
  make check, but continue to be exposed in futon. We should work to be
 sure
  they function as well as possible, for the reasons you provide.
 

 Blargh no. Server tests should be testing the server. The entire point
 of moving to the command line is so that we don't have to maintain the
 Futon test suite. Just look at the 1.1.1 thread (or damn near any
 release thread) and the wildly varying reports of test output. The
 situation is just a waste of time for everyone involved.

  I think the JS testing situation is a great place for people to jump in
 and
  help out, especially with the browser environment diversity.
 

 Sure, but I don't see what this has to do with browsers.


People who aren't into the internals can help to fix the suite to work in
different browser environments. That's all I meant.

I suggested that the CLI tests be exposed in Futon because I think there are
probably some JS heads in this community who wouldn't have too much trouble
fixing a lot of the user agent related issues in the test suite. I didn't
mean to suggest that it should continue to be part of the release procedure
(it shouldn't) or that we should feel 100% obligated to make sure they pass
in 100% of environments (we can't and shouldn't), but J. Lee's point about
how keeping such tests around can sometimes expose interesting problems we
wouldn't otherwise see, possible outside the CouchDB codebase even, is
worthwhile.

-Randall

Re: [VOTE] Apache CouchDB 1.1.1 Release, Round 2

2011-10-20 Thread Randall Leeds

On Thu, Oct 20, 2011 at 13:44, Robert Newson rnew...@apache.org wrote:

 This is the second release vote for Apache CouchDB 1.1.1

 Changes since round 1;

 * Fix object sealing with SpiderMonkey 1.7.0
 * Update CHANGES/NEWS to reflect COUCHDB-1129
 * Fix JavaScript CLI test runner

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Test ALL the things.

 B.


Hey, so that was smooth.
Everything passes, first time around, with no problems.
+1

[jira] [Commented] (COUCHDB-1309) File descriptor leaks on design document update and view cleanup

2011-10-20 Thread Paul Joseph Davis (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131954#comment-13131954
 ] 

Paul Joseph Davis commented on COUCHDB-1309:


I've been thinking about this and it occurs to me that adding the new function 
to the index seems like the wrong way to go about this. Seems to me that 
couch_index_server and couch_index should take care of all of this without 
requiring each index to reimplement this simple code. I'll take a quick pass 
through later to try and sketch out what i mean.

 File descriptor leaks on design document update and view cleanup
 

 Key: COUCHDB-1309
 URL: https://issues.apache.org/jira/browse/COUCHDB-1309
 Project: CouchDB
  Issue Type: Bug
Reporter: Filipe Manana
Assignee: Filipe Manana
 Attachments: couchdb-1309_12x.patch, couchdb-1309_trunk.patch


 If we add a design document with views defined in it, open the corresponding 
 view group (by querying one of its views for e.g.), then update the design 
 document in such a way that the view signature changes (changing a view's map 
 function code for e.g), the old view group remains open forever (unless a 
 server restart happens) and keeps it's view file reference counter active 
 forever.
 If a view cleanup request comes, the old view file is not deleted since the 
 reference counter is not dropped by the old view group, keeping the file 
 descriptor in use forever.
 This leakage is different from what is reported in COUCHDB-1129 but it's 
 somehow related.
 The attached patch, simply shutdowns a view group when the design document is 
 updated and the new view signature changes, releasing the old view file 
 descriptor (as soon as no more clients are using the old view).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)

On Thu, Oct 20, 2011 at 1:45 PM, Randall Leeds randall.le...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 13:42, Paul Davis paul.joseph.da...@gmail.comwrote:

 On Thu, Oct 20, 2011 at 1:38 AM, Randall Leeds rand...@apache.org wrote:
  On Wed, Oct 19, 2011 at 23:38, J. Lee Coltrane 
 l...@projectmastermind.comwrote:
 
 
   For what it's worth, a CLI based test system is what I was imagining
   as well. Take Futon out of the mix and test CouchDB.
 
  IMO, If CouchDB is intended to be a server that can be accessed from
  the browser directly, then there should continue to be some kind of
  browser-based test suite that would serve to confirm this capability.
 
 
  I have been looking closely at the Futon tests in 1.1.0 for the last
  several days, with the idea that I might begin to clean them up a bit
  as time permits.
 
  I have found that, while some of these test failures are totally bogus,
  *some* of them actually do stem from real issues -- minor
  incompatibilities between CouchDB's http interface, and the internal
  mechanisms of modern browsers (XHR, caching, etc).
 
  These are problems that we're not going to catch with a stateless,
  cache-less http client running on the CLI.  (I can provide examples)
 
  These issues have the potential to cause real problems for
  developers of real browser-based apps in the wild.  That means,
  there's valuable info to be gathered from the browser tests, Iff we
  can clean them up, and make them behave consistently; so that
  when they fail or succeed, we can actually trust the results.
 
 
  After digging around a good bit, I can see no reason why the existing
  tests couldn't be cleaned up and made to work correctly in all current
  versions of major browsers.  I also see no reason why the same tests
  couldn't be used successfully from the CLI and `make check` as well.
 
  I do see significant benefits to using the same javascript test code in
  all environments we test.
 
  -Lee
  (irc: coltr)
 
 
   +1
  Verify Installation could grow into a suite of browser/futon tests that
  verify that futon (and apps in general) work, including interactions with
  proxies and the like.

 Sure. Client tests that test the client are fine.

  The test suite for developers should run cleanly from the CLI as part of
  make check, but continue to be exposed in futon. We should work to be
 sure
  they function as well as possible, for the reasons you provide.
 

 Blargh no. Server tests should be testing the server. The entire point
 of moving to the command line is so that we don't have to maintain the
 Futon test suite. Just look at the 1.1.1 thread (or damn near any
 release thread) and the wildly varying reports of test output. The
 situation is just a waste of time for everyone involved.

  I think the JS testing situation is a great place for people to jump in
 and
  help out, especially with the browser environment diversity.
 

 Sure, but I don't see what this has to do with browsers.


 People who aren't into the internals can help to fix the suite to work in
 different browser environments. That's all I meant.


Seeing as I'm having a Negative Nancy day, I'll just ask rhetorically,
If these people exist, why do I not see anything in JIRA?

 I suggested that the CLI tests be exposed in Futon because I think there are
 probably some JS heads in this community who wouldn't have too much trouble
 fixing a lot of the user agent related issues in the test suite. I didn't
 mean to suggest that it should continue to be part of the release procedure
 (it shouldn't) or that we should feel 100% obligated to make sure they pass
 in 100% of environments (we can't and shouldn't), but J. Lee's point about
 how keeping such tests around can sometimes expose interesting problems we
 wouldn't otherwise see, possible outside the CouchDB codebase even, is
 worthwhile.

 -Randall


We've had these tests for three years or more now. Perhaps I'm just
being dense today but I can't think of a single specific case where
testing things in the browser has lead to a bug report/fix that we
wouldn't have found with pure CLI tests.

The only thing that I'm aware that the tests have done for us is
required us to exert a nontrivial amount of effort to keep them
running in multiple browser environments. I have no interest in
maintaing these as tests runnable in the browser. I want to create a
CLI test environment that promotes stable, repeatable, concise tests.
Running these in a browser is the antithesis to such an environment.

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)

I'll also note that the bug that killed round 1 of 1.1.1 was not found
by any test we currently have. All it would have taken is a test that
did any map call followed by almost any other bit of javascript (and
sm 1.7.0).

On 20 October 2011 21:22, Paul Davis paul.joseph.da...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 1:45 PM, Randall Leeds randall.le...@gmail.com 
 wrote:
 On Thu, Oct 20, 2011 at 13:42, Paul Davis paul.joseph.da...@gmail.comwrote:

 On Thu, Oct 20, 2011 at 1:38 AM, Randall Leeds rand...@apache.org wrote:
  On Wed, Oct 19, 2011 at 23:38, J. Lee Coltrane 
 l...@projectmastermind.comwrote:
 
 
   For what it's worth, a CLI based test system is what I was imagining
   as well. Take Futon out of the mix and test CouchDB.
 
  IMO, If CouchDB is intended to be a server that can be accessed from
  the browser directly, then there should continue to be some kind of
  browser-based test suite that would serve to confirm this capability.
 
 
  I have been looking closely at the Futon tests in 1.1.0 for the last
  several days, with the idea that I might begin to clean them up a bit
  as time permits.
 
  I have found that, while some of these test failures are totally bogus,
  *some* of them actually do stem from real issues -- minor
  incompatibilities between CouchDB's http interface, and the internal
  mechanisms of modern browsers (XHR, caching, etc).
 
  These are problems that we're not going to catch with a stateless,
  cache-less http client running on the CLI.  (I can provide examples)
 
  These issues have the potential to cause real problems for
  developers of real browser-based apps in the wild.  That means,
  there's valuable info to be gathered from the browser tests, Iff we
  can clean them up, and make them behave consistently; so that
  when they fail or succeed, we can actually trust the results.
 
 
  After digging around a good bit, I can see no reason why the existing
  tests couldn't be cleaned up and made to work correctly in all current
  versions of major browsers.  I also see no reason why the same tests
  couldn't be used successfully from the CLI and `make check` as well.
 
  I do see significant benefits to using the same javascript test code in
  all environments we test.
 
  -Lee
  (irc: coltr)
 
 
   +1
  Verify Installation could grow into a suite of browser/futon tests that
  verify that futon (and apps in general) work, including interactions with
  proxies and the like.

 Sure. Client tests that test the client are fine.

  The test suite for developers should run cleanly from the CLI as part of
  make check, but continue to be exposed in futon. We should work to be
 sure
  they function as well as possible, for the reasons you provide.
 

 Blargh no. Server tests should be testing the server. The entire point
 of moving to the command line is so that we don't have to maintain the
 Futon test suite. Just look at the 1.1.1 thread (or damn near any
 release thread) and the wildly varying reports of test output. The
 situation is just a waste of time for everyone involved.

  I think the JS testing situation is a great place for people to jump in
 and
  help out, especially with the browser environment diversity.
 

 Sure, but I don't see what this has to do with browsers.


 People who aren't into the internals can help to fix the suite to work in
 different browser environments. That's all I meant.


 Seeing as I'm having a Negative Nancy day, I'll just ask rhetorically,
 If these people exist, why do I not see anything in JIRA?

 I suggested that the CLI tests be exposed in Futon because I think there are
 probably some JS heads in this community who wouldn't have too much trouble
 fixing a lot of the user agent related issues in the test suite. I didn't
 mean to suggest that it should continue to be part of the release procedure
 (it shouldn't) or that we should feel 100% obligated to make sure they pass
 in 100% of environments (we can't and shouldn't), but J. Lee's point about
 how keeping such tests around can sometimes expose interesting problems we
 wouldn't otherwise see, possible outside the CouchDB codebase even, is
 worthwhile.

 -Randall


 We've had these tests for three years or more now. Perhaps I'm just
 being dense today but I can't think of a single specific case where
 testing things in the browser has lead to a bug report/fix that we
 wouldn't have found with pure CLI tests.

 The only thing that I'm aware that the tests have done for us is
 required us to exert a nontrivial amount of effort to keep them
 running in multiple browser environments. I have no interest in
 maintaing these as tests runnable in the browser. I want to create a
 CLI test environment that promotes stable, repeatable, concise tests.
 Running these in a browser is the antithesis to such an environment.

Re: [VOTE] Apache CouchDB 1.1.1 Release

2011-10-20 Thread Klaus Trainer

-1


On Thu, 2011-10-20 at 18:57 +0100, Robert Newson wrote:
 Too late.
 
 I'm inclined to work with Paul Davis and make 1.1.1 the last time that
 there *is* a Futon test suite.
 
 B.
 
 On 20 October 2011 18:54, J. Lee Coltrane l...@projectmastermind.com wrote:
 
  FWIW, the patch attached to COUCHDB-1310
   (https://issues.apache.org/jira/browse/COUCHDB-1310)
 
  will fix a great many (all, afaik) of the futon test hangs (the cases 
  where
  the tests get stuck, and never complete).  Without this patch, I was
  never able to get a complete run through the browser tests in 1.1.1 RC1.
  With the patch, I still get test failures, but at least I can get through 
  all the
  tests without restarting the browser.
 
  The patch is tiny -- it just swaps the order of two lines of code, in the
  '/_restart' handler, so that the http response gets written *before* the 
  server
  is restarted (rather than after).
 
  As test instability continues to be a hot topic, maybe this patch is worth
  considering for inclusion in the next 1.1.1 RC?
 
  -Lee
 
 
 
  On Oct 20, 2011, at 12:25 PM, Benoit Chesneau wrote:
 
  On Thu, Oct 20, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote:
  Hi All,
 
  Thanks for all the responses so far. Unfortunately I am aborting this 
  round.
 
  It turns out there is a serious bug in this 1.1.1 candidate when using
  SpiderMonkey 1.7.0. Instead of sealing the 'doc' parameter to views,
  we seal the object that defines the seal function, which then causes
  all kinds of 'X is read-only' events.
 
  It's a one word fix, so a new 1.1.1 candidate will be out very soon,
  and it should not invalidate any of these results.
 
  B.
 
 
  :(
 
  It would worth to look at this erlang warning too imo. Hopefully i
  will have some wifi at the hotel tonight.I will see if I can make it.
 
  - benoit
 
 



signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Apache CouchDB 1.1.1 Release, Round 2

2011-10-20 Thread Sam Bisbee

+1

Everything worked great. Wasn't able to check the pgp key because my
gpg client is acting up at the moment.

Cheers,

--
Sam Bisbee

On Thu, Oct 20, 2011 at 1:44 PM, Robert Newson rnew...@apache.org wrote:
 This is the second release vote for Apache CouchDB 1.1.1

 Changes since round 1;

 * Fix object sealing with SpiderMonkey 1.7.0
 * Update CHANGES/NEWS to reflect COUCHDB-1129
 * Fix JavaScript CLI test runner

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Test ALL the things.

 B.

Re: [VOTE] Apache CouchDB 1.1.1 Release

2011-10-20 Thread Klaus Trainer

Hehe, given the fact that the voting round has been aborted, I thought
it would be clear that it relates to your most recent reply ;)

Sorry, I've missed that the respective thread for that topic (i.e.,
futon tests) had grown meanwhile. I should have better replied on that
one.

- K


On Thu, 2011-10-20 at 21:38 +0100, Robert Newson wrote:
 What is that -1 related to?
 
 On 20 October 2011 21:36, Klaus Trainer klaus_trai...@posteo.de wrote:
  -1
 
 
  On Thu, 2011-10-20 at 18:57 +0100, Robert Newson wrote:
  Too late.
 
  I'm inclined to work with Paul Davis and make 1.1.1 the last time that
  there *is* a Futon test suite.
 
  B.
 
  On 20 October 2011 18:54, J. Lee Coltrane l...@projectmastermind.com 
  wrote:
  
   FWIW, the patch attached to COUCHDB-1310
(https://issues.apache.org/jira/browse/COUCHDB-1310)
  
   will fix a great many (all, afaik) of the futon test hangs (the cases 
   where
   the tests get stuck, and never complete).  Without this patch, I was
   never able to get a complete run through the browser tests in 1.1.1 RC1.
   With the patch, I still get test failures, but at least I can get 
   through all the
   tests without restarting the browser.
  
   The patch is tiny -- it just swaps the order of two lines of code, in the
   '/_restart' handler, so that the http response gets written *before* the 
   server
   is restarted (rather than after).
  
   As test instability continues to be a hot topic, maybe this patch is 
   worth
   considering for inclusion in the next 1.1.1 RC?
  
   -Lee
  
  
  
   On Oct 20, 2011, at 12:25 PM, Benoit Chesneau wrote:
  
   On Thu, Oct 20, 2011 at 6:23 PM, Robert Newson rnew...@apache.org 
   wrote:
   Hi All,
  
   Thanks for all the responses so far. Unfortunately I am aborting this 
   round.
  
   It turns out there is a serious bug in this 1.1.1 candidate when using
   SpiderMonkey 1.7.0. Instead of sealing the 'doc' parameter to views,
   we seal the object that defines the seal function, which then causes
   all kinds of 'X is read-only' events.
  
   It's a one word fix, so a new 1.1.1 candidate will be out very soon,
   and it should not invalidate any of these results.
  
   B.
  
  
   :(
  
   It would worth to look at this erlang warning too imo. Hopefully i
   will have some wifi at the hotel tonight.I will see if I can make it.
  
   - benoit
  
  
 
 



signature.asc
Description: This is a digitally signed message part

[jira] [Created] (COUCHDB-1314) Couchdb _replicator documents should not show passwords in clear text

2011-10-20 Thread Dario Freire (Created) (JIRA)

Couchdb _replicator documents should not show passwords in clear text
-

 Key: COUCHDB-1314
 URL: https://issues.apache.org/jira/browse/COUCHDB-1314
 Project: CouchDB
  Issue Type: Improvement
  Components: Replication
Affects Versions: 1.1
Reporter: Dario Freire
Priority: Critical


The documents stored in the _replicator database show passwords in clear text.

Imagine a scenario where a developer provides a couchdb app that runs in a 
central location and must synchronize with user's local couchdb instances.
The users would need to pull updates to their database by adding a document to 
_replicator:

{
_id: great-app,
source:  http://great-app-provider.com:5984/great-app;,
target:  my-great-app,
create_target:  true
}

Now if the developer doesn't want his central couchdb instance to be public, he 
needs to protect it by creating an admin party.
The problem is that he cannot longer share his database for replication because 
doing so would reveal the admin credentials to the app users.
i.e. in order for the synchronization to work the users would need to update 
their _replicator documents to:

{
_id: great-app,
source:  http://admin:passw...@great-app-provider.com:5984/great-app;,
target:  my-great-app,
create_target:  true
}

All in plain text.
Thus, the users would know how to access the restricted central couchdb 
instance.

This is just a possible scenario where showing credentials in plain text is a 
problem, but by no means is the only scenario where it is a problem.

Since one of the selling points of couchdb is its outstanding ability to 
synchronize databases, the security concerns caused by this issue make it 
impossible to use in practice. 
Because of this, it looks like an improvement on this matter is of critical 
importance.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (COUCHDB-860) Futon appends wrong version number to files

2011-10-20 Thread Randall Leeds (Assigned) (JIRA)


 [ 
https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randall Leeds reassigned COUCHDB-860:
-

Assignee: Randall Leeds

 Futon appends wrong version number to files
 ---

 Key: COUCHDB-860
 URL: https://issues.apache.org/jira/browse/COUCHDB-860
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 1.0.1
Reporter: Volker Mische
Assignee: Randall Leeds
Priority: Minor
 Attachments: 
 0001-remove-version-number-from-futon-static-resources.patch, 
 0002-Futon-Cache-Control.patch


 Futon appends the CouchDB version number to the JavaScript files it loads. In 
 1.0.1 it still appends 0.11

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COUCHDB-860) Futon appends wrong version number to files

2011-10-20 Thread Randall Leeds (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randall Leeds updated COUCHDB-860:
--

Attachment: 0002-Futon-Cache-Control.patch
0001-remove-version-number-from-futon-static-resources.patch

Here are two patches. First one removes the version number. Second one serves 
futon resources with cache-control headers to help prevent issues with futon 
caching.

Does this look right?

 Futon appends wrong version number to files
 ---

 Key: COUCHDB-860
 URL: https://issues.apache.org/jira/browse/COUCHDB-860
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 1.0.1
Reporter: Volker Mische
Priority: Minor
 Attachments: 
 0001-remove-version-number-from-futon-static-resources.patch, 
 0002-Futon-Cache-Control.patch


 Futon appends the CouchDB version number to the JavaScript files it loads. In 
 1.0.1 it still appends 0.11

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-860) Futon appends wrong version number to files

2011-10-20 Thread Paul Joseph Davis (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132144#comment-13132144
 ] 

Paul Joseph Davis commented on COUCHDB-860:
---

No, that busts cache on everything served from the utils directory. What you 
want to do is to generate the files that reference the version with Autotools.

 Futon appends wrong version number to files
 ---

 Key: COUCHDB-860
 URL: https://issues.apache.org/jira/browse/COUCHDB-860
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 1.0.1
Reporter: Volker Mische
Assignee: Randall Leeds
Priority: Minor
 Attachments: 
 0001-remove-version-number-from-futon-static-resources.patch, 
 0002-Futon-Cache-Control.patch


 Futon appends the CouchDB version number to the JavaScript files it loads. In 
 1.0.1 it still appends 0.11

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-860) Futon appends wrong version number to files

2011-10-20 Thread Randall Leeds (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132171#comment-13132171
 ] 

Randall Leeds commented on COUCHDB-860:
---

Not true. It asks that clients revalidate. The mochiweb_request:serve_file call 
we use provides the last-modified header from the file mtime. Clients 
interested in caching should provide if-modified-since and mochiweb will 
properly handles the 304 in this case: 
https://github.com/mochi/mochiweb/blob/master/src/mochiweb_request.erl#L598. I 
like that much more than having autotools generate all these files.

 Futon appends wrong version number to files
 ---

 Key: COUCHDB-860
 URL: https://issues.apache.org/jira/browse/COUCHDB-860
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 1.0.1
Reporter: Volker Mische
Assignee: Randall Leeds
Priority: Minor
 Attachments: 
 0001-remove-version-number-from-futon-static-resources.patch, 
 0002-Futon-Cache-Control.patch


 Futon appends the CouchDB version number to the JavaScript files it loads. In 
 1.0.1 it still appends 0.11

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-860) Futon appends wrong version number to files

2011-10-20 Thread Paul Joseph Davis (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132196#comment-13132196
 ] 

Paul Joseph Davis commented on COUCHDB-860:
---

Hrm, seems like something that we should reasonably expect. But its browsers, 
so I'd double check that its still conditional. If so, then I'm fine with that 
approach.

 Futon appends wrong version number to files
 ---

 Key: COUCHDB-860
 URL: https://issues.apache.org/jira/browse/COUCHDB-860
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 1.0.1
Reporter: Volker Mische
Assignee: Randall Leeds
Priority: Minor
 Attachments: 
 0001-remove-version-number-from-futon-static-resources.patch, 
 0002-Futon-Cache-Control.patch


 Futon appends the CouchDB version number to the JavaScript files it loads. In 
 1.0.1 it still appends 0.11

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Thu, Oct 20, 2011 at 2:28 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Oct 20, 2011 at 3:17 PM, Filipe David Manana
 fdman...@apache.org wrote:
 On Thu, Oct 20, 2011 at 2:12 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Wed, Oct 19, 2011 at 4:27 PM, Robert Newson rnew...@apache.org wrote:
 This is the release vote for Apache CouchDB 1.1.1

 Changes in this release:

 * Support SpiderMonkey 1.8.5
 * Add configurable maximum to the number of bytes returned by _log.
 * Allow CommonJS modules to be an empty string.
 * Bump minimum Erlang version to R13B02.
 * Do not run deleted validate_doc_update functions.
 * ETags for views include current sequence if include_docs=true.
 * Fix bug where duplicates can appear in _changes feed.
 * Fix bug where update handlers break after conflict resolution.
 * Fix bug with _replicator where include filter could crash couch.
 * Fix crashes when compacting large views.
 * Fix file descriptor leak in _log
 * Fix missing revisions in _changes?style=all_docs.
 * Improve handling of compaction at max_dbs_open limit.
 * JSONP responses now send text/javascript for Content-Type.
 * Link to ICU 4.2 on Windows.
 * Permit forward slashes in path to update functions.
 * Reap couchjs processes that hit reduce_overflow error.
 * Status code can be specified in update handlers.
 * Support provides() in show functions.
 * _view_cleanup when ddoc has no views now removes all index files.
 * max_replication_retry_count now supports infinity.
 * Fix replication crash when source database has a document with empty ID.
 * Fix deadlock when assigning couchjs processes to serve requests.
 * Fixes to the document multipart PUT API.

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Since you have read this far, you MUST vote.


 make check pass, but when running js tests I got the following error
 (reproducible from time to time) :

 [info] [0.1915.0] Stopping all ongoing replications because the
 replicator database was deleted or changed
 Apache CouchDB 1.1.1 (LogLevel=info) is starting.
 Segmentation fault: 11

 configuration : rb1404, osx lion (last update)

 That's likely the OpenSSL issue on Lion. If init:restart/0 is invoked
 and the crypto application was loaded (CouchDB's case) the VM crashes
 with either a bus error, segmentation fault or no error message at
 all.

 Have you tried building OTP like in https://gist.github.com/1199903 ?

 I had exactly the same issue.


 - benoit


 Shouldn't it be fixed in r144b04? \

Nop, not fixed in r14b04 unfortunately.
And it's independent of the couch codebase, since all start the crypto
application.

 ALso I don't reproduce it at all on
 refuge when running tests, s it may be due to the way we compile
 couch.

 - benoit

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)

+1 on all the stuff Paul said.

On Thu, Oct 20, 2011 at 9:25 PM, Robert Newson rnew...@apache.org wrote:

 I'll also note that the bug that killed round 1 of 1.1.1 was not found
 by any test we currently have. All it would have taken is a test that
 did any map call followed by almost any other bit of javascript (and
 sm 1.7.0).

 On 20 October 2011 21:22, Paul Davis paul.joseph.da...@gmail.com wrote:
  On Thu, Oct 20, 2011 at 1:45 PM, Randall Leeds randall.le...@gmail.com
 wrote:
  On Thu, Oct 20, 2011 at 13:42, Paul Davis paul.joseph.da...@gmail.com
 wrote:
 
  On Thu, Oct 20, 2011 at 1:38 AM, Randall Leeds rand...@apache.org
 wrote:
   On Wed, Oct 19, 2011 at 23:38, J. Lee Coltrane 
  l...@projectmastermind.comwrote:
  
  
For what it's worth, a CLI based test system is what I was
 imagining
as well. Take Futon out of the mix and test CouchDB.
  
   IMO, If CouchDB is intended to be a server that can be accessed from
   the browser directly, then there should continue to be some kind of
   browser-based test suite that would serve to confirm this
 capability.
  
  
   I have been looking closely at the Futon tests in 1.1.0 for the last
   several days, with the idea that I might begin to clean them up a
 bit
   as time permits.
  
   I have found that, while some of these test failures are totally
 bogus,
   *some* of them actually do stem from real issues -- minor
   incompatibilities between CouchDB's http interface, and the internal
   mechanisms of modern browsers (XHR, caching, etc).
  
   These are problems that we're not going to catch with a stateless,
   cache-less http client running on the CLI.  (I can provide examples)
  
   These issues have the potential to cause real problems for
   developers of real browser-based apps in the wild.  That means,
   there's valuable info to be gathered from the browser tests, Iff we
   can clean them up, and make them behave consistently; so that
   when they fail or succeed, we can actually trust the results.
  
  
   After digging around a good bit, I can see no reason why the
 existing
   tests couldn't be cleaned up and made to work correctly in all
 current
   versions of major browsers.  I also see no reason why the same tests
   couldn't be used successfully from the CLI and `make check` as well.
  
   I do see significant benefits to using the same javascript test code
 in
   all environments we test.
  
   -Lee
   (irc: coltr)
  
  
+1
   Verify Installation could grow into a suite of browser/futon tests
 that
   verify that futon (and apps in general) work, including interactions
 with
   proxies and the like.
 
  Sure. Client tests that test the client are fine.
 
   The test suite for developers should run cleanly from the CLI as part
 of
   make check, but continue to be exposed in futon. We should work to be
  sure
   they function as well as possible, for the reasons you provide.
  
 
  Blargh no. Server tests should be testing the server. The entire point
  of moving to the command line is so that we don't have to maintain the
  Futon test suite. Just look at the 1.1.1 thread (or damn near any
  release thread) and the wildly varying reports of test output. The
  situation is just a waste of time for everyone involved.
 
   I think the JS testing situation is a great place for people to jump
 in
  and
   help out, especially with the browser environment diversity.
  
 
  Sure, but I don't see what this has to do with browsers.
 
 
  People who aren't into the internals can help to fix the suite to work
 in
  different browser environments. That's all I meant.
 
 
  Seeing as I'm having a Negative Nancy day, I'll just ask rhetorically,
  If these people exist, why do I not see anything in JIRA?
 
  I suggested that the CLI tests be exposed in Futon because I think there
 are
  probably some JS heads in this community who wouldn't have too much
 trouble
  fixing a lot of the user agent related issues in the test suite. I
 didn't
  mean to suggest that it should continue to be part of the release
 procedure
  (it shouldn't) or that we should feel 100% obligated to make sure they
 pass
  in 100% of environments (we can't and shouldn't), but J. Lee's point
 about
  how keeping such tests around can sometimes expose interesting problems
 we
  wouldn't otherwise see, possible outside the CouchDB codebase even, is
  worthwhile.
 
  -Randall
 
 
  We've had these tests for three years or more now. Perhaps I'm just
  being dense today but I can't think of a single specific case where
  testing things in the browser has lead to a bug report/fix that we
  wouldn't have found with pure CLI tests.
 
  The only thing that I'm aware that the tests have done for us is
  required us to exert a nontrivial amount of effort to keep them
  running in multiple browser environments. I have no interest in
  maintaing these as tests runnable in the browser. I want to create a
  CLI test environment that promotes stable, repeatable, concise tests.

Re: [VOTE] Apache CouchDB 1.1.1 Release

On Thu, Oct 20, 2011 at 6:57 PM, Robert Newson rnew...@apache.org wrote:

 Too late.

 I'm inclined to work with Paul Davis and make 1.1.1 the last time that
 there *is* a Futon test suite.


:D

Re: [VOTE] Apache CouchDB 1.1.1 Release, Round 2

Can someone provide assistance on the new Test procedure please:

http://mail-archives.apache.org/mod_mbox/couchdb-dev/201110.mbox/%3CCA+Y+447FXqVGx8ow=ewqm86cn9epb1cnbmvhk9ku4ogujby...@mail.gmail.com%3E

I am not sure how best to update the workflow for Git.

This is important. *waves hands*

On Thu, Oct 20, 2011 at 6:44 PM, Robert Newson rnew...@apache.org wrote:

 This is the second release vote for Apache CouchDB 1.1.1

 Changes since round 1;

 * Fix object sealing with SpiderMonkey 1.7.0
 * Update CHANGES/NEWS to reflect COUCHDB-1129
 * Fix JavaScript CLI test runner

 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. Please report your
 results and vote to this thread.

 We are voting on the following release artifacts:

  http://people.apache.org/~rnewson/dist/1.1.1/

 Instructions for validating the release tarball can be found here:

  http://people.apache.org/~rnewson/dist/

 Instructions for testing the build artefacts can be found here:

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

 These artifacts have been built from the 1.1.1 tag in Git:

 apache-couchdb-1.1.1.tar.gz
 apache-couchdb-1.1.1.tar.gz.md5
 apache-couchdb-1.1.1.tar.gz.asc
 apache-couchdb-1.1.1.tar.gz.sha

 Test ALL the things.

 B.

Locking down the wiki

Hey,

On advice from Gavin McDonald, I'd like to suggest that we lock down the
wiki to a list of pre-approved users. To get approved to make edits, you
would submit a request to one of the mailing lists or to one of the wiki
admins or committers. That's it. It should remove the need to protect pages
like the in the wild stuff and the people on the couch. Other projects
have implemented this and they get absolutely no spam as a result.
Infrastructure suggested we move to it, and I wanna see what people think
about it.

More info here:

http://wiki.apache.org/general/OurWikiFarm


Look for the section:

per wiki access control - tighten your wiki just a little, benefit just a
lot


Thanks,

N

Re: Locking down the wiki

2011-10-20 Thread Adam Kocoloski

Thanks for looking into it Noah.  I don't have a problem with locking it down 
as you suggest.  Maybe we can seed the pre-approved list with the list of users 
who have made non-spam edits already?

Adam

On Oct 20, 2011, at 8:26 PM, Noah Slater wrote:

 Hey,
 
 On advice from Gavin McDonald, I'd like to suggest that we lock down the
 wiki to a list of pre-approved users. To get approved to make edits, you
 would submit a request to one of the mailing lists or to one of the wiki
 admins or committers. That's it. It should remove the need to protect pages
 like the in the wild stuff and the people on the couch. Other projects
 have implemented this and they get absolutely no spam as a result.
 Infrastructure suggested we move to it, and I wanna see what people think
 about it.
 
 More info here:
 
 http://wiki.apache.org/general/OurWikiFarm
 
 
 Look for the section:
 
 per wiki access control - tighten your wiki just a little, benefit just a
 lot
 
 
 Thanks,
 
 N

Re: Tweaking the release procedure

2011-10-20 Thread Dustin Sallings


On Oct 20, 2011, at 10:51 AM, Paul Davis wrote:

 Yes, the path prefixes (path probably was a bard word in my original
 email) exists merely as a way to distinguish between these are
 official releases and are immutable and the this is a temporary tag
 that I can fix if I screw up.

Branches really make the best temporary tags.

 I'm trying to consider all the cases here (in the context of my OCD).
 Do we necessarily care about the rc tags once a release has been made?
 In a perfect world I would expect one tag per release and everything
 would be neat and tidy. If so, then we need to be able to remove old
 tags once they have been usurped by actual releases.

I've always considered anything I give out to be a release.  This 
includes betas and RCs and anything else.

 Consider it from the POV of a user as well. If you have 5-10 tags for
 a release (not out of the question) then each user looking for that
 release has to spend time figuring out which is the right tag. Which
 means that either our naming conventions have to be extremely clear
 (even then I've seen enough to know that we'll still get questions) or
 we need to have procedure to narrow down the set of tags once the
 release is made. I prefer procedure because it will minimize the
 number of times in the future that i have to spend time debugging the
 fact that someone downloaded 1.1.1-rc1 instead of 1.1.1 which has that
 bug related to SpiderMonkey 1.7 and sealing.

This is why semver suggests version and tag naming conventions.  
There's just no confusion if the version number and the tag number match.

In the above example, if someone downloaded and is currently running 
1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and 
v1.1.1-rc2, why would be confused?  More importantly, you released that, so why 
would you not want the user to be able to see whether any changes between 
1.1.1-rc1 and 1.1.1 final affect his deployment?

The git git repo has 366 tags right now.  In addition to releases from 
a subproject that spun out, there are 337 tags representing releases (and RCs) 
that shipped.  It captures a wonderful release history of the project.

These are the tags since (and including) the version I'm running:

v1.7.4.4Git 1.7.4.4
v1.7.4.5Git 1.7.4.5
v1.7.5  Git 1.7.5
v1.7.5-rc0  Git 1.7.5-rc0
v1.7.5-rc1  Git 1.7.5-rc1
v1.7.5-rc2  Git 1.7.5-rc2
v1.7.5-rc3  Git 1.7.5-rc3
v1.7.5.1Git 1.7.5.1
v1.7.5.2Git 1.7.5.2
v1.7.5.3Git 1.7.5.3
v1.7.5.4Git 1.7.5.4
v1.7.6  Git 1.7.6
v1.7.6-rc0  Git 1.7.6-rc0
v1.7.6-rc1  Git 1.7.6-rc1
v1.7.6-rc2  Git 1.7.6-rc2
v1.7.6-rc3  Git 1.7.6-rc3
v1.7.6.1Git 1.7.6.1
v1.7.7-rc0  Git 1.7.7-rc0

I very well may be biased, but I don't find that confusing.

-- 
dustin sallings

Re: Tweaking the release procedure

On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings dus...@spy.net wrote:

I've always considered anything I give out to be a release.  This includes
 betas and RCs and anything else.


It's important to clear up that this is NOT the case for Apache projects. A
release is a set of artefacts that have been successfully voted on by the
community and then released according to our official release procedure.
Anything else, including the artefacts we vote on that don't make the cut,
are not considered releases. And this isn't just a choice of wording either,
it's a very important distinction.

Anyone can prepare an artefact and put it up for the vote, but only
artefacts that pass the muster are considered releases. The term release
candidate is not an official term, and it is not defined in the ASF
literature or as part of the release process. It's probably a bad choice of
words too, as in other projects, a release candidate IS a sort of release
that is made by the project. We don't do that here.

Hope this clears things up!

Re: Tweaking the release procedure

On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings dus...@spy.net wrote:

v1.7.4.4Git 1.7.4.4
 v1.7.4.5Git 1.7.4.5
 v1.7.5  Git 1.7.5
 v1.7.5-rc0  Git 1.7.5-rc0
 v1.7.5-rc1  Git 1.7.5-rc1
 v1.7.5-rc2  Git 1.7.5-rc2
 v1.7.5-rc3  Git 1.7.5-rc3
 v1.7.5.1Git 1.7.5.1
 v1.7.5.2Git 1.7.5.2
 v1.7.5.3Git 1.7.5.3
 v1.7.5.4Git 1.7.5.4
 v1.7.6  Git 1.7.6
 v1.7.6-rc0  Git 1.7.6-rc0
 v1.7.6-rc1  Git 1.7.6-rc1
 v1.7.6-rc2  Git 1.7.6-rc2
 v1.7.6-rc3  Git 1.7.6-rc3
 v1.7.6.1Git 1.7.6.1
 v1.7.7-rc0  Git 1.7.7-rc0

I very well may be biased, but I don't find that confusing.


Oh, and by extension, I will give my -1 vote to any system that mixes these
two together. The release tag for X.Y.Z should be tied to an official
artefact of the Apache CouchDB project. A tag that doesn't pass the vote
should be deleted. The history is in the X.Y.x release branch. It has no
business cluttering up the tags, and no business confusing users about
whether it has been blessed by the project.

Re: Tweaking the release procedure

On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings dus...@spy.net wrote:

In the above example, if someone downloaded and is currently running
 1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and
 v1.1.1-rc2, why would be confused?  More importantly, you released that, so
 why would you not want the user to be able to see whether any changes
 between 1.1.1-rc1 and 1.1.1 final affect his deployment?


If someone has downloaded and is running an artefact from a botched release
vote, our release procedure has failed us catastrophically. Nobody should
EVER be running these as-of-yet-not-approved release artefacts. Except for
testing and voting, obviously. Hence, the only reason you'd want to see what
the changes were between 1.1.1-rc1 and 1.1.1 would be for testing a second
round of voting. Perhaps we should eschew the release candidate
nomenclature if it is causing these problems? I am worried that we might be
sending the wrong message to our users who expect this terminology to mean
something else entirely. Oh, and Sorry about replying in
a piecemeal fashion!

Re: Tweaking the release procedure

2011-10-20 Thread Dustin Sallings


On Oct 20, 2011, at 6:18 PM, Noah Slater wrote:

 The history is in the X.Y.x release branch. It has no
 business cluttering up the tags, and no business confusing users about
 whether it has been blessed by the project.


Does this imply you intend to leave branches open forever even when 
development on them has stopped?

I would say that the history is in the commits that lead up to the tag 
along with the release notes being actually *in* the tag. 

I've seen people keep lots of dead branches around which I find 
considerably more confusing than excessive tags since a branch is a dynamic 
line of development and a tag is a static commit in time.  If you're not 
actively doing development, a branch just makes it look like you might be.

It's trivial (in git at least) to reopen a development branch from any 
previously released version with cryptographically verified certainty that you 
have the correct code that led to that release.


Not that I think you guys don't know what you're doing or anything.  
I'm coming mostly from a user who will be hoping to be using couchdb sources, 
writing extensions, and trying hard to make sure whatever changes I make are 
made available to all couchdb users and developers.  That and I've got a 
ridiculous amount of time spent manipulating git repos.

-- 
dustin sallings

Re: Tweaking the release procedure

As Noah points out, there are ASF procedural issues that affect this
discussion. Part of making a release involves getting community input
on whether the release is a valid artefact. As such we need to be able
to refer to these not-release sets of bytes. Traditionally in SVN we
did this by creating and delting tags. Though SVN's idea of tags is
pretty bad.

The current issue is how do we create general best-practice guidelines
for any ASF project that might be interested in using Git. A naming
scheme along with the specific ASF Git hosting code should be
considered to try and minimize the confusion across a theoretical
couple hundred projects employing a couple thousand committers.

        In the above example, if someone downloaded and is currently running 
 1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and 
 v1.1.1-rc2, why would be confused?  More importantly, you released that, so 
 why would you not want the user to be able to see whether any changes between 
 1.1.1-rc1 and 1.1.1 final affect his deployment?


You're missing my concern. My concern is when someone comes to us and
say's, I'm running 1.1.1 and then I spend a couple hours debugging
that they really meant I'm running 1.1.1-rc1. Anyone that's not
scared of this needs to spend more time debugging bugs in community
IRC channels or mailing lists.

        The git git repo has 366 tags right now.  In addition to releases from 
 a subproject that spun out, there are 337 tags representing releases (and 
 RCs) that shipped.  It captures a wonderful release history of the project.

        These are the tags since (and including) the version I'm running:

 v1.7.4.4        Git 1.7.4.4
 v1.7.4.5        Git 1.7.4.5
 v1.7.5          Git 1.7.5
 v1.7.5-rc0      Git 1.7.5-rc0
 v1.7.5-rc1      Git 1.7.5-rc1
 v1.7.5-rc2      Git 1.7.5-rc2
 v1.7.5-rc3      Git 1.7.5-rc3
 v1.7.5.1        Git 1.7.5.1
 v1.7.5.2        Git 1.7.5.2
 v1.7.5.3        Git 1.7.5.3
 v1.7.5.4        Git 1.7.5.4
 v1.7.6          Git 1.7.6
 v1.7.6-rc0      Git 1.7.6-rc0
 v1.7.6-rc1      Git 1.7.6-rc1
 v1.7.6-rc2      Git 1.7.6-rc2
 v1.7.6-rc3      Git 1.7.6-rc3
 v1.7.6.1        Git 1.7.6.1
 v1.7.7-rc0      Git 1.7.7-rc0

        I very well may be biased, but I don't find that confusing.


Nor do I, but that is absolutely not the way to think about the issue.
Anyone on the dev@ list is pretty much categorically disqualified from
making a decision on what's best here. Of course if you follow such a
list you'll have an idea on what the right release is. But if you're
not involved, or even if you're not involved in dev of anything, its
not inconceivable (I do know what that word means :) to make the
mistake that 1.1.1-rc1 is newer than 1.1.1.

Re: Tweaking the release procedure

On Thu, Oct 20, 2011 at 8:18 PM, Noah Slater nsla...@tumbolia.org wrote:
 On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings dus...@spy.net wrote:

 v1.7.4.4        Git 1.7.4.4
 v1.7.4.5        Git 1.7.4.5
 v1.7.5          Git 1.7.5
 v1.7.5-rc0      Git 1.7.5-rc0
 v1.7.5-rc1      Git 1.7.5-rc1
 v1.7.5-rc2      Git 1.7.5-rc2
 v1.7.5-rc3      Git 1.7.5-rc3
 v1.7.5.1        Git 1.7.5.1
 v1.7.5.2        Git 1.7.5.2
 v1.7.5.3        Git 1.7.5.3
 v1.7.5.4        Git 1.7.5.4
 v1.7.6          Git 1.7.6
 v1.7.6-rc0      Git 1.7.6-rc0
 v1.7.6-rc1      Git 1.7.6-rc1
 v1.7.6-rc2      Git 1.7.6-rc2
 v1.7.6-rc3      Git 1.7.6-rc3
 v1.7.6.1        Git 1.7.6.1
 v1.7.7-rc0      Git 1.7.7-rc0

        I very well may be biased, but I don't find that confusing.


 Oh, and by extension, I will give my -1 vote to any system that mixes these
 two together. The release tag for X.Y.Z should be tied to an official
 artefact of the Apache CouchDB project. A tag that doesn't pass the vote
 should be deleted. The history is in the X.Y.x release branch. It has no
 business cluttering up the tags, and no business confusing users about
 whether it has been blessed by the project.


Hear hear. My thoughts on this were to try and add a simple convention
to enforce this. Merely by prefixing anything with rel/ that would
signal an 'official blessing' on the subject in question. There are
any number of ways to do this, and I'm quite open to hearing
alternatives, but this is exactly what I was aiming at. We need a
procedural/community thing that says these over here are pristine,
these over here are us fucking about.

In my slap dashery I chose the rel/ prefix. There are definitely
other solutions, but I think Noah has hit the nail on the head in
pointing out the underlying need that we should be discussing.

Re: Tweaking the release procedure

On Thu, Oct 20, 2011 at 8:23 PM, Noah Slater nsla...@tumbolia.org wrote:
 On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings dus...@spy.net wrote:

 In the above example, if someone downloaded and is currently running
 1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and
 v1.1.1-rc2, why would be confused?  More importantly, you released that, so
 why would you not want the user to be able to see whether any changes
 between 1.1.1-rc1 and 1.1.1 final affect his deployment?


 If someone has downloaded and is running an artefact from a botched release
 vote, our release procedure has failed us catastrophically. Nobody should
 EVER be running these as-of-yet-not-approved release artefacts. Except for
 testing and voting, obviously. Hence, the only reason you'd want to see what
 the changes were between 1.1.1-rc1 and 1.1.1 would be for testing a second
 round of voting. Perhaps we should eschew the release candidate
 nomenclature if it is causing these problems? I am worried that we might be
 sending the wrong message to our users who expect this terminology to mean
 something else entirely. Oh, and Sorry about replying in
 a piecemeal fashion!


Piecemeal helps us find our way back.

http://en.wikipedia.org/wiki/Hansel_and_Gretel

Re: Tweaking the release procedure

On Thu, Oct 20, 2011 at 10:01 PM, Dustin Sallings dus...@spy.net wrote:

 On Oct 20, 2011, at 6:18 PM, Noah Slater wrote:

 The history is in the X.Y.x release branch. It has no
 business cluttering up the tags, and no business confusing users about
 whether it has been blessed by the project.


        Does this imply you intend to leave branches open forever even when 
 development on them has stopped?

        I would say that the history is in the commits that lead up to the tag 
 along with the release notes being actually *in* the tag.

        I've seen people keep lots of dead branches around which I find 
 considerably more confusing than excessive tags since a branch is a dynamic 
 line of development and a tag is a static commit in time.  If you're not 
 actively doing development, a branch just makes it look like you might be.

        It's trivial (in git at least) to reopen a development branch from any 
 previously released version with cryptographically verified certainty that 
 you have the correct code that led to that release.


Your argument here and the earlier argument about branches being
temporary tags confuses me. Both are nothing more than pointers at
hashes. This is just a social distinction. This entire thread is
considering social distinctions about community consensus to decide
what will be the value of the 1.1.1 (for immediate reference) tag.

Consider each release a single round of Paxos to generate distributed
consensus on which sha to choose.


        Not that I think you guys don't know what you're doing or anything.  
 I'm coming mostly from a user who will be hoping to be using couchdb 
 sources, writing extensions, and trying hard to make sure whatever changes I 
 make are made available to all couchdb users and developers.  That and I've 
 got a ridiculous amount of time spent manipulating git repos.

 --
 dustin sallings

Re: Locking down the wiki

On Thu, Oct 20, 2011 at 7:26 PM, Noah Slater nsla...@tumbolia.org wrote:
 Hey,

 On advice from Gavin McDonald, I'd like to suggest that we lock down the
 wiki to a list of pre-approved users. To get approved to make edits, you
 would submit a request to one of the mailing lists or to one of the wiki
 admins or committers. That's it. It should remove the need to protect pages
 like the in the wild stuff and the people on the couch. Other projects
 have implemented this and they get absolutely no spam as a result.
 Infrastructure suggested we move to it, and I wanna see what people think
 about it.

 More info here:

 http://wiki.apache.org/general/OurWikiFarm


 Look for the section:

 per wiki access control - tighten your wiki just a little, benefit just a
 lot


 Thanks,

 N


+1 one of these
http://astroblog.cosmobc.com/wp-content/uploads/2010/03/shuttle.jpg

Re: [VOTE] Apache CouchDB 1.1.1 Release, Round 2

On Thu, Oct 20, 2011 at 7:16 PM, Noah Slater nsla...@tumbolia.org wrote:
Can someone provide assistance on the new Test procedure please:

http://mail-archives.apache.org/mod_mbox/couchdb-dev/201110.mbox/%3CCA+Y+447FXqVGx8ow=ewqm86cn9epb1cnbmvhk9ku4ogujby...@mail.gmail.com%3E

I am not sure how best to update the workflow for Git.

git clone http://git-wip-us.apache.org/repos/asf/couchdb.git git
checkout X.Y.Z

The more I think about it, the more I think the requirement to not
require a local checkout is silly. You're still requiring a copy of
the VCS locally. Just because Git can make it a super awesome local
copy of the entire repo seems like something we shouldn't penalize it
for.

Granted, Noah usually has a reasoning, so maybe I'm missing something else?

This is important. *waves hands*

On Thu, Oct 20, 2011 at 6:44 PM, Robert Newson rnew...@apache.org wrote:

This is the second release vote for Apache CouchDB 1.1.1

Changes since round 1;

* Fix object sealing with SpiderMonkey 1.7.0
* Update CHANGES/NEWS to reflect COUCHDB-1129
* Fix JavaScript CLI test runner

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. Please report your
results and vote to this thread.

We are voting on the following release artifacts:

http://people.apache.org/~rnewson/dist/1.1.1/

Instructions for validating the release tarball can be found here:

http://people.apache.org/~rnewson/dist/

Instructions for testing the build artefacts can be found here:

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

These artifacts have been built from the 1.1.1 tag in Git:

apache-couchdb-1.1.1.tar.gz
apache-couchdb-1.1.1.tar.gz.md5
apache-couchdb-1.1.1.tar.gz.asc
apache-couchdb-1.1.1.tar.gz.sha

Test ALL the things.

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)

http://www.youtube.com/watch?feature=player_detailpagev=G6j5bve7O5E#t=109s

On Thu, Oct 20, 2011 at 7:08 PM, Noah Slater nsla...@tumbolia.org wrote:
 +1 on all the stuff Paul said.

 On Thu, Oct 20, 2011 at 9:25 PM, Robert Newson rnew...@apache.org wrote:

 I'll also note that the bug that killed round 1 of 1.1.1 was not found
 by any test we currently have. All it would have taken is a test that
 did any map call followed by almost any other bit of javascript (and
 sm 1.7.0).

 On 20 October 2011 21:22, Paul Davis paul.joseph.da...@gmail.com wrote:
  On Thu, Oct 20, 2011 at 1:45 PM, Randall Leeds randall.le...@gmail.com
 wrote:
  On Thu, Oct 20, 2011 at 13:42, Paul Davis paul.joseph.da...@gmail.com
 wrote:
 
  On Thu, Oct 20, 2011 at 1:38 AM, Randall Leeds rand...@apache.org
 wrote:
   On Wed, Oct 19, 2011 at 23:38, J. Lee Coltrane 
  l...@projectmastermind.comwrote:
  
  
For what it's worth, a CLI based test system is what I was
 imagining
as well. Take Futon out of the mix and test CouchDB.
  
   IMO, If CouchDB is intended to be a server that can be accessed from
   the browser directly, then there should continue to be some kind of
   browser-based test suite that would serve to confirm this
 capability.
  
  
   I have been looking closely at the Futon tests in 1.1.0 for the last
   several days, with the idea that I might begin to clean them up a
 bit
   as time permits.
  
   I have found that, while some of these test failures are totally
 bogus,
   *some* of them actually do stem from real issues -- minor
   incompatibilities between CouchDB's http interface, and the internal
   mechanisms of modern browsers (XHR, caching, etc).
  
   These are problems that we're not going to catch with a stateless,
   cache-less http client running on the CLI.  (I can provide examples)
  
   These issues have the potential to cause real problems for
   developers of real browser-based apps in the wild.  That means,
   there's valuable info to be gathered from the browser tests, Iff we
   can clean them up, and make them behave consistently; so that
   when they fail or succeed, we can actually trust the results.
  
  
   After digging around a good bit, I can see no reason why the
 existing
   tests couldn't be cleaned up and made to work correctly in all
 current
   versions of major browsers.  I also see no reason why the same tests
   couldn't be used successfully from the CLI and `make check` as well.
  
   I do see significant benefits to using the same javascript test code
 in
   all environments we test.
  
   -Lee
   (irc: coltr)
  
  
    +1
   Verify Installation could grow into a suite of browser/futon tests
 that
   verify that futon (and apps in general) work, including interactions
 with
   proxies and the like.
 
  Sure. Client tests that test the client are fine.
 
   The test suite for developers should run cleanly from the CLI as part
 of
   make check, but continue to be exposed in futon. We should work to be
  sure
   they function as well as possible, for the reasons you provide.
  
 
  Blargh no. Server tests should be testing the server. The entire point
  of moving to the command line is so that we don't have to maintain the
  Futon test suite. Just look at the 1.1.1 thread (or damn near any
  release thread) and the wildly varying reports of test output. The
  situation is just a waste of time for everyone involved.
 
   I think the JS testing situation is a great place for people to jump
 in
  and
   help out, especially with the browser environment diversity.
  
 
  Sure, but I don't see what this has to do with browsers.
 
 
  People who aren't into the internals can help to fix the suite to work
 in
  different browser environments. That's all I meant.
 
 
  Seeing as I'm having a Negative Nancy day, I'll just ask rhetorically,
  If these people exist, why do I not see anything in JIRA?
 
  I suggested that the CLI tests be exposed in Futon because I think there
 are
  probably some JS heads in this community who wouldn't have too much
 trouble
  fixing a lot of the user agent related issues in the test suite. I
 didn't
  mean to suggest that it should continue to be part of the release
 procedure
  (it shouldn't) or that we should feel 100% obligated to make sure they
 pass
  in 100% of environments (we can't and shouldn't), but J. Lee's point
 about
  how keeping such tests around can sometimes expose interesting problems
 we
  wouldn't otherwise see, possible outside the CouchDB codebase even, is
  worthwhile.
 
  -Randall
 
 
  We've had these tests for three years or more now. Perhaps I'm just
  being dense today but I can't think of a single specific case where
  testing things in the browser has lead to a bug report/fix that we
  wouldn't have found with pure CLI tests.
 
  The only thing that I'm aware that the tests have done for us is
  required us to exert a nontrivial amount of effort to keep them
  running in multiple browser environments. I have no interest

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)

Wait, did you post that because me and you rock this project like the
Beatles rocked America? Or did you post it with the intention of the song
She Loves You being a sort of meta-commentary on our enviable, and now
infamous, bromance?

On Fri, Oct 21, 2011 at 5:13 AM, Paul Davis paul.joseph.da...@gmail.comwrote:

 http://www.youtube.com/watch?feature=player_detailpagev=G6j5bve7O5E#t=109s

 On Thu, Oct 20, 2011 at 7:08 PM, Noah Slater nsla...@tumbolia.org wrote:
  +1 on all the stuff Paul said.
 
  On Thu, Oct 20, 2011 at 9:25 PM, Robert Newson rnew...@apache.org
 wrote:
 
  I'll also note that the bug that killed round 1 of 1.1.1 was not found
  by any test we currently have. All it would have taken is a test that
  did any map call followed by almost any other bit of javascript (and
  sm 1.7.0).
 
  On 20 October 2011 21:22, Paul Davis paul.joseph.da...@gmail.com
 wrote:
   On Thu, Oct 20, 2011 at 1:45 PM, Randall Leeds 
 randall.le...@gmail.com
  wrote:
   On Thu, Oct 20, 2011 at 13:42, Paul Davis 
 paul.joseph.da...@gmail.com
  wrote:
  
   On Thu, Oct 20, 2011 at 1:38 AM, Randall Leeds rand...@apache.org
  wrote:
On Wed, Oct 19, 2011 at 23:38, J. Lee Coltrane 
   l...@projectmastermind.comwrote:
   
   
 For what it's worth, a CLI based test system is what I was
  imagining
 as well. Take Futon out of the mix and test CouchDB.
   
IMO, If CouchDB is intended to be a server that can be accessed
 from
the browser directly, then there should continue to be some kind
 of
browser-based test suite that would serve to confirm this
  capability.
   
   
I have been looking closely at the Futon tests in 1.1.0 for the
 last
several days, with the idea that I might begin to clean them up a
  bit
as time permits.
   
I have found that, while some of these test failures are totally
  bogus,
*some* of them actually do stem from real issues -- minor
incompatibilities between CouchDB's http interface, and the
 internal
mechanisms of modern browsers (XHR, caching, etc).
   
These are problems that we're not going to catch with a
 stateless,
cache-less http client running on the CLI.  (I can provide
 examples)
   
These issues have the potential to cause real problems for
developers of real browser-based apps in the wild.  That means,
there's valuable info to be gathered from the browser tests, Iff
 we
can clean them up, and make them behave consistently; so that
when they fail or succeed, we can actually trust the results.
   
   
After digging around a good bit, I can see no reason why the
  existing
tests couldn't be cleaned up and made to work correctly in all
  current
versions of major browsers.  I also see no reason why the same
 tests
couldn't be used successfully from the CLI and `make check` as
 well.
   
I do see significant benefits to using the same javascript test
 code
  in
all environments we test.
   
-Lee
(irc: coltr)
   
   
 +1
Verify Installation could grow into a suite of browser/futon tests
  that
verify that futon (and apps in general) work, including
 interactions
  with
proxies and the like.
  
   Sure. Client tests that test the client are fine.
  
The test suite for developers should run cleanly from the CLI as
 part
  of
make check, but continue to be exposed in futon. We should work to
 be
   sure
they function as well as possible, for the reasons you provide.
   
  
   Blargh no. Server tests should be testing the server. The entire
 point
   of moving to the command line is so that we don't have to maintain
 the
   Futon test suite. Just look at the 1.1.1 thread (or damn near any
   release thread) and the wildly varying reports of test output. The
   situation is just a waste of time for everyone involved.
  
I think the JS testing situation is a great place for people to
 jump
  in
   and
help out, especially with the browser environment diversity.
   
  
   Sure, but I don't see what this has to do with browsers.
  
  
   People who aren't into the internals can help to fix the suite to
 work
  in
   different browser environments. That's all I meant.
  
  
   Seeing as I'm having a Negative Nancy day, I'll just ask rhetorically,
   If these people exist, why do I not see anything in JIRA?
  
   I suggested that the CLI tests be exposed in Futon because I think
 there
  are
   probably some JS heads in this community who wouldn't have too much
  trouble
   fixing a lot of the user agent related issues in the test suite. I
  didn't
   mean to suggest that it should continue to be part of the release
  procedure
   (it shouldn't) or that we should feel 100% obligated to make sure
 they
  pass
   in 100% of environments (we can't and shouldn't), but J. Lee's point
  about
   how keeping such tests around can sometimes expose interesting
 problems
  we
   wouldn't otherwise see, possible outside the CouchDB codebase even,
 is
   worthwhile.

Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)