Re: futon tests (Was: Re: [VOTE] Apache CouchDB 1.1.1 Release)
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. 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. I think the JS testing situation is a great place for people to jump in and help out, especially with the browser environment diversity. -R
[jira] [Commented] (COUCHDB-860) Futon appends wrong version number to files
[ https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131465#comment-13131465 ] Volker Mische commented on COUCHDB-860: --- Randall, it's still there: https://github.com/apache/couchdb/blob/trunk/share/www/index.html#L24 I think the original idea was to prevent browers to cache the JavaScript from different versions of CouchDB. As there's stil 0.11.0 appended to the files the resolution for the fix shouldn't be Cannot Reproduce but Won't fix. 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)
+1 On Wed, 2011-10-19 at 23:38 -0400, J. Lee Coltrane 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. 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) signature.asc Description: This is a digitally signed message part
Re: [VOTE] Apache CouchDB 1.1.1 Release
On Wed, Oct 19, 2011 at 16:27, 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. Testing in the Gentoo Linux packaging system yields the following test failures: Test Summary Report --- /var/tmp/portage/dev-db/couchdb-1.1.1/work/apache-couchdb-1.1.1/test/etap/170-os-daemons.t (Wstat: 0 Tests: 37 Failed: 0) Parse errors: Bad plan. You planned 49 tests but ran 37. /var/tmp/portage/dev-db/couchdb-1.1.1/work/apache-couchdb-1.1.1/test/etap/173-os-daemon-cfg-register.t (Wstat: 0 Tests: 27 Failed: 5) Failed tests: 4, 6, 23, 26-27 Files=44, Tests=773, 188 wallclock secs ( 0.45 usr 0.15 sys + 39.30 cusr 7.16 csys = 47.06 CPU) Result: FAIL This is with Erlang 13B04. On the other hand, the browser test suite (Firefox 9.0a2, OS X) is all clean, which is more than I can say for most releases I've tried! Thanks for the release work, let me know if I can debug those test failures somehow). Cheers, Dirkjan
Re: [VOTE] Apache CouchDB 1.1.1 Release
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
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
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
[ 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
[ 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
[ 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
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
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
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)
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
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
[ 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
-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
+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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
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. B.
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)
Honestly, I was looking for the video of the one lady screaming to provide commentary on they I agree with what he said comment. But I failed slightly, but only slightly enough to illicit an awesome introspection on a random Beatles video. On Thu, Oct 20, 2011 at 11:17 PM, Noah Slater nsla...@tumbolia.org wrote: 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