Re: [ANNOUNCE] Jay Doane elected as CouchDB committer

[Eiri]

Congratulations, Jay! Welcome, and well deserved!


---
Eric

 

> On Jan 8, 2019, at 19:16, Alexander Shorin  wrote:
> 
> Congratulations, Jay, and Happy New Year! 
> --
> ,,,^..^,,,
> 
> On Wed, Jan 9, 2019 at 2:11 AM Joan Touzet  wrote:
>> 
>> Dear community,
>> 
>> I am pleased to announce that the CouchDB Project Management Committee has 
>> elected Jay Doane as a CouchDB committer.
>> 
>>Apache ID: jaydoane
>> 
>>IRC nick: jaydoane
>> 
>>Twitter: jaydoane
>> 
>> Committers are given a binding vote in certain project decisions, as well as 
>> write access to public project infrastructure.
>> 
>> This election was made in recognition of Jay's commitment to the project. We 
>> mean this in the sense of being loyal to the project and its interests.
>> 
>> Please join me in extending a warm welcome to Jay!
>> 
>> On behalf of the CouchDB PMC,
>> Joan "more committers!" Touzet

Re: [PROPOSAL] Change the minimum supported Erlang version to OTP 19

[Eiri]

+1


> On Dec 20, 2018, at 04:55, Jay Doane  wrote:
> 
> Currently, CouchDB requires at least OTP 17 or later to build and run
> [1][2]. However, recent work undertaken to eliminate compiler warnings
> [3][4] has highlighted the additional effort needed to continue to support
> older Erlang versions. Some of the issues that have come up are:
> 1. erlang:now/0 deprecated in OTP 18 [5]
> 2. crypto:rand_uniform/2 deprecated in OTP 20 [6], but no rand module
> pre-OTP 18
> which both require using rebar platform defines [7] and ifdefs [8] to work
> around compiler warnings.
> 
> Joan raised the idea that maybe it's time to move to a more recent minimum
> version to simplify the code, and also because there a many compelling new
> features in later versions that we currently cannot use:
> 1. maps introduced in OTP 17, but only became performant for large number
> of entries in OTP 18 [9]
> 2. off heap messages introduced in OTP 19 [10]
> 
> Since CouchDB now ships with it's own OTP 19.6.3 Erlang binaries [9], it's
> not clear whether we need to continue supporting OTP 17 and 18. As a bonus,
> removing those versions will also speed up travis builds.
> 
> Any thoughts either for or against this proposal?
> 
> Best regards,
> Jay
> 
> [1] https://github.com/apache/couchdb/blob/master/rebar.config.script#L94
> [2] https://github.com/apache/couchdb/blob/master/.travis.yml#L10
> [3] https://github.com/apache/couchdb-ets-lru/pull/7
> [4] https://github.com/apache/couchdb/pull/1798
> [5] http://erlang.org/doc/apps/erts/time_correction.html
> [6] http://erlang.org/pipermail/erlang-questions/2017-May/092435.html
> [7]
> https://github.com/apache/couchdb/blob/master/src/couch/rebar.config.script#L148-L154
> [8]
> https://github.com/apache/couchdb/blob/master/src/couch/src/couch_rand.erl#L22-L57
> [9] http://erlang.org/download/otp_src_18.0.readme
> [10]
> https://www.erlang-solutions.com/blog/erlang-19-0-garbage-collector.html
> [9] https://github.com/apache/couchdb-ci/blob/master/README.md

Re: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Eiri]

+1


> On Dec 7, 2018, at 12:58, Joan Touzet  wrote:
> 
> Requesting lazy consensus - does anyone have a problem with them
> starting the process to mass-migrate all of the remaining repos to
> gitbox?
> 
> This means integrated access and easy PRs on repos like couchdb-admin,
> couchdb-ets-lru, etc.
> 
> I can't imagine anyone will say no, but we need "documented support
> for the decision" from a mailing list post, so, here it is.
> 
> -Joan
> - Forwarded Message -
> From: "Daniel Gruno" 
> To: us...@infra.apache.org
> Sent: Friday, December 7, 2018 11:52:36 AM
> Subject: [NOTICE] Mandatory relocation of Apache git repositories on 
> git-wip-us.apache.org
> 
> [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
>  DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
> 
> Hello Apache projects,
> 
> I am writing to you because you may have git repositories on the
> git-wip-us server, which is slated to be decommissioned in the coming
> months. All repositories will be moved to the new gitbox service which
> includes direct write access on github as well as the standard ASF
> commit access via gitbox.apache.org.
> 
> ## Why this move? ##
> The move comes as a result of retiring the git-wip service, as the
> hardware it runs on is longing for retirement. In lieu of this, we
> have decided to consolidate the two services (git-wip and gitbox), to
> ease the management of our repository systems and future-proof the
> underlying hardware. The move is fully automated, and ideally, nothing
> will change in your workflow other than added features and access to
> GitHub.
> 
> ## Timeframe for relocation ##
> Initially, we are asking that projects voluntarily request to move
> their repositories to gitbox, hence this email. The voluntary
> timeframe is between now and January 9th 2019, during which projects
> are free to either move over to gitbox or stay put on git-wip. After
> this phase, we will be requiring the remaining projects to move within
> one month, after which we will move the remaining projects over.
> 
> To have your project moved in this initial phase, you will need:
> 
> - Consensus in the project (documented via the mailing list)
> - File a JIRA ticket with INFRA to voluntarily move your project repos
>   over to gitbox (as stated, this is highly automated and will take
>   between a minute and an hour, depending on the size and number of
>   your repositories)
> 
> To sum up the preliminary timeline;
> 
> - December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
>   relocation
> - January 9th -> February 6th: Mandated (coordinated) relocation
> - February 7th: All remaining repositories are mass migrated.
> 
> This timeline may change to accommodate various scenarios.
> 
> ## Using GitHub with ASF repositories ##
> When your project has moved, you are free to use either the ASF
> repository system (gitbox.apache.org) OR GitHub for your development
> and code pushes. To be able to use GitHub, please follow the primer
> at: https://reference.apache.org/committer/github
> 
> 
> We appreciate your understanding of this issue, and hope that your
> project can coordinate voluntarily moving your repositories in a
> timely manner.
> 
> All settings, such as commit mail targets, issue linking, PR
> notification schemes etc will automatically be migrated to gitbox as
> well.
> 
> With regards, Daniel on behalf of ASF Infra.
> 
> PS:For inquiries, please reply to us...@infra.apache.org, not your 
> project's dev list :-).
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org

Re: [VOTE] Release Apache CouchDB 2.3.0-RC1

[Eiri]

Ubuntu 18.04 (bionic)

sig: ok
sha256: ok
sha512: ok

Deps installed with install-dependencies.sh from 
https://github.com/apache/couchdb-ci

All tests pass. Had to rerun js tests because of emfile.

Manual testing with curl: start cluster, create db, bulk add docs, add a view, 
query view, delete db.

+1 from me.


---
Eric

Exact definition of a database "active size"

[Eiri]

Dear all,

I’d like to hear your opinion on how we should interpret a database attribute 
“active size”.

As you surely know we are using three different size attributes in a database 
info: file - the size of the database file on disk; external - the uncompressed 
size of database contents and active, defined as “the size of live data inside 
the database” or “active byte in the current MVCC snapshot”.

Sometime ago I had a discussion with Paul Davis and he pointed on ambiguity of 
that definition, namely - is it live data before a compaction or after a 
compaction? To put it in other words: should we treat as “active” only the 
documents and attachments on btree’s leafs or also include into it the previous 
document revisions while they can be accessed. Codewise it is the latter, both 
in current version of CouchDB and in 1.x version where active size was named 
data_size, but intuitively it feels that it should be former.

Despite sounds academical this is a practical question, the difference of 
active size before and after compaction could be rather noticeable and since it 
is used as a trigger by compaction daemon it could skew disk usage pattern.

Please share your thoughts. If we’ll conclude that we want to change how active 
size calculated I’m willing to take on implementation of this as I have a 
recent PR around the same area of code.


Regards,
Eric

 



 

  

Re: Proposal: removing view changes code from mrview

[Eiri]

Hi all,

Since we seems to be in agreement and with 2.1.2 released, I'm starting to work 
on this.
Just wanted to let everyone know.


Regards,
Eric



> On Apr 3, 2018, at 13:03, Paul Davis  wrote:
> 
> +1
> 
> On Tue, Apr 3, 2018 at 9:23 AM, Joan Touzet  wrote:
> 
>> +1.
>> 
>> 1. No one has worked on a fix since its contribution prior to 2.0.
>> 2. The code will always be in git in an older revision if someone is
>> looking for it.
>> 3. We have #592 which describes the fundamental problem that needs to be
>> resolved. (By the way, with my PMC hat on, you should unassign this issue
>> from yourself unless you're actively working on it *right now*.)
>> 
>> - Original Message -
>> From: "Eiri" 
>> To: dev@couchdb.apache.org
>> Sent: Tuesday, April 3, 2018 8:15:21 AM
>> Subject: Proposal: removing view changes code from mrview
>> 
>> Hi all,
>> 
>> It is my understanding that a current implementation of view changes in
>> mrview is conceptually broken. I heard from Robert Newson that he and
>> Benjamin Bastian found that some time ago doing testing with deletion and
>> recreation of docs emitting same keys in the views.
>> 
>> I propose to remove view changes code from mrview and its mention from
>> documentation, as it seem that people keep trying to use those for filtered
>> replication or getting a false impression that it's a simple fix in fabric.
>> Not to mention that the current implementation quite complicates mrviews
>> code and takes space in view files with building unneeded seq and kseq
>> btrees.
>> 
>> We can re-implement this feature later in more robust way as there are
>> clearly a demand for it. Please share your opinion.
>> 
>> 
>> Regards,
>> Eric
>> 

Proposal: removing view changes code from mrview

[Eiri]

Hi all,

It is my understanding that a current implementation of view changes in mrview 
is conceptually broken. I heard from Robert Newson that he and Benjamin Bastian 
found that some time ago doing testing with deletion and recreation of docs 
emitting same keys in the views.

I propose to remove view changes code from mrview and its mention from 
documentation, as it seem that people keep trying to use those for filtered 
replication or getting a false impression that it's a simple fix in fabric. Not 
to mention that the current implementation quite complicates mrviews code and 
takes space in view files with building unneeded seq and kseq btrees.

We can re-implement this feature later in more robust way as there are clearly 
a demand for it. Please share your opinion.


Regards,
Eric

Re: /_stats not working on 2.0

[Eiri]

Hi Garth,

Stats are node specific, so they are on nodes interface 
/_node/{node@name}/_stats in 2.0,  e.g. /_node/node1@127.0.0.1/_stats


Regards,
Eric

> On Dec 1, 2016, at 15:26, Garth Gutenberg  wrote:
> 
> When I try hitting localhost:5984/_stats I get:
> 
> {"error":"not_found","reason":"Database does not exist."}
> 
> On my 1.6 box it returns stats as expected.  All of the 2.0 docs still
> refer to /_stats, but it's not working for me.
> 
> Of note, I'm testing this against a cluster setup.  Could that be the
> problem?  Is /_stats not supported in a cluster?  If not, what is the
> equivalent?

Re: [VOTE] Release Apache CouchDB 2.0.0-rc.1

[Eiri]

CentOS 7.2, erlang 17.5

Verified sig and checksums, all is good, though sha256sum (version 8.22) 
doesn’t like format of apache-couchdb-2.0.0.tar.gz.sha256 file

`make check` passed. I ran some simple tests: created db, added and updated a 
couple of docs, deleted db, replicated db from Couch 1.6 — everything’s looking 
good.

+1


Regards,
Eric


> On Sep 12, 2016, at 10:53, Jan Lehnardt  wrote:
> 
> Dear community,
> 
> I would like to call a vote Apache CouchDB 2.0.0-rc.1.
> 
> We encourage the whole community to download and test these release artefacts 
> so that any critical issues can be resolved before the release is made. 
> Everyone is free to vote on this release, so get stuck in!
> 
> The release artefacts we are voting on are available here:
> 
>wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.0.0/rc.1/apache-couchdb-2.0.0.tar.gz
>wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.0.0/rc.1/apache-couchdb-2.0.0.tar.gz.asc
>wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.0.0/rc.1/apache-couchdb-2.0.0.tar.gz.tar.gz.md5
>wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.0.0/rc.1/apache-couchdb-2.0.0.tar.gz.tar.gz.sha
> 
> Please follow the test procedure here:
> 
>
> https://docs.google.com/document/d/1BtndYr-0KDQTqBSLVdJoR_8C5ObYjT1RBo_Qyh5ykdQ/edit
> 
> Please remember that “rc.1” is an annotation. If the vote passes, these 
> artefacts will be released as Apache CouchDB 2.0.0. If we are restarting the 
> vote, we’ll get “rc.2”, “rc.3” etc.
> 
> Please also note, since this is the first vote on 2.0.0, we’re leaving the 
> vote open for a full five days instead of the usual 3.
> 
> If you find *anything* out of the ordinary, please let us know asap. Doing 
> votes is cheap, but we have to make sure that this is a good release.
> 
> Here is some background info on what it means to do an Apache Release: 
> http://www.apache.org/dev/release.html
> 
> Everyone on this list has a vote and every vote counts!
> 
> Please cast your votes now.
> 
> Thanks,
> Jan
> --
> 

Re: Testing a CouchDB 2.0 feature

[Eiri]

Hi Joey,

Does the invalid json you are seeing looks like it described in this issue's 
comment?

https://issues.apache.org/jira/browse/COUCHDB-3060?focusedCommentId=15436912=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15436912
 


If so it should be fixed in the next RC

Regards,
Eric


> On Sep 2, 2016, at 15:06, Joey Samonte  wrote:
> 
> How do I file a bug report for this? Seems to return an invalid json both 
> when results are found or not.
> 
>> Date: Tue, 30 Aug 2016 01:35:46 -0400
>> From: woh...@apache.org
>> To: dev@couchdb.apache.org
>> Subject: Re: Testing a CouchDB 2.0 feature
>> 
>> Should be possible! Try it yourself!
>> 
>> - Original Message -
>>> From: "Joey Samonte" 
>>> To: dev@couchdb.apache.org
>>> Sent: Tuesday, August 30, 2016 1:10:38 AM
>>> Subject: RE: Testing a CouchDB 2.0 feature
>>> 
>>> Is it possible to add a 'limit' and 'descending' clause to each pair
>>> of startkey/endkey?
>>> 
 Date: Wed, 24 Aug 2016 14:51:56 -0400
 From: woh...@apache.org
 To: dev@couchdb.apache.org
 Subject: Re: Testing a CouchDB 2.0 feature
 
 Try it and find out! :) (Yes, it should work just fine.)
 
 
 
 - Original Message -
> From: "Joey Samonte" 
> To: dev@couchdb.apache.org
> Sent: Wednesday, August 24, 2016 7:31:00 AM
> Subject: RE: Testing a CouchDB 2.0 feature
> 
> Could the startkeys and endkeys be arrays as before?
> Thanks!
> 
>> Date: Wed, 24 Aug 2016 05:32:09 -0400
>> From: woh...@apache.org
>> To: dev@couchdb.apache.org
>> Subject: Re: Testing a CouchDB 2.0 feature
>> 
>> Replying to my own email with more detail.
>> 
>> The format of the 'queries' POST doc should look like:
>> 
>> {
>>  "queries" : [
>>{ "startkey": "a", "endkey": "c"},
>>{ "startkey": "q", "endkey": "s"}
>>  ]
>> }
>> 
>> 
>> - Original Message -
>>> From: "Joan Touzet" 
>>> To: dev@couchdb.apache.org
>>> Sent: Wednesday, August 24, 2016 5:29:24 AM
>>> Subject: Re: Testing a CouchDB 2.0 feature
>>> 
>>> Looks like from the code your POST body should contain a
>>> 'queries' list or a 'keys' key-value pair. Here's an example
>>> of the latter that should now work under CouchDB 2.0 (see the
>>> answer, not the question):
>>> 
>>> http://stackoverflow.com/questions/27327140/how-to-combine-multiple-couchdb-queries-into-a-single-request
>>> 
>>> 
>>> 
>>> - Original Message -
 From: "Joey Samonte" 
 To: dev@couchdb.apache.org
 Sent: Wednesday, August 24, 2016 5:07:07 AM
 Subject: Testing a CouchDB 2.0 feature
 
 
 
 Good day,
 
 It says here that this issue is already resolved.
 https://issues.apache.org/jira/browse/COUCHDB-523
 I was really looking forward for this feature, so I was
 wondering
 is
 there any documentation for this, on how to use the API?
 
 Regards,
 Joey
 
 
 
>>> 
>>> 
> 
>>> 
> 

[GitHub] couchdb-couch-log-lager pull request: Get lager event handlers fro...

[eiri]

Github user eiri commented on a diff in the pull request:


https://github.com/apache/couchdb-couch-log-lager/pull/2#discussion_r56441052
  
--- Diff: src/couch_log_lager.erl ---
@@ -64,10 +64,9 @@ emergency(Fmt, Args) ->
 
 -spec set_level(atom()) -> ok.
 set_level(Level) ->
-{ok, Handlers} = application:get_env(lager, handlers),
-lists:foreach(fun({Handler, _}) ->
-lager:set_loglevel(Handler, Level)
-end, Handlers).
+Handlers = gen_event:which_handlers(lager_event),
+[ok = lager:set_loglevel(Handler, Level) || Handler <- Handlers],
--- End diff --

I'd suggest to keep foreach here, it's more idiomatically correct and you 
wouldn't need an explicit `ok` at the end. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] couchdb-couch-log-lager pull request: Get lager event handlers fro...

[eiri]

Github user eiri commented on the pull request:


https://github.com/apache/couchdb-couch-log-lager/pull/2#issuecomment-197638745
  
lgtm


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] couchdb-couch pull request: Fix `active_size` format conversion in...

[eiri]

Github user eiri commented on the pull request:

https://github.com/apache/couchdb-couch/pull/54#issuecomment-106033350
  
@hdiedrich Yes I understand the question and link in my previous answer is 
pointing to the code point. It's populated on `couch_db_updater` init and 
`btree_by_id_reduce` is the reducer.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] couchdb-couch pull request: Fix `active_size` format conversion in...

[eiri]

GitHub user eiri opened a pull request:

https://github.com/apache/couchdb-couch/pull/54

Fix `active_size` format conversion in `get_db_info` function

In `active_size` conversion in `couch_db:get_db_info/1` old db reduction's 
size format assumed to be an integer representing active state, when it also 
could be a tuple of active and external sizes.

This handeled correctly, for example, in 
[couch_db_updater.erl](https://github.com/apache/couchdb-couch/blob/master/src/couch_db_updater.erl#L426).

This patch addresses conversion of both possible formats to CouchDB 
`size_info` record.

This closes issue COUCHDB-2701

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/eiri/couchdb-couch fix-get-db-info

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/couchdb-couch/pull/54.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #54


commit e2349f39c23a22c1ed054224f1a8ace68a4366e1
Author: Eric Avdey e...@eiri.ca
Date:   2015-05-26T12:59:24Z

Fix `active_size` format conversion in `get_db_info` function

In `active_size` conversion in `couch_db:get_db_info/1` old db reduction's 
size format assumed to be an integer representing active state, when it also 
could be a tuple of active and external sizes.

This handeled correctly, for example, in 
[couch_db_updater.erl](https://github.com/apache/couchdb-couch/blob/master/src/couch_db_updater.erl#L426).

This patch addresses conversion of both possible formats to CouchDB 
`size_info` record.

This closes issue COUCHDB-2701




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] couchdb-couch pull request: Fix `active_size` format conversion in...

[eiri]

Github user eiri commented on the pull request:

https://github.com/apache/couchdb-couch/pull/54#issuecomment-105523469
  
@kxepal I can reproduce it by migrating a test database from DBCore to 
CouchDB 2.0, but I doubt it could be shown in migration from CouchDB 1.6.x to 
2.0, as far as I can tell from a code, 1.6.x doesn't have a concept of external 
size and just uses integer in there. I can try though.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] couchdb-couch pull request: Fix `active_size` format conversion in...

[eiri]

Github user eiri commented on the pull request:

https://github.com/apache/couchdb-couch/pull/54#issuecomment-105577336
  
@hdiedrich : in 
[couch_db_updater.erl](https://github.com/apache/couchdb-couch/blob/master/src/couch_db_updater.erl#L492)

It's the same in DBCore's `couch_db_updater:btree_by_id_reduce/2`, except, 
but of course, for the record vs tuple discrepancy. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] couchdb-couch pull request: Fix `active_size` format conversion in...

[eiri]

Github user eiri commented on the pull request:

https://github.com/apache/couchdb-couch/pull/54#issuecomment-105529725
  
@kxepal  I don't think simple copy would do, given the database file going 
to be named as a shard. I thought of something like creating test db for 1.x, 
creating empty db with same name in 2.x (probably as r,w,n,q = 1), then 
overwriting it with 1.x and running compaction. Tricky business, but should be 
doable.

DBCore and CouchDB 1.x are quite different, but DBCore and Couch 2.0 are 
essentially the same apart from active/external format. Couch 2.0 uses 
#active_size record for it and DBCore just a 2 elements tuple, hence the PR.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] couchdb-ets-lru pull request: Migrate the tests from etap to eunit

[eiri]

GitHub user eiri opened a pull request:

https://github.com/apache/couchdb-ets-lru/pull/1

Migrate the tests from etap to eunit

All the etap tests converted to eunit. The tests for the validating
of the correct handeling of the bad options for LRU are re-enabled.

This work is a part of COUCHDB-2590.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/eiri/couchdb-ets-lru migrate-tests-to-eunit

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/couchdb-ets-lru/pull/1.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1


commit fb44bea467f13497d1af8b869f62203ba58a9dcb
Author: Eric Avdey e...@eiri.ca
Date:   2015-04-30T12:16:19Z

Migrate the tests from etap to eunit

All the etap tests converted to eunit. The tests for the validating
of the correct handeling of the bad options for LRU are re-enabled.

This work is a part of COUCHDB-2590.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---