Re: BigCouch merge status

[Joan Touzet]

Yes. Download our new 2.0.0-RC2 release candidate to get your hands on
the merged code and let us know how your testing goes! We hope to have
2.0.0 released very, very soon now.

-Joan

- Original Message -
> From: "Nestor Urquiza" 
> To: user@couchdb.apache.org
> Sent: Thursday, July 21, 2016 3:01:26 PM
> Subject: BigCouch merge status
> 
> Greetings,
> 
> I am sorry if I missed the announcement but was BigCouch code merged
> into
> couchdb?
> 
> Thanks,
> 
> - Nestor
> 

[jira] [Created] (COUCHDB-3068) Docs fail to build with Sphinx 1.4+

[Joan Touzet (JIRA)]

Joan Touzet created COUCHDB-3068:


 Summary: Docs fail to build with Sphinx 1.4+
 Key: COUCHDB-3068
 URL: https://issues.apache.org/jira/browse/COUCHDB-3068
 Project: CouchDB
  Issue Type: Bug
  Components: Documentation
Reporter: Joan Touzet


After updating my local install of Sphinx to 1.4, I get the following error in 
the build:

{noformat}
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [  0%] about
writing output... [  1%] api/basics

Warning, treated as error:
/home/joant/couchdb/src/docs/src/api/basics.rst:144: WARNING: Could not lex 
literal_block as "http". Highlighting skipped.
{noformat}

Because we specify {{-W}} on the {{sphinx-build}} line, we treat all warnings 
as errors the build stops here. Removing the -W allows the build to complete 
but results in 255 warnings where highlighting is being skipped as a result of 
a failure to parse the block. The full output of {{make html}} is here: 
https://paste.apache.org/DKOL

The temporary fix is to disable the -W option in the makefile. [~janl] 
[~andywenk] this is something you might want to think about for the RC2 
release, though I suspect your local Sphinx is old enough that it's not running 
into the bug.

The right fix is to fix the code blocks so they work under Sphinx 1.4+. See for 
instance [this diff|http://dpdk.org/dev/patchwork/patch/14861/] of how another 
project fixed their warnings - it's mainly un-escaping some text since the 
parser expects no syntax errors in the block of text.

If no one else steps up by mid- next week I can look at this bug, but my time 
is booked until July 27th at the earliest.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: CouchDB 2.0 blog series

[Joan Touzet]

Hi Jenn,

I'll write about Release Candidates, as long as I can get a sentence
or two in about the Windows port I just completed. :) I won't be
available to write the post until August, though.

Thanks,
Joan

- Original Message -
> From: "Jenn Turner" 
> To: market...@couchdb.apache.org
> Cc: dev@couchdb.apache.org
> Sent: Wednesday, July 20, 2016 11:53:47 AM
> Subject: Re: CouchDB 2.0 blog series
> 
> Also, thank you Tony, Garren and Robert for volunteering!
> 
> That means we need volunteers for
> 
> - Release Candidates
> - Migration Guide
> - Feature: compactor
> - Feature: replicator
> - Misc features/bug fixes
> 
> Anyone else want to chip in and write a post?
> 
> 
> On Wed, Jul 20, 2016 at 3:40 AM, Robert Newson 
> wrote:
> 
> > The architecture one makes most sense
> >
> > Sent from my iPhone
> >
> > > On 19 Jul 2016, at 21:07, Jenn Turner 
> > > wrote:
> > >
> > > Hello there!
> > >
> > > We’re getting closer to releasing CouchDB 2.0 and leading up to
> > > its
> > official
> > > release, we want to publish a series of blog posts examining
> > > topics like
> > the
> > > history of the project, differences between the 2.0 and 1.0
> > > architecture,
> > > unpacking the new features, and so forth.
> > >
> > > To accomplish this **we need your help**, we need 7-8 CouchDB
> > > users to
> > help
> > > write these posts. Don’t worry, we’re not after Shakespeare here,
> > > just
> > > introducing an idea in 200-300 words, to get folks interested in
> > > CouchDB
> > 2.0.
> > > I’ll be available to help with editing and coordinating the
> > > publication
> > > schedule.
> > >
> > > Ideally, we’ll be able to release two posts a week, one on Monday
> > > and
> > > Wednesday, with the weekly news still going out on Thursdays, so
> > > we’re
> > not
> > > over saturating the blog. Jan Lehnardt has volunteered to kick
> > > off the
> > series
> > > next week, with a post on the The Road to CouchDB 2.0 on Monday.
> > >
> > > That means we need a volunteer to write one for next Wednesday,
> > > July 27.
> > We’re
> > > still tossing around ideas for giving the 7-8 authors of these
> > > posts a
> > special
> > > kind of CouchDB swag, if that helps. :)
> > >
> > > Below is a list of topics (also important: if you have an idea
> > > for a
> > topic you
> > > **don’t see** below, please let us know!):
> > >
> > > **The Road to CouchDB 2.0**: (Jan)
> > > \- History of the big Couch fork
> > > \- Cloudant
> > > \- Big Couch merge announcement
> > > \- Davisphack (rnewson on the couch)
> > > \- Windsor merge
> > > \- New build system
> > > \- Cluster setup
> > > \- Tests! Tests! Tests!
> > > \- RC1
> > >
> > > **The CouchDB 2.0 Architecture**: (need volunteer)
> > > \- Dynamo
> > > \- BigCouch
> > > \- Cluster/Shards/Consistency
> > >
> > > **Release Candidates**: (need volunteer)
> > > \- Please test:
> > > \- Install
> > >  \- 1 node
> > >  \- 3 node
> > >  \- n node
> > > \- App Devs & Library devs:
> > > \- Run your software against each
> > > \- Fix any issues on your side
> > > \- Report any issues to us
> > >
> > > **Migration Guide**: (need volunteer)
> > > \- 99% is the same
> > > \- update_seq is opaque string now
> > > \- Changes feed can include duplicates
> > > \- JS apps using /_utils/*.js: copy 1.6 files and put into your
> > > apps
> > > \- /_config is not available on the cluster, but there is
> > /_node//
> > > _config/ for your setup needs, make sure you do it on all nodes
> > > \- Test suites:
> > > \- If you are creating and deleting databases in quick
> > > succession, start
> > using
> > > unique db names (and add cleanup)
> > >
> > > New features posts
> > > \- **Feature: compactor** (need volunteer)
> > > \- faster
> > > \- lower i/o
> > > \- more compact files
> > > \- faster post compaction files
> > >
> > > \- **Feature: replicator** (need volunteer)
> > > \- TBD
> > >
> > > \- **Feature: fauxton** (need volunteer)
> > > \- Complete rewrite
> > > \- First Backbone
> > > \- Now React
> > > \- Extendable
> > >
> > > \- **Feature: Mango query** (need volunteer)
> > > \- Import from Cloudant Query
> > > \- MongoDB-inspired query language
> > > \- Create indexes
> > > \- Query patterns
> > >
> > > \- **Miscellaneous improvements and bugfixes** (need volunteer)
> > > \- /_db_updates gets persisted, supports ?since like changes
> > > \- Preview: view based changes
> > > \- Uses rebar under the hood for building, ditched autotools \o/
> > >
> > > Also, if you have an idea of someone who would be a good
> > > candidate to
> > write
> > > one of these blog posts, let me know so I can reach out to them.
> > >
> > > Please help us get the community excited for the changes coming
> > > to
> > CouchDB. :D
> > > :D :D
> > >
> > > Cheers!
> > >
> > >
> > > Jenn Turner
> > >
> > > The Neighbourhoodie Software GmbH
> > > Adalbertstr. 7-8, 10999 Berlin
> > > [neighbourhood.ie](https://link.nylas.com/link/c4yg26doe3du1m7gpdgdrj1jp
> > > /local-eda5af1b-
> > >
> > bbb8/0?redirect=http%3A%2F%2Fn

Re: CouchDB 2.0 blog series

[Joan Touzet]

Hi Jenn,

I'll write about Release Candidates, as long as I can get a sentence
or two in about the Windows port I just completed. :) I won't be
available to write the post until August, though.

Thanks,
Joan

- Original Message -
> From: "Jenn Turner" 
> To: marketing@couchdb.apache.org
> Cc: d...@couchdb.apache.org
> Sent: Wednesday, July 20, 2016 11:53:47 AM
> Subject: Re: CouchDB 2.0 blog series
> 
> Also, thank you Tony, Garren and Robert for volunteering!
> 
> That means we need volunteers for
> 
> - Release Candidates
> - Migration Guide
> - Feature: compactor
> - Feature: replicator
> - Misc features/bug fixes
> 
> Anyone else want to chip in and write a post?
> 
> 
> On Wed, Jul 20, 2016 at 3:40 AM, Robert Newson 
> wrote:
> 
> > The architecture one makes most sense
> >
> > Sent from my iPhone
> >
> > > On 19 Jul 2016, at 21:07, Jenn Turner 
> > > wrote:
> > >
> > > Hello there!
> > >
> > > We’re getting closer to releasing CouchDB 2.0 and leading up to
> > > its
> > official
> > > release, we want to publish a series of blog posts examining
> > > topics like
> > the
> > > history of the project, differences between the 2.0 and 1.0
> > > architecture,
> > > unpacking the new features, and so forth.
> > >
> > > To accomplish this **we need your help**, we need 7-8 CouchDB
> > > users to
> > help
> > > write these posts. Don’t worry, we’re not after Shakespeare here,
> > > just
> > > introducing an idea in 200-300 words, to get folks interested in
> > > CouchDB
> > 2.0.
> > > I’ll be available to help with editing and coordinating the
> > > publication
> > > schedule.
> > >
> > > Ideally, we’ll be able to release two posts a week, one on Monday
> > > and
> > > Wednesday, with the weekly news still going out on Thursdays, so
> > > we’re
> > not
> > > over saturating the blog. Jan Lehnardt has volunteered to kick
> > > off the
> > series
> > > next week, with a post on the The Road to CouchDB 2.0 on Monday.
> > >
> > > That means we need a volunteer to write one for next Wednesday,
> > > July 27.
> > We’re
> > > still tossing around ideas for giving the 7-8 authors of these
> > > posts a
> > special
> > > kind of CouchDB swag, if that helps. :)
> > >
> > > Below is a list of topics (also important: if you have an idea
> > > for a
> > topic you
> > > **don’t see** below, please let us know!):
> > >
> > > **The Road to CouchDB 2.0**: (Jan)
> > > \- History of the big Couch fork
> > > \- Cloudant
> > > \- Big Couch merge announcement
> > > \- Davisphack (rnewson on the couch)
> > > \- Windsor merge
> > > \- New build system
> > > \- Cluster setup
> > > \- Tests! Tests! Tests!
> > > \- RC1
> > >
> > > **The CouchDB 2.0 Architecture**: (need volunteer)
> > > \- Dynamo
> > > \- BigCouch
> > > \- Cluster/Shards/Consistency
> > >
> > > **Release Candidates**: (need volunteer)
> > > \- Please test:
> > > \- Install
> > >  \- 1 node
> > >  \- 3 node
> > >  \- n node
> > > \- App Devs & Library devs:
> > > \- Run your software against each
> > > \- Fix any issues on your side
> > > \- Report any issues to us
> > >
> > > **Migration Guide**: (need volunteer)
> > > \- 99% is the same
> > > \- update_seq is opaque string now
> > > \- Changes feed can include duplicates
> > > \- JS apps using /_utils/*.js: copy 1.6 files and put into your
> > > apps
> > > \- /_config is not available on the cluster, but there is
> > /_node//
> > > _config/ for your setup needs, make sure you do it on all nodes
> > > \- Test suites:
> > > \- If you are creating and deleting databases in quick
> > > succession, start
> > using
> > > unique db names (and add cleanup)
> > >
> > > New features posts
> > > \- **Feature: compactor** (need volunteer)
> > > \- faster
> > > \- lower i/o
> > > \- more compact files
> > > \- faster post compaction files
> > >
> > > \- **Feature: replicator** (need volunteer)
> > > \- TBD
> > >
> > > \- **Feature: fauxton** (need volunteer)
> > > \- Complete rewrite
> > > \- First Backbone
> > > \- Now React
> > > \- Extendable
> > >
> > > \- **Feature: Mango query** (need volunteer)
> > > \- Import from Cloudant Query
> > > \- MongoDB-inspired query language
> > > \- Create indexes
> > > \- Query patterns
> > >
> > > \- **Miscellaneous improvements and bugfixes** (need volunteer)
> > > \- /_db_updates gets persisted, supports ?since like changes
> > > \- Preview: view based changes
> > > \- Uses rebar under the hood for building, ditched autotools \o/
> > >
> > > Also, if you have an idea of someone who would be a good
> > > candidate to
> > write
> > > one of these blog posts, let me know so I can reach out to them.
> > >
> > > Please help us get the community excited for the changes coming
> > > to
> > CouchDB. :D
> > > :D :D
> > >
> > > Cheers!
> > >
> > >
> > > Jenn Turner
> > >
> > > The Neighbourhoodie Software GmbH
> > > Adalbertstr. 7-8, 10999 Berlin
> > > [neighbourhood.ie](https://link.nylas.com/link/c4yg26doe3du1m7gpdgdrj1jp
> > > /local-eda5af1b-
> > >
> > bbb8/0?redirect=http%3A%2F%2F

[jira] [Commented] (COUCHDB-3040) Support CouchDB 2.0 release on Windows

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384455#comment-15384455
 ] 

Joan Touzet commented on COUCHDB-3040:
--

I have completed work on the WiX-based installer and have released an 
unofficial 2.0 RC1 installer at https://atypical.net/mm/couchdb-2.0.0-rc1.msi .

Please note the following known issues:

* Logs only to the console window for now.
* No Windows Service is created, as logs would be unavailable.

Once the logging issue is worked out I'll try and release a new installer build 
with a Windows Service installation. My time this week is extremely limited so 
this may not happen until next week at the earliest.

> Support CouchDB 2.0 release on Windows
> --
>
> Key: COUCHDB-3040
> URL: https://issues.apache.org/jira/browse/COUCHDB-3040
> Project: CouchDB
>  Issue Type: Task
>  Components: Build System
>Affects Versions: 2.0.0
>Reporter: Joan Touzet
>Assignee: Joan Touzet
>Priority: Blocker
>  Labels: windows
> Fix For: 2.0.0
>
>
> As the title says. Tasks to be completed:
> # Complete release/couchdb_2.0 -> master PR on dch/glazier
> # Migrate the dch/glazier repo into the new ASF couchdb-glazier repo
> # -Port couchdb/Makefile to work via gnuwin32 gnumake format- done
> # -Squash remaining bugs- done, tests all pass now
> # -Import and support WiX installer (Joan has for 1.x, needs updating for 
> 2.0)- done



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

2.0 Windows Installer RC1

[Joan Touzet]

Hi everyone,

https://atypical.net/mm/couchdb-2.0.0-rc1.msi

is an unofficial Windows 2.0.0 RC1 installer. Please note the 
following known issues:

  * Logs only to the console window for now.
  * No Windows Service is created, as logs would be unavailable.

Once the logging issue is worked out I'll try and release a 
new installer build with a Windows Service installation. My time
this week is extremely limited so this may not happen until
next week at the earliest.

Steps used to create this installer are detailed at

https://github.com/dch/glazier/blob/release/couchdb_2.0/README.md

This repository will be moved into ASF infrastructure shortly.

Enjoy,
Joan Touzet

Re: New contributor need help

[Joan Touzet]

Hi Harald,

While your point is taken - we need better documentation on how to get
new developers on board - I'd like to take issue with you saying that
some tests are failing.

As far as I know, the JavaScript tests right now 100% pass on both
Linux and Windows for me and for the rest of the core development team.
You run these by typing

$ make all javascript (Linux)

or

C:\relax\couchdb> make -f Makefile.win all javascript

and look for all the  statements (hopefully!)

If you have a failing test or tests, could you please post which ones
are failing here, and include a link to the log of your test output?
(Preferably use a site like https://paste.apache.org/ or
http://gist.github.com instead of pasting your entire logfile to the
mailing list.)

We can then help direct you at the JS file(s) you need to review to 
understand what may be wrong.

And as Jan said, please be sure you have the latest tarball to look at, 
or if you know how to use git, cloned from our apache/couchdb repository
(master branch). We've recently fixed a couple of failing tests and you
may be seeing issues we've already resolved.

Best,
Joan Touzet

[jira] [Commented] (COUCHDB-3040) Support CouchDB 2.0 release on Windows

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15382012#comment-15382012
 ] 

Joan Touzet commented on COUCHDB-3040:
--

As of the latest checkin to master, everything in {{make release}} works. The 
make process now creates a relocatable CouchDB 2.0 installation, complete with 
Fauxton and documentation.

I'm going to get some sleep (hopefully), and later today I'll look at 
completing the installer framework. Once we have a suitable Windows package 
being generated, I'll complete steps 1 and 2 and get this ticket closed out.

> Support CouchDB 2.0 release on Windows
> --
>
> Key: COUCHDB-3040
> URL: https://issues.apache.org/jira/browse/COUCHDB-3040
> Project: CouchDB
>  Issue Type: Task
>  Components: Build System
>Affects Versions: 2.0.0
>Reporter: Joan Touzet
>Assignee: Joan Touzet
>Priority: Blocker
>  Labels: windows
> Fix For: 2.0.0
>
>
> As the title says. Tasks to be completed:
> # Complete release/couchdb_2.0 -> master PR on dch/glazier
> # Migrate the dch/glazier repo into the new ASF couchdb-glazier repo
> # -Port couchdb/Makefile to work via gnuwin32 gnumake format- done
> # -Squash remaining bugs- done, tests all pass now
> # Import and support WiX installer (Joan has for 1.x, needs updating for 2.0)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 2.0 & Windows: status update (all tests passing)

[Joan Touzet]

Trimming the long thread for readability...

Good news, everyone! As of the latest checkin to master, CouchDB 2.0
builds correctly on Windows 64-bit! All eunit and javascript tests
pass (or are skipped intentionally). 

This is a huge milestone! I especially want to thank Nick North and
Dave Cottlehuber for helping me get this far.

What's left is that rebar generate fails completely. Until this is
working I can't generate a full release build, I can't finish the
installer work, and I don't want to push dch/glazier into
asf/couchdb-glazier until all of that is complete.

Still, we're in the home stretch.

-Joan

[jira] [Commented] (COUCHDB-3040) Support CouchDB 2.0 release on Windows

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380268#comment-15380268
 ] 

Joan Touzet commented on COUCHDB-3040:
--

As of the latest commit to the couchdb repo (660c32f), couchdb builds cleanly 
on Windows 64-bit. All tests (eunit and javascript) pass. Hooray!

What's left is that {{rebar generate}} fails completely. Until this is working 
I can't generate a full release build, I can't finish the installer work, and I 
don't want to push dch/glazier into asf/couchdb-glazier until all of that is 
complete.

Still, we're in the home stretch. I couldn't have done it without the help of 
[~dch] and [~nicknorth], special thanks to you both!

> Support CouchDB 2.0 release on Windows
> --
>
> Key: COUCHDB-3040
> URL: https://issues.apache.org/jira/browse/COUCHDB-3040
> Project: CouchDB
>  Issue Type: Task
>  Components: Build System
>    Affects Versions: 2.0.0
>Reporter: Joan Touzet
>Assignee: Joan Touzet
>Priority: Blocker
>  Labels: windows
> Fix For: 2.0.0
>
>
> As the title says. Tasks to be completed:
> # Complete release/couchdb_2.0 -> master PR on dch/glazier
> # Migrate the dch/glazier repo into the new ASF couchdb-glazier repo
> # -Port couchdb/Makefile to work via gnuwin32 gnumake format- done
> # -Squash remaining bugs- done, tests all pass now
> # Import and support WiX installer (Joan has for 1.x, needs updating for 2.0)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2791) Allow for direct parallel access to shards via _changes

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376034#comment-15376034
 ] 

Joan Touzet commented on COUCHDB-2791:
--

The initial change set does seem small, and it's pleasing that it didn't take 
more work to open up these new endpoints.

Is it wrong of me to ask that you submit some working test cases along with the 
actual implementation itself before we merge this? It would be a nice precedent 
to start setting for ourselves.

> Allow for direct parallel access to shards via _changes
> ---
>
> Key: COUCHDB-2791
> URL: https://issues.apache.org/jira/browse/COUCHDB-2791
> Project: CouchDB
>  Issue Type: New Feature
>  Components: Database Core
>Reporter: Tony Sun
>Assignee: Tony Sun
>
> For performance gains, we introduce a new _changes feed option parallel that 
> returns a list of urls that the user can use to directly access individual 
> shards. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 2.0 & Windows: status update

[Joan Touzet]

I took a look at the eunit failures and found that the entire
couchdb_os_daemon_test module fails due to issues with how it expects
to launch daemons.

The main issue is that the primary test harness is a .escript file, which
on *nix is magically parsed via the #!/usr/bin/escript header. On Windows
we are just trying to directly launch the .escript file which fails (since
Windows has no idea how to execute *.escript files). There are also .sh
scripts that are part of the test harness that will not run correctly.

I've submitted a PR to simply bypass this entire test module for now. It
sure would be swell to make it work but it'll be a fair bit of fiddling,
especially in a way that makes eunit happy, to get it to work.

Besides, there are other tests that drive the mrview os daemon; we will
see massive failures in the JS test suite if the entire os daemon launching
process fails.

https://github.com/apache/couchdb-couch/pull/184 hopefully will land soon
allowing the main couch eunit tests to pass.

More worryingly we have a failure in jiffy on Windows:

https://gist.github.com/anonymous/c796d4b048efa90b17b1f43008c59783#file-gistfile1-txt-L381-L389

Anyone who can help look at this one? (Paul?)

-Joan

- Original Message -----
From: "Joan Touzet" 
To: dev@couchdb.apache.org
Sent: Tuesday, July 12, 2016 6:02:12 PM
Subject: Re: 2.0 & Windows: status update

Thanks, Paul. I'm starting to look at this today.

In better news, current Windows JS tests now match the *nix JS test results.
Only one test, replication.js, is failing (ignoring the ignored tests).

Results: https://gist.github.com/anonymous/8e236848a89af440d3c56569e81f4829

Mr. Newson is looking at this failure right now and says we may be able
to improve upon the testing methodology.

-Joan

- Original Message -
From: "Paul Davis" 
To: dev@couchdb.apache.org
Sent: Tuesday, July 12, 2016 4:37:15 PM
Subject: Re: 2.0 & Windows: status update

The logs posted at [1] show that we're seeing OS processes die with an
exit code of 4. The most likely place I can find that that comes from
is couchspawnkillable_win.c [2] which is nicely Windows specific so
would do a lot to explain why we don't see it on *nix systems.
Unfortunately other than pointing out that the subprocess creation
seems to fail I don't have any idea or suggestion on how to debug
further.

[1] https://gist.github.com/anonymous/f2a94234195f007c3049e27d942482c1
[2] 
https://github.com/apache/couchdb-couch/blob/master/priv/spawnkillable/couchspawnkillable_win.c#L106

On Wed, Jun 29, 2016 at 4:21 PM, Sebastian Rothbucher
 wrote:
> Hi all,
>
> just to follow up on that: there is another PR coming up (
> https://github.com/apache/couchdb/pull/427) that tests for some more fixes
> and brings even more stability. In the meantime, deleting dev/lib is indeed
> the best way to produce reliable results. So is switching between
> auth-tests-wip and master. But there's progress => it might all end up
> nicely on master.
>
> Good luck, thanks & best
> Sebastian
>
>
> On Mon, Jun 20, 2016 at 5:26 PM, Nick North  wrote:
>
>> Thanks Sebastian. I'm looking at eunit at the moment, but hope to come back
>> to these.
>>
>> Nick
>>
>> On Sun, 19 Jun 2016 at 23:01 Sebastian Rothbucher <
>> sebastianrothbuc...@googlemail.com> wrote:
>>
>> > Hi Joan, Nick,
>> >
>> > the following gist provides a current run of the test against the latest
>> > master of CouchDB - and the latest tests (from the auth-tests-wip
>> branch):
>> >
>> >
>> https://gist.github.com/sebastianrothbucher/efa3a992bd4de9996b4125da82a7e0de
>> > Maybe you can use them
>> >
>> > Here's what I did to get both latest tests and latest code:
>> > git checkout master
>> > ./configure -c --disable-docs --disable-fauxton
>> > make clean
>> > make
>> > git checkout auth-tests-wip
>> >
>> > Currently, make javascript seems not optimal as one tests (needs
>> > investigation) seems to mess up the setup for all that's following.
>> Hence,
>> > I took this drastic measure to produce the logs:
>> >
>> > for t in test/javascript/tests/*.js; do rm -rf dev/lib; dev/run -n 1 -q
>> > --with-admin-party-please test/javascript/run $t 2>&1 | tee -a
>> jstest2.log;
>> > done
>> >
>> > Maybe it makes sense for you to start w/ something similar to produce
>> some
>> > meaningful results.
>> >
>> > Best
>> >Sebastian
>> >
>> > On Sun, Jun 19, 2016 at 6:04 PM, Nick North  wrote:
>> >
>> > > Sorry - I meant a single node cluster in that last message. And I mea

Re: 2.0 & Windows: status update

[Joan Touzet]

Thanks, Paul. I'm starting to look at this today.

In better news, current Windows JS tests now match the *nix JS test results.
Only one test, replication.js, is failing (ignoring the ignored tests).

Results: https://gist.github.com/anonymous/8e236848a89af440d3c56569e81f4829

Mr. Newson is looking at this failure right now and says we may be able
to improve upon the testing methodology.

-Joan

- Original Message -
From: "Paul Davis" 
To: dev@couchdb.apache.org
Sent: Tuesday, July 12, 2016 4:37:15 PM
Subject: Re: 2.0 & Windows: status update

The logs posted at [1] show that we're seeing OS processes die with an
exit code of 4. The most likely place I can find that that comes from
is couchspawnkillable_win.c [2] which is nicely Windows specific so
would do a lot to explain why we don't see it on *nix systems.
Unfortunately other than pointing out that the subprocess creation
seems to fail I don't have any idea or suggestion on how to debug
further.

[1] https://gist.github.com/anonymous/f2a94234195f007c3049e27d942482c1
[2] 
https://github.com/apache/couchdb-couch/blob/master/priv/spawnkillable/couchspawnkillable_win.c#L106

On Wed, Jun 29, 2016 at 4:21 PM, Sebastian Rothbucher
 wrote:
> Hi all,
>
> just to follow up on that: there is another PR coming up (
> https://github.com/apache/couchdb/pull/427) that tests for some more fixes
> and brings even more stability. In the meantime, deleting dev/lib is indeed
> the best way to produce reliable results. So is switching between
> auth-tests-wip and master. But there's progress => it might all end up
> nicely on master.
>
> Good luck, thanks & best
> Sebastian
>
>
> On Mon, Jun 20, 2016 at 5:26 PM, Nick North  wrote:
>
>> Thanks Sebastian. I'm looking at eunit at the moment, but hope to come back
>> to these.
>>
>> Nick
>>
>> On Sun, 19 Jun 2016 at 23:01 Sebastian Rothbucher <
>> sebastianrothbuc...@googlemail.com> wrote:
>>
>> > Hi Joan, Nick,
>> >
>> > the following gist provides a current run of the test against the latest
>> > master of CouchDB - and the latest tests (from the auth-tests-wip
>> branch):
>> >
>> >
>> https://gist.github.com/sebastianrothbucher/efa3a992bd4de9996b4125da82a7e0de
>> > Maybe you can use them
>> >
>> > Here's what I did to get both latest tests and latest code:
>> > git checkout master
>> > ./configure -c --disable-docs --disable-fauxton
>> > make clean
>> > make
>> > git checkout auth-tests-wip
>> >
>> > Currently, make javascript seems not optimal as one tests (needs
>> > investigation) seems to mess up the setup for all that's following.
>> Hence,
>> > I took this drastic measure to produce the logs:
>> >
>> > for t in test/javascript/tests/*.js; do rm -rf dev/lib; dev/run -n 1 -q
>> > --with-admin-party-please test/javascript/run $t 2>&1 | tee -a
>> jstest2.log;
>> > done
>> >
>> > Maybe it makes sense for you to start w/ something similar to produce
>> some
>> > meaningful results.
>> >
>> > Best
>> >Sebastian
>> >
>> > On Sun, Jun 19, 2016 at 6:04 PM, Nick North  wrote:
>> >
>> > > Sorry - I meant a single node cluster in that last message. And I meant
>> > to
>> > > sign my name correctly.
>> > >
>> > > Nick
>> > >
>> > > On Sun, 19 Jun 2016 at 16:56 Nick North  wrote:
>> > >
>> > > > I'm trying these tests now, and find that there are still a lot of JS
>> > > > failures with a single cluster. Many of them look suspiciously
>> similar
>> > at
>> > > > an initial glance, but I hope to look in more detail tomorrow.
>> > > >
>> > > > Nicj
>> > > >
>> > > > On Sun, 19 Jun 2016 at 15:20 Jan Lehnardt  wrote:
>> > > >
>> > > >>
>> > > >> > On 17 Jun 2016, at 22:48, Joan Touzet  wrote:
>> > > >> >
>> > > >> > Hello everyone,
>> > > >> >
>> > > >> > I'd like to update the community on the status of the 2.0 port to
>> > > >> Microsoft Windows. There are three parts to this email: the build
>> > > >> tools/chain themselves, support in CouchDB for the Windows build
>> > > process,
>> > > >> and testing results. I'll cover them in that order.
>> > > >> >
>> > > >> > 

Re: Couchdb logging

[Joan Touzet]

Hi Michael,

The 0.6257.467 part is the Erlang PID processing the result.

Your best bet to time the duration of the request is to use haproxy
ahead of CouchDB itself, and use haproxy's extensive logging features to
get the timings you desire.

Best regards,
Joan Touzet

- Original Message -
> From: "Michael Power" 
> To: user@couchdb.apache.org
> Sent: Monday, July 11, 2016 6:20:29 PM
> Subject: Couchdb logging
> 
> Hello,
> 
> I noticed couchdb logging looks like:
> [Mon, 11 Jul 2016 13:33:36 GMT] [info] [<0.6257.467>] ###.###.###.###
> - - METHOD PATH RESULT
> 
> I was wondering, if the 0.6257.467 is the duration of the request?
>  If not, is it possible to reconfigure the couchdb log format to
> include the duration of the request?
> 
> Michael Power
> Software Architect
> EloTouch Solutions
> 
> 

Re: [DISCUSSION] Limiting the allowed size for documents

[Joan Touzet]

- Original Message -
> Couch 1.x and Couch 2.x will choke as soon as the indexer tries to
> process a too large document that was added. The indexing stops and
> you have to manually remove the doc. In the best case you built an
> automatic process around the process. The automatic process removes
> the document instead of the human.

I've known about this problem for years, but never did anything.
Thank you for taking the initiative here, Robert.

I think flat out rejecting documents that are too big, with that value set
in the ini file, is the right move if we can't fix the underlying couchjs
issue. 

As for what is "too big," do you have empirical data from Cloudant as to a
recommendation? I've seen documents at Cloudant as small as 24MB cause issues
with couchjs views, personally.

-Joan

Re: Need help on this "badmatch" error of couchdb 2.0

[Joan Touzet]

Hi Ying,

It's the beam.smp process that is the main couchdb process. The
other processes:

  epmd: Erlang port mapper daemon, acts as a name server for other
Erlang hosts
  beam.smp: BEAM, the Erlang Virtual Machine, where couchdb runs
  cpu_sup: Erlang CPU supervisor process
  couchjs: The CouchDB view server process, where your Javascript 
map/reduce views execute and are built/maintained. You have
2o f these running.

> Another question, how did you know that the error is EMFILE? I did
> not see this even by skimming through the code.

It's right here:

> >> {"status":500,"name":"badmatch","message":"Database encountered an
> >> unknown
> >> error","reason":"{error,{badmatch,{error,{{badmatch,{error,emfile}},

The {error,emfile} says that the OS has passed up an EMFILE error. I know
what this error is from (on Linux) running `man errno`, which lists:

   EMFILE  Too many open files (POSIX.1)

The error code emfile isn't in CouchDB itself because we don't explicitly
check for it - as we consider that a configuration error, not a database
fault.

All the best,
Joan

Re: Need help on this "badmatch" error of couchdb 2.0

[Joan Touzet]

Ying,

Looks like your error is EMFILE, meaning too many open files as returned
by the operating system.

On OSX it appears you can up the limit:

http://stackoverflow.com/questions/5377450/maximum-number-of-open-filehandles-per-process-on-osx-and-how-to-increase

Try the command(s) listed there and see if this fixes your problem.

Good luck,
Joan

- Original Message -
> From: "Ying Bian" 
> To: user@couchdb.apache.org
> Sent: Wednesday, June 29, 2016 6:09:11 PM
> Subject: Need help on this "badmatch" error of couchdb 2.0
> 
> Hi,
> 
> I'm developing a web application using couchdb 2.0 dev build (version
> is '9d28c57' at this time) as the database.  Sometimes when I do a
> simple query against a simple view using pouchdb api, I got the
> following error emitted by couchdb (I've tried to prettify the
> output by replacing '\n' with hard newline). When the error happens,
> if I wait for a few minutes and try again, it may work again. But
> this is definitely something that I need to worry about as it looks
> like something fundamental with couchdb.
> 
> This happens in my local Mac machine. The only special thing about my
> setup is that there are about 70+ small databases created, but my
> query is against only one of those. Let me know if you have any
> idea. I can upgrade to the latest build if you think that may help,
> but I doubt that as I upgraded several times before but things did
> not change.
> 
> The error stack:
> 
> {"status":500,"name":"badmatch","message":"Database encountered an
> unknown
> error","reason":"{error,{badmatch,{error,{{badmatch,{error,emfile}},
> [{couch_file,init,1,
> [{file,\"src/couch_file.erl\"},{line,336}]},
> {gen_server,init_it,6,
> [{file,\"gen_server.erl\"},{line,328}]},
> {proc_lib,init_p_do_apply,3,
> [{file,\"proc_lib.erl\"},{line,240}]}]}},
> [{couch_index_server,get_index,4,
> [{file,\"src/couch_index_server.erl\"},
> {line,97}]},
> {couch_mrview_util,get_view,4,
> [{file,\"src/couch_mrview_util.erl\"},
> {line,47}]},
> {couch_mrview,query_view,6,
> [{file,\"src/couch_mrview.erl\"},{line,244}]},
> {rexi_server,init_p,3,
> [{file,\"src/rexi_server.erl\"},{line,139}]}]}}"}
> 
> -Ying

Item for the newsletter

[Joan Touzet]

Someone came into IRC #couchdb today and told us about their open
sourced Slack clone they built based on CouchDB:

https://github.com/cicakhq/potato

-Joan

Re: 2.0 & Windows: status update

[Joan Touzet]

*facepalm* :) Nothing private, just...didn't want to clutter the list.

Sorry!

- Original Message -
> From: "Joan Touzet" 
> To: dev@couchdb.apache.org
> Sent: Saturday, June 18, 2016 3:56:50 AM
> Subject: Re: 2.0 & Windows: status update
> 
> Replying off list.
[SNIP]

Re: 2.0 & Windows: status update

[Joan Touzet]

Replying off list.

Nick be sure you get my patch to the couchdb repo itself before you test:

  https://github.com/apache/couchdb/pull/423/files

I'll be reworking this slightly to make Ilya happy but the PR works 
in its current state.

-Joan

- Original Message -
> From: "Nick North" 
> To: dev@couchdb.apache.org, "Joan Touzet" 
> Sent: Saturday, June 18, 2016 3:37:50 AM
> Subject: Re: 2.0 & Windows: status update
> 
> Hi Joan. This sounds like an improvement on my last Windows build
> attempt,
> which still had a couple of eunit failures outside the os_process
> area.
> I'll attempt to reproduce your results today, and report back.
> 
> Nick
> 
> On Sat, 18 Jun 2016 at 00:34 Joan Touzet  wrote:
> 
> > Replying to my own email: dev/run is using the wrong path slashes
> > for
> > the path to the javascript/coffeescript view servers. I've
> > submitted a PR
> > and will merge if no one complains.
> >
> > Here is the latest set of test results if anyone still wants to
> > volunteer
> > to help me review them (both Eunit and JS, scroll down for the JS
> > results):
> >
> >   https://gist.github.com/wohali/256d134dea8e79c2050636c7ff044c23
> >
> > I'm especially worried about the few JS tests we're failing, those
> > seem
> > subtle. I need a Linux baseline to compare against. If no one has
> > one, I
> > can see I'll be setting up my own Linux build environment on
> > Monday...
> >
> > -Joan
> >
> 

Re: 2.0 & Windows: status update

[Joan Touzet]

Replying to my own email: dev/run is using the wrong path slashes for
the path to the javascript/coffeescript view servers. I've submitted a PR
and will merge if no one complains.

Here is the latest set of test results if anyone still wants to volunteer
to help me review them (both Eunit and JS, scroll down for the JS results):

  https://gist.github.com/wohali/256d134dea8e79c2050636c7ff044c23

I'm especially worried about the few JS tests we're failing, those seem
subtle. I need a Linux baseline to compare against. If no one has one, I 
can see I'll be setting up my own Linux build environment on Monday...

-Joan

Re: Extra reference in a commit message

[Joan Touzet]

No objection from me, if it makes things easier for you - as long as you
are aware that you may get requests from customers saying "Hey, I see
you used my bug tracker ticket id # in a CouchDB commit..." ;)

-Joan

- Original Message -
From: "Ilya Khlopotov" 
To: dev@couchdb.apache.org
Sent: Friday, June 17, 2016 7:07:22 PM
Subject: Extra reference in a commit message


Hello,

We at Cloudant using our own bug tracker. Quite often we have two tickets
opened for the same problem.
One ticket is in ASF JIRA and another one in our internal bug tracker.
We have some automation, which compiles the issues we worked on in a
current release cycle.
However, it is extremely challenging to get it working right. Since it
needs to consult two independent trackers with no link between them.
We are considering adding a second reference in a commit message.

Does anyone have a strong opinion against it?
Would these unrelated references be too annoying for the community?

Best regards,
ILYA Khlopotov

[jira] [Created] (COUCHDB-3041) boot_node:monitor_parent shells to nonexistant kill cmd

[Joan Touzet (JIRA)]

Joan Touzet created COUCHDB-3041:


 Summary: boot_node:monitor_parent shells to nonexistant kill cmd
 Key: COUCHDB-3041
 URL: https://issues.apache.org/jira/browse/COUCHDB-3041
 Project: CouchDB
  Issue Type: Sub-task
  Components: Database Core
Reporter: Joan Touzet


See https://github.com/apache/couchdb/blob/master/dev/boot_node.erl#L30-L38 for 
the ugly.

There is no direct kill -0 equivalent on Windows. Instead we get something like 
{{tasklist /fi "PID eq 1234"}} which doesn't return an error code != 0 if a 
match is not found, we actually have to parse the output returned. Bleah.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 2.0 & Windows: status update

[Joan Touzet]

A small update on the testing front. I've tried replicating the animaldb from
Cloudant to my local server, and things looked very ugly:

https://gist.github.com/anonymous/f2a94234195f007c3049e27d942482c1

I've yet to dig into this failure; I'm posting it here in case anyone has the
time to analyze it on my behalf. (I have about 2 more hours in my work day
today and I have other things to attend to...)

-Joan

[jira] [Commented] (COUCHDB-3040) Support CouchDB 2.0 release on Windows

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15336966#comment-15336966
 ] 

Joan Touzet commented on COUCHDB-3040:
--

Adding a mention of [~dch] and [~nicknorth] so that they get email notification 
of this task. 

We can split this up into sub-tasks if anyone wants to bite off part of the 
work to be completed, especially that of fixing particular failing test cases.

I'd prefer to own steps 1, 3 and 5, but am happy for help with the other line 
items if anyone is so motivated.

> Support CouchDB 2.0 release on Windows
> --
>
> Key: COUCHDB-3040
> URL: https://issues.apache.org/jira/browse/COUCHDB-3040
> Project: CouchDB
>  Issue Type: Task
>  Components: Build System
>Affects Versions: 2.0.0
>Reporter: Joan Touzet
>Assignee: Joan Touzet
>Priority: Blocker
>  Labels: windows
>
> As the title says. Tasks to be completed:
> # Complete release/couchdb_2.0 -> master PR on dch/glazier
> # Migrate the dch/glazier repo into the new ASF couchdb-glazier repo
> # Port couchdb/Makefile to couchdb/Makefile.win (NMake format)
> # Squash remaining bugs
> # Import and support WiX installer (Joan has for 1.x, needs updating for 2.0)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COUCHDB-3040) Support CouchDB 2.0 release on Windows

[Joan Touzet (JIRA)]

Joan Touzet created COUCHDB-3040:


 Summary: Support CouchDB 2.0 release on Windows
 Key: COUCHDB-3040
 URL: https://issues.apache.org/jira/browse/COUCHDB-3040
 Project: CouchDB
  Issue Type: Task
  Components: Build System
Reporter: Joan Touzet


As the title says. Tasks to be completed:

# Complete release/couchdb_2.0 -> master PR on dch/glazier
# Migrate the dch/glazier repo into the new ASF couchdb-glazier repo
# Port couchdb/Makefile to couchdb/Makefile.win (NMake format)
# Squash remaining bugs
# Import and support WiX installer (Joan has for 1.x, needs updating for 2.0)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COUCHDB-1644) make distcheck should work on Windows too

[Joan Touzet (JIRA)]

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

Joan Touzet resolved COUCHDB-1644.
--
Resolution: Won't Fix

Build system is changing for 2.0 and there is no longer a distcheck. Reopen if 
you disagree.

> make distcheck should work on Windows too
> -
>
> Key: COUCHDB-1644
> URL: https://issues.apache.org/jira/browse/COUCHDB-1644
> Project: CouchDB
>  Issue Type: Task
>  Components: Build System
>Reporter: Dave Cottlehuber
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COUCHDB-2950) Using CouchDB 1.6.1 on Windows. Trying to point...

[Joan Touzet (JIRA)]

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

Joan Touzet resolved COUCHDB-2950.
--
Resolution: Won't Fix
  Assignee: Joan Touzet

> Using CouchDB 1.6.1 on Windows.Trying to point...
> -
>
> Key: COUCHDB-2950
> URL: https://issues.apache.org/jira/browse/COUCHDB-2950
> Project: CouchDB
>  Issue Type: Bug
>Reporter: ASF subversion and git services
>    Assignee: Joan Touzet
>
> Using CouchDB 1.6.1 on Windows.
> Trying to point the database_dir to a UNC path doesn't seem to work.
> e.g. setting database_dir = //test/couchdb will create a new couchdb folder 
> under c:\test\couchdb instead of the intended UNC path.
> *Reporter*: Steve Dickson
> *E-mail*: [mailto:sdick...@fraedom.com]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2950) Using CouchDB 1.6.1 on Windows. Trying to point...

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15336950#comment-15336950
 ] 

Joan Touzet commented on COUCHDB-2950:
--

I'm afraid we don't support UNC paths on Windows, and there are going to be 
serious performance considerations serving a database from a network share, 
just so you know. I strongly advise against this for anything other than 
development work (and would be against putting UNC path support into the 
product for this very reason).

Can you map a drive to your UNC path and test things that way?

> Using CouchDB 1.6.1 on Windows.Trying to point...
> -
>
> Key: COUCHDB-2950
> URL: https://issues.apache.org/jira/browse/COUCHDB-2950
> Project: CouchDB
>  Issue Type: Bug
>Reporter: ASF subversion and git services
>
> Using CouchDB 1.6.1 on Windows.
> Trying to point the database_dir to a UNC path doesn't seem to work.
> e.g. setting database_dir = //test/couchdb will create a new couchdb folder 
> under c:\test\couchdb instead of the intended UNC path.
> *Reporter*: Steve Dickson
> *E-mail*: [mailto:sdick...@fraedom.com]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

2.0 & Windows: status update

[Joan Touzet]

Hello everyone,

I'd like to update the community on the status of the 2.0 port to Microsoft 
Windows. There are three parts to this email: the build tools/chain themselves, 
support in CouchDB for the Windows build process, and testing results. I'll 
cover them in that order.

-Joan

Build Tools/Chain
=
** TL;DR: New glazier repo to join couchdb, contains scripts and README to 
build CouchDB 2.0 on Windows.

Our work to date has been going on in Dave Cottlehuber's glazier repository at 

  https://github.com/dch/glazier/tree/release/couchdb_2.0

The reason for the extra repository is that the Windows build process is *very* 
ugly, involving 3 distinct build chains (Visual Studio, Cygwin and the Mozilla 
Build system) to build all of the necessary prerequisites. The repository 
includes a number of support scripts to set up that environment, a README with 
a detailed walkthrough, and some patches necessary to the prerequisites to get 
them to build under the modern Windows b uild system.

Parenthetically, it _is_ possible to use binary installs for the prerequisites 
(OpenSSL, libcurl, Erlang, SM 1.8.5), but Dave, Nick North and I have evolved 
the glazier system over a number of years and it's proven quite effective. 
Plus, we don't have to worry about the provenance of any of the binaries since 
we build everything from source directly, and that's important when we put up 
an unofficial Windows build for download at https://couchdb.apache.org/ .

Good news: as of today I've requested and Infra has created a new apache 
couchdb-glazier repo, and it's my intent to mirror dch/glazier over into the 
ASF's repo once things have stabilized a bit more (PR and merge of the 
release/couchdb_2.0 branch, and pending progress on steps 2 and 3 below). Dave 
and I did an audit of the repository as it stands, and since all checkins come 
from CouchDB contributors already, we are good to go from a licensing 
perspective.


Overall CouchDB Windows support
===
** TL;DR: Windows support in 2.0 a priority, conversion of top-level Makefile 
in progress.

There are two aspects to native CouchDB Windows support. The first is anything 
within the CouchDB code itself that assumes a Unix-like environment. 
Fortunately, most of these problems have been worked out in prior releases. I'm 
not aware of any outstanding issues here (except one point below under test 
results).

The other aspect is the build setup within the couchdb repo itself. I've 
already converted the bash configure script into a PowerShell configure script 
that works fine. However, the Makefile has bashisms in it and assumes GNU Make. 
I've started a conversion of this into Windows NMake format and will submit a 
PR for a Makefile.win in due course.

I want to answer two frequent questions we get here before they get re-asked:

  1) Why not use a cygwin environment to retain compatibility with the Unix 
build process? The answer is that performance suffers, the build chain is 
onerous, there are link-time problems when trying to link against things built 
using Visual Studio, and there are still assumptions on paths that don't work 
out. We can't get away from making Windows-specific customizations to the build 
process anyway, so we might as well take the extra step and support the build 
process properly. It's not THAT much work to convert the Makefile and configure 
script, and our top-level Makefile really isn't much more than a shell script 
anyway (every target is a .PHONY target!). In fact, a TODO for an enterprising 
developer might be to rewrite our top-level Makefile/Makefile.win as a Python 
script that "does the right thing" on both platforms, the same way our dev/run 
script works today.

  2) Why not use the new "Bash and Ubuntu on Windows" functionality Microsoft 
has announced for Windows 10? There are two distinct problems here. The first 
is that there is a very large install base still of Windows 7 and 8 (and 
Windows Server) machines that cannot run this subsystem. The second is that 
Microsoft themselves say this about the functionality:

 "Second, while you’ll be able to run native Bash and many Linux 
command-line tools on Windows, it’s important to note that this is a developer 
toolset to help you write and build all your code for all your scenarios and 
platforms. This is not a server platform upon which you will host websites, run 
server infrastructure, etc."

Given this strong warning from Microsoft themselves (which hints at performance 
consideratings), and the fact that download statistics show an equal number of 
downloads of the CouchDB .tar source and the Windows .zip installer from our 
couchdb.apache.org website, we need to consider that people are running CouchDB 
on Windows not just as a developer tool but as a fully-fledged server. As such 
it behooves us to build it "properly" as a normal Windows binary/service.


Test Results

** TL;DR: Lots of things are failing

Re: _replicate vs. _replicator

[Joan Touzet]

Hi Ben, did anyone ever get back to you on this? I know that the
core developers have a LOT of reservations about the _replicator database,
primarily the fact that the backing store for a _replicator endpoint
probably shouldn't be a database itself (though it could conceivably present
a similar API to one).

Personally I still use the _replicate endpoint most of the time.

-Joan

- Original Message -
From: "Ben Keen" 
To: dev@couchdb.apache.org
Sent: Friday, June 3, 2016 10:11:30 AM
Subject: _replicate vs. _replicator

Hey!

Wonder if I could get some advice here. I’ve been working on refactoring
the replication feature in Fauxton to POST to the /_replicator database
rather than using /_replicate.

Having all replications (continuous/one-offs) logged in one place (the
_replicator database) leaves a nice paper trail of replication history.
[N.B. I’ve been speaking to Markus Fischboeck, who’s doing work on adding
some advanced replication features - we’re working in parallel].

I’ve been able to get replications working, but it requires passing both
basic headers in the POSTed JSON content, and the creds in the actual
endpoint URL, like so:

http://bob:bobspassw...@mylocalsite.dev:8000/_replicator

It’s the latter that particularly worries me. I don’t believe this is
secure over http (correct?), and since Fauxton could be run anywhere, I
 wanted to know if I should stop heading down this road and stick with
_replicate.

Thanks!

Ben

Re: [ANNOUNCE] Nick Vatamaniuc elected as CouchDB committer

[Joan Touzet]

As I said on IRC...congratulations! Long overdue.

-Joan

- Original Message -
> From: "Benjamin Bastian" 
> To: dev@couchdb.apache.org
> Sent: Thursday, June 16, 2016 8:42:19 PM
> Subject: Re: [ANNOUNCE] Nick Vatamaniuc elected as CouchDB committer
> 
> Congratulations, Nick!
> 
> On Thu, Jun 16, 2016 at 5:11 PM, Kyle Snavely 
> wrote:
> 
> > Awesome! Congrats Nick!
> >
> > On Thu, Jun 16, 2016 at 7:41 PM, Michelle Phung
> > 
> > wrote:
> >
> > > Congrats Nick!
> > >
> > >
> > > > On Jun 16, 2016, at 7:24 PM, Robert Samuel Newson
> > > > 
> > > wrote:
> > > >
> > > > Dear community,
> > > >
> > > > I am pleased to announce that the CouchDB Project Management
> > > > Committee
> > > has elected Nick Vatamaniuc as a CouchDB committer.
> > > >
> > > >Apache ID: vatamane
> > > >
> > > >IRC nick: vatamane
> > > >
> > > > 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 Nick'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 Nick!
> > > >
> > > > On behalf of the CouchDB PMC,
> > > >
> > > > Robert Samuel Newson
> > > >
> > >
> > >
> >
> 

Re: 2.0 Code Freeze or branching 2.1?

[Joan Touzet]

Also +1, except for the work to get the Windows port running correctly.

-Joan

- Original Message -
> From: "Michelle Phung" 
> To: dev@couchdb.apache.org
> Sent: Thursday, May 26, 2016 7:23:46 AM
> Subject: Re: 2.0 Code Freeze or branching 2.1?
> 
> +1
> 
> - Michelle
> 
> > On May 26, 2016, at 6:34 AM, Alexander Shorin 
> > wrote:
> > 
> > I think that's better call feature/improvements freeze, since we
> > still
> > have to commit the code that includes bugfixes.
> > 
> > +1
> > --
> > ,,,^..^,,,
> > 
> > 
> >> On Thu, May 26, 2016 at 12:56 PM, Robert Newson
> >>  wrote:
> >> +1 for code freeze.
> >> 
> >> The only changes we will merge to master branches must contribute
> >> toward 2.0 actually shipping.
> >> 
> >> I would also not make 2.x.x branches until 2.0 is GA. the first
> >> commit on all those branches should be the release itself.
> >> Subsequent commits are backported fixes from master only.
> >> 
> >> Lets explicitly say that we'll take no work for future
> >> enhancements or fixes until 2.0 ships. We must get this out.
> >> 
> >> Sent from my iPhone
> >> 
> >>> On 26 May 2016, at 09:10, Andy Wenk  wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> in my opinion, everybody is interested to add new features on a
> >>> stable version of CouchDB. So with a code freeze, everybody is
> >>> asked to help get 2.0 shipped because then, new features can be
> >>> added with more focus and on a stable release.
> >>> 
> >>> For me, this sounds better than branching even though, that some
> >>> people will work on their own repos.
> >>> 
> >>> +1 for code freeze
> >>> 
> >>> Side note: as I am not actively developing, my opinion should be
> >>> taken with low prio because there might be reasons from others
> >>> to prefer branching.
> >>> 
> >>> Thanks to everyone making CouchDB 2.0 great!
> >>> 
> >>> Andy
> >>> 
> >>> --
> >>> Andy Wenk
> >>> RockIt!
> >>> 
> >>> Hamburg / Germany
> >>> 
> >>> GPG public key:
> >>> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
> >>> 
>  On 26 May 2016, at 09:42, Jan Lehnardt  wrote:
>  
>  Hey all,
>  
>  last night on IRC Bob brought up a good point: we have ongoing
>  development going into our repos while we are trying to get 2.0
>  out the
>  door. It might be time to split these two.
>  
>  Bob suggested a code freeze until we ship a first 2.0 beta. An
>  alternative would be to branch out 2.x.x and stabilise that,
>  port any
>  fixes to master, where regular development can occur there.
>  
>  Both alternatives have their pros and cons, but I like the
>  aspect of a
>  code freeze that forces everyone to help get the release build
>  stable.
>  
>  That said, I fear that most folks would then just commit to
>  their
>  personal or other corporate repos (hello Cloudant) and only sync
>  to ASF
>  repos when the freeze is over, and not help out with the build.
>  
>  E.g. I don’t want to force anyone into anything they don’t want
>  to do
>  with an arbitrary policy, but I’d be in support of a code freeze
>  if
>  people here would signal that it’d help them focus on a stable
>  build
>  as opposed to new feature development.
>  
>  What do you think?
>  
>  Best
>  Jan
>  --
> >> 
> 

Item for the CouchDB Newsletter

[Joan Touzet]

http://www.stilldrinking.org/proposal-for-new-rest-methods

A bit of humour for the newsletter, maybe? :)

-Joan

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Joan Touzet]

Congrats, Nolan!

- Original Message -
> From: "Robert Kowalski" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, April 19, 2016 12:04:22 PM
> Subject: Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer
> 
> Whohoo, congrats Nolan! :)
> 
> On Tue, Apr 19, 2016 at 5:21 PM, Darío Cravero 
> wrote:
> > Congrats Nolan!! :)
> >
> > On Tue, Apr 19, 2016 at 3:49 PM Nolan Lawson
> >  wrote:
> >
> >> Thanks, Jan and Garren!! I'm happy to join up with such a fine and
> >> welcoming community. :) Here's to a great 2016 for CouchDB!
> >>
> >> Cheers,
> >> Nolan
> >>
> >> On Tue, Apr 19, 2016 at 10:46 AM, Jan Lehnardt 
> >> wrote:
> >>
> >> > Woohoo contrats and welcome Nolan :)
> >> >
> >> > Best
> >> > Jan
> >> > --
> >> > > On 19 Apr 2016, at 16:43, Garren Smith 
> >> > > wrote:
> >> > >
> >> > > Dear community,
> >> > >
> >> > > I am pleased to announce that the CouchDB Project Management
> >> > > Committee
> >> > > has elected Nolan Lawson as a CouchDB committer.
> >> > >
> >> > >Apache ID: nolan
> >> > >
> >> > >IRC nick: nolanlawson
> >> > >
> >> > >Twitter: @nolanlawson
> >> > >
> >> > > 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 Nolan'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 Nolan!
> >> > >
> >> > > On behalf of the CouchDB PMC,
> >> > >
> >> > > Cheers
> >> > >
> >> > > Garren
> >> >
> >> > --
> >> > Professional Support for Apache CouchDB:
> >> > https://neighbourhood.ie/couchdb-support/
> >> >
> >> >
> >>
> >>
> >> --
> >> Nolan Lawson
> >> nolanlawson.com
> >> github.com/nolanlawson
> >>
> 

Re: make

[Joan Touzet]

Windows port. If the test suite is finally stable we'll do another
pass of getting this to work - sans the Win 10 bash stuff since a)
that's still in private release and b) Win 10 stinks.

-Joan

- Original Message -
> From: "Jan Lehnardt" 
> To: dev@couchdb.apache.org
> Sent: Friday, April 15, 2016 4:48:29 PM
> Subject: Re: make
> 
> What else is missing for 2.0? If nothing/not much, I'd like to get
> first 2.0.0 release candidates out next week.
> 
> It's time to bring out your pet features/bug fixes ;)
> 
> Jan
> --
> 
> > On 15 Apr 2016, at 18:31, Jan Lehnardt  wrote:
> > 
> > As promised: https://github.com/apache/couchdb/pull/402
> > 
> > Little issue with Fauxton, would love help from the team <3
> > 
> > Best
> > Jan
> > --
> > 
> >> On 30 Mar 2016, at 21:57, Jan Lehnardt  wrote:
> >> 
> >> Hey all,
> >> 
> >> last year I endeavoured to make the 2.0 build system to behave as
> >> close to 1.x as possible.
> >> 
> >> We’re 80% there, but the remaining 80% prove hard, of course.
> >> Without going too much into the details, the missing parts are
> >> the integration with all the different operating systems. Stuff
> >> that takes years to get right (even with autotools in 1.x it took
> >> us quite some time).
> >> 
> >> To keep it short: I don’t want to hold up 2.0 for this work. It
> >> can be easily (re-)added later, and the intermediate solution
> >> allows us to ship 2.0 sooner (yay).
> >> 
> >> My current plan is to have `./configure && make` produce a
> >> directory `./apache-couchdb-` that includes a full
> >> CouchDB build, Fauxton, Docs, etc. that can be moved into the OS
> >> anywhere (say `/usr/local`) and run from there, and everything:
> >> logs, data files, sources, ini files, are in that directory, and
> >> there is no way to move them out (maybe via symlinks, but I don’t
> >> care ;) into a standard file system layout (config files under
> >> [/usr/local]/etc, data files into [/usr/local]/var/lib etc. There
> >> won’t be a `make install` (maybe a dummy that prints an
> >> explanation of how to do the install, and why the target isn’t
> >> there).
> >> 
> >> This shouldn’t be a lot of work and I’ll try to work on this asap.
> >> 
> >> Let me know what you think!
> >> 
> >> Best
> >> Jan
> >> --
> >> Professional Support for Apache CouchDB:
> >> https://neighbourhood.ie/couchdb-support/
> > 
> > --
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
> > 
> 
> 

Re: Adam Kocoloski is now an IBM Fellow

[Joan Touzet]

Congrats!

- Original Message -
> From: "Jan Lehnardt" 
> To: "dev@couchdb.apache.org Developers" 
> Sent: Friday, April 15, 2016 4:50:10 AM
> Subject: Adam Kocoloski is now an IBM Fellow
> 
> Hey all,
> 
> our own Adam made IBM Fellow! He’s now one of only 267* individuals
> who’ve been awarded this honour for their contributions to IBM and
> computing in general:
> 
>   http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/
> 
> Congratulations Adam, very proud to have you on the team :)
> 
> Best
> Jan
> --
> * this is only slightly less than the number of git repos
>   we now manage.

Re: On dependency management and CI issues associated with it

[Joan Touzet]

Based on this information, are we in violation of ASF requirements? Can
anyone clarify for me what we actually need to be doing here?

-Joan

- Original Message -
> From: "Garren Smith" 
> To: dev@couchdb.apache.org, "Joan Touzet" 
> Sent: Thursday, April 14, 2016 2:43:10 AM
> Subject: Re: On dependency management and CI issues associated with it
> 
> Hi Joan,
> 
> Good point. Until about a week ago we use to keep all our
> dependencies in
> our repo. But we have just switched to webpack which allows us to
> manage
> our dependencies via npm (in case you are wondering, we don't depend
> on
> leftpad directly). So some of them are in our repo but the majority
> are
> downloaded and then bundled.
> 
> 
> Cheers
> Garren
> 
> On Wed, Apr 13, 2016 at 11:29 PM, Joan Touzet 
> wrote:
> 
> > Garren, correct me if I'm wrong but Fauxton depends on a large
> > number
> > of JS dependencies that we don't keep copies of, correct? Or is it
> > just
> > for the build process?
> >
> > -Joan
> >
> > - Original Message -
> > > From: "Alexander Shorin" 
> > > To: dev@couchdb.apache.org
> > > Sent: Wednesday, April 13, 2016 2:08:20 PM
> > > Subject: Re: On dependency management and CI issues associated
> > > with it
> > >
> > > On Wed, Apr 13, 2016 at 8:39 PM, Robert Newson
> > > 
> > > wrote:
> > > > It's a thread derail but this notion that we're being "fairly
> > > > rude"
> > > > needs resolving. It might be lost to history now but we got
> > > > here,
> > > > I think, with the best intentions of ensuring all the code that
> > > > appears in couchdb can be traced back to code hosted at asf. Is
> > > > it
> > > > a concrete requirement? I honestly forget but I thought so.
> > >
> > > Yes, that's the answer why. If one day mochiweb owner will decide
> > > to
> > > drop his github repo, we shouldn't be leave with broken builds.
> > > See
> > > leftpad story as well. Initially, that requirement seems
> > > redundant,
> > > but recent npm drama showed that it has a huge point. Also there
> > > are
> > > some legal bits about.
> > >
> > > --
> > > ,,,^..^,,,
> > >
> >
> 

Re: On dependency management and CI issues associated with it

[Joan Touzet]

Garren, correct me if I'm wrong but Fauxton depends on a large number
of JS dependencies that we don't keep copies of, correct? Or is it just
for the build process?

-Joan

- Original Message -
> From: "Alexander Shorin" 
> To: dev@couchdb.apache.org
> Sent: Wednesday, April 13, 2016 2:08:20 PM
> Subject: Re: On dependency management and CI issues associated with it
> 
> On Wed, Apr 13, 2016 at 8:39 PM, Robert Newson 
> wrote:
> > It's a thread derail but this notion that we're being "fairly rude"
> > needs resolving. It might be lost to history now but we got here,
> > I think, with the best intentions of ensuring all the code that
> > appears in couchdb can be traced back to code hosted at asf. Is it
> > a concrete requirement? I honestly forget but I thought so.
> 
> Yes, that's the answer why. If one day mochiweb owner will decide to
> drop his github repo, we shouldn't be leave with broken builds. See
> leftpad story as well. Initially, that requirement seems redundant,
> but recent npm drama showed that it has a huge point. Also there are
> some legal bits about.
> 
> --
> ,,,^..^,,,
> 

Re: make

[Joan Touzet]

Agreed, good enough for now. 

- Original Message -
> From: "Jan Lehnardt" 
> To: "dev@couchdb.apache.org Developers" 
> Sent: Wednesday, March 30, 2016 3:57:01 PM
> Subject: make
> 
> Hey all,
> 
> last year I endeavoured to make the 2.0 build system to behave as
> close to 1.x as possible.
> 
> We’re 80% there, but the remaining 80% prove hard, of course. Without
> going too much into the details, the missing parts are the
> integration with all the different operating systems. Stuff that
> takes years to get right (even with autotools in 1.x it took us
> quite some time).
> 
> To keep it short: I don’t want to hold up 2.0 for this work. It can
> be easily (re-)added later, and the intermediate solution allows us
> to ship 2.0 sooner (yay).
> 
> My current plan is to have `./configure && make` produce a directory
> `./apache-couchdb-` that includes a full CouchDB build,
> Fauxton, Docs, etc. that can be moved into the OS anywhere (say
> `/usr/local`) and run from there, and everything: logs, data files,
> sources, ini files, are in that directory, and there is no way to
> move them out (maybe via symlinks, but I don’t care ;) into a
> standard file system layout (config files under [/usr/local]/etc,
> data files into [/usr/local]/var/lib etc. There won’t be a `make
> install` (maybe a dummy that prints an explanation of how to do the
> install, and why the target isn’t there).
> 
> This shouldn’t be a lot of work and I’ll try to work on this asap.
> 
> Let me know what you think!
> 
> Best
> Jan
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
> 
> 

Re: Calculating Revision IDs outside erlang (proposal to add {minor_version, 1} to the calc)

[Joan Touzet]

Hey Mike,

As mentioned on IRC I'd like to see some test cases in our suite
to help ensure we don't regress on this in the future. Specifically,
I think it'd be good to ensure consistent revs on a handful of 
indicative docs.

There's nothing saying we can't change how we do this in the future,
but we need to be mindful of the fact now that:

1) We are a reference implementation for rev calculation for other DBs,
and
2) We should be alerted to the fact that how we calculate revs for docs
   has changed due to some checkin or another

You mentioned on IRC you had a few documents that could help with this.
Even if you don't commit the test cases yourself, could you share your
current test suite with us somehow?

Thanks,
Joan


- Original Message -
> From: "Michael Fair" 
> To: dev@couchdb.apache.org
> Sent: Saturday, March 26, 2016 7:49:21 PM
> Subject: Re: Calculating Revision IDs outside erlang (proposal to add 
> {minor_version, 1} to the calc)
> 
> Alright, merge is in!
> 
> Step 1) for 2.0+ revisions!
> 
> Thanks all!
> Mike
> On Mar 24, 2016 12:16 AM, "Michael Fair" 
> wrote:
> 
> > Ok pull request is away, I used the GitHub repository,
> > apache/master as a
> > base, and revId-minor_version_1-md5Calc as the branch in my fork.
> >  It
> > wasn't obvious to me how to get a Jira ticket and branch created
> > and my git
> > skills are minimal on a good day.
> >
> > There was a build error on R16B03-1; I tried to look at the logs
> > but
> > wasn't sure what I was looking at/for.
> >
> > The actual change is extremely minimal as it's just changing like
> > 876 in
> > src/couch_db.erl from this:
> > couch_crypto:hash(md5, term_to_binary([Deleted,
> > OldStart,
> > OldRev, Body, Atts2]))
> >
> > to this:
> > couch_crypto:hash(md5, term_to_binary([Deleted,
> > OldStart,
> > OldRev, Body, Atts2], [{minor_version, 1}]))
> >
> >  Any advice/help/guidance appreciated.
> >
> > Thanks,
> > Mike
> >
> 

[jira] [Commented] (STEVE-40) Show prior vote when re-casting a vote

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/STEVE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210172#comment-15210172
 ] 

Joan Touzet commented on STEVE-40:
--

I'd like to voice my support for this issue. Neither the confirmation email nor 
re-visiting the URL shows the prior vote. This is especially confusing as the 
re-visited URL shows no evidence that any vote has taken place at all!

Is there a reason why the receipt email (Vote registered) either instead of or 
in addition to the re-visited URL cannot at a baseline include the prior vote?

> Show prior vote when re-casting a vote
> --
>
> Key: STEVE-40
> URL: https://issues.apache.org/jira/browse/STEVE-40
> Project: Steve
>  Issue Type: Improvement
>Reporter: John D. Ament
>
> When re-casting a vote on a ballot, I should have access to my old vote when 
> deciding what to recast to.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Public endpoint when couch_httpd_auth.require_valid_user=true

[Joan Touzet]

In CouchDB 2.0 there should be /_up . I'd consider it a bug if that
endpoint required a valid user.

/_up returns {"status":"ok"} if everything is copacetic.

-Joan

- Original Message -
> From: "Alexander Shorin" 
> To: user@couchdb.apache.org
> Sent: Thursday, March 10, 2016 1:26:40 PM
> Subject: Re: Public endpoint when couch_httpd_auth.require_valid_user=true
> 
> IIRC, no, that's the point of this option. If it responding with 401
> then it's actually available and responding (:
> --
> ,,,^..^,,,
> 
> 
> On Thu, Mar 10, 2016 at 2:58 PM, Matthew Buckett
>  wrote:
> > Are there any URLs that requested when
> > couch_httpd_auth.require_valid_user=true that don't generate an
> > HTTP
> > 401 error?
> >
> > I'm looking to just check that CouchDB is available and responding.
> >
> > --
> >   Matthew Buckett, VLE Developer, IT Services, University of Oxford
> 

Re: Happy Birthday Garren!!

[Joan Touzet]

Jumping on the bandwagon a bit late butHappy Happy!

-Joan

- Original Message -
> From: "Garren Smith" 
> To: dev@couchdb.apache.org
> Cc: andyw...@apache.org, "Garren Smith" 
> Sent: Friday, February 12, 2016 12:27:05 PM
> Subject: Re: Happy Birthday Garren!!
> 
> Thanks everyone for the well wishes, that's really awesome. I had a
> great day
> and stayed hippo attack free.
> 
> On Friday, 12 February 2016, Ben Keen  wrote:
> 
> > Hey happy birthday, Garren! Avoided a hippo attack for one more
> > year, nice
> > job! Not to bum you out or anything, but statistically the next
> > year's
> > going to be a tough one.
> >
> > Ben
> >
> >
> >
> > On Fri, Feb 12, 2016 at 6:49 AM, Andy Wenk  > > wrote:
> >
> > > oh no - again one year older :D
> > >
> > > Happy Birthday and all the best ;-)
> > >
> > > Cheers
> > >
> > > Andy
> > >
> > > On 12 February 2016 at 15:29, Jan Lehnardt  > > wrote:
> > >
> > > > Oh oh oh!
> > > >
> > > > Happy Birthday Garren ;) 🎉
> > > >
> > > > Best
> > > > Jan
> > > > --
> > > >
> > > > > On 12 Feb 2016, at 15:21, Michelle Phung
> > > > >  > > wrote:
> > > > >
> > > > > Happy Birthday Garren!!
> > > >
> > > >
> > >
> > >
> > > --
> > > Andy Wenk
> > > Hamburg - Germany
> > > RockIt!
> > >
> > > GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3
> > > 9588
> > >
> > > https://people.apache.org/keys/committer/andywenk.asc
> > >
> >
> 

Re: Applied for official Docker image

[Joan Touzet]

I've not been following this message trail carefully, but I have a question.

Does the docker image run 3 instances within the same image, or is it a
single node version? The reason I ask is that, in deployment, which is
where I would expect docker to shine, you'd **NEVER** want to run 3
nodes on the same machine. It basically removes the entire clustering
feature from CouchDB.

I'm happy to explain more if it's not clear why having the default docker
image as a single node is strongly preferable.

-Joan

- Original Message -
> From: "Jan Lehnardt" 
> To: dev@couchdb.apache.org
> Sent: Monday, February 1, 2016 10:22:42 AM
> Subject: Re: Applied for official Docker image
> 
> 
> > On 01 Feb 2016, at 08:18, Dave Cottlehuber 
> > wrote:
> > 
> > On Tue, 26 Jan 2016, at 02:19 AM, Eli Stevens (Gmail) wrote:
> >> On Mon, Jan 25, 2016 at 11:10 AM, Alexander Shorin
> >> 
> >> wrote:
> >>> On Mon, Jan 25, 2016 at 9:59 PM, Eli Stevens (Gmail)
> >>>  wrote:
>  The intent was to hopefully have the build scripts, etc. folded
>  back
>  into the main repo to make it easier for future releases to have
>  official packages, but I think that everyone was too focused on
>  core
>  2.0 issues to get too involved in packaging (and also enough
>  changed
>  that it was probably too early to get it right).
> >>> 
> >>> Hm...nice! Do you have these build scripts? We can put them into
> >>> our
> >>> repo now even for 1.6 state. That would be still better than
> >>> start
> >>> whole work from scratch and I think we can make these builds
> >>> official
> >>> via CI services that will run Ubuntu anyway.
> >> 
> >> I don't have the scripts, as the only formal deliverable from
> >> earlier
> >> was a working Ubuntu 12.04 package of 1.6.1 (and we wouldn't have
> >> had
> >> a use for the scripts in any case, as we're not interested in
> >> building
> >> CouchDB ourselves, hence contracting that out to someone who knows
> >> what they're doing).
> >> 
> >> I'll let Dave comment about the new work, once we've got a
> >> contract
> >> hammered out, and he's been able to devote some time to the
> >> project.
> >> Again, it might be a bit before that happens.
> >> 
> >> Cheers,
> >> Eli
> > 
> > The scripts are public[1] and we could merge them happily if it
> > makes
> > sense where they go to. I should explain briefly how these are
> > built, as
> > this
> > is relevant.
> > 
> > The repo master branch includes the unpacked couchdb release
> > tarball in
> > the root, and a /debian/ folder with all the magic pixie dust. On
> > each
> > new
> > release (whether of couchdb, updating packaging, or re-packaging
> > for
> > a new ubuntu release), do the following:
> > 
> > - spin up a compatible Ubuntu box
> > - provision with ansible [2]
> > - bare clone the repo
> > - check out only the /debian/ packaging directory (patches,
> > dependency
> > info)
> > - unpack the new couchdb release
> > - commit the "changes" to git
> > - futz around with init scripts, systemd and whatever until couchdb
> > works
> > 
> > There's no particular reason why this shouldn't work for 2.0, more
> > detail in
> > the associated wiki[3].
> > 
> > I updated the repo for 1.6.1 and supporting wily + xenial [4], the
> > main
> > change
> > is integrating systemd changes and complying with the latest debian
> > packaging tools, so this is a good base to continue from.
> > 
> > I'm not sure where these scripts would go in our ASF world, but
> > they
> > should
> > be kept in step with any releases.
> 
> I’d put them in couchdb.git/build-aux for now, that’s where I keep
> scripts
> that are run during configure/make. If this should be its own repo,
> we can
> apply for couchdb-package.git or something.
> 
> Would the ./build-aux directory work for now?
> 
> Best
> Jan
> --
> 
> 
> 
> > 
> > Finally, anybody wishing to contribute to the ppa or the build repo
> > is
> > welcome
> > just email me (PPA) or send a PR (build repo).
> > A+
> > Dave
> > 
> > [1]: https://github.com/dch/couchdb-launchpad
> > [2]: https://gist.github.com/dch/86982e187e97a9b23bf5
> > [3]:
> > https://github.com/dch/couchdb-launchpad/wiki/creating-the-package
> > [4]: https://launchpad.net/~couchdb/+archive/ubuntu/dev/
> > [5]: https://launchpad.net/~couchdb/
> 
> 

Re: Signal Handing

[Joan Touzet]

Feel free to kill -9 couchdb if you want. There is no special "graceful"
shutdown for couchdb and it doesn't matter given our crash-only architecture.

If SIGSTOP makes you feel better, feel free to cargo cult that as a
solution. Makes no difference ;)

-Joan

- Original Message -
> From: "Matthew Buckett" 
> To: user@couchdb.apache.org
> Sent: Tuesday, January 26, 2016 8:11:56 AM
> Subject: Signal Handing
> 
> I was looking to see if it's possible to have CouchDB shutdown
> gracefully in response to UNIX signals but it looks like this isn't
> something that erlang natively supports:
> 
> http://erlang.2086793.n4.nabble.com/Signal-handling-TERM-INT-etc-td2107363.html
> 
> From looking in the documentation I can see the standard way to
> shutdown couchdb when it's running in the background is to use:
> 
> couchdb -d
> 
> I'm running couchdb inside docker so was running couchdb in the
> foreground (-i as well as ENV ERL_FLAGS=-noinput), this means that
> `couchdb -d` doesn't work (it says it isn't running). However because
> of running in interactive mode I can send the process a SIGSTOP and
> it
> appears to exit gracefully (exit code 0).
> 
> Is this a sensible or acceptable thing todo and am I likely to hit
> problems with it?
> 
> Thanks.
> 
> --
>   Matthew Buckett, VLE Developer, IT Services, University of Oxford
> 

Re: Compiling snappy under Windows

[Joan Touzet]

I agree we should avoid re-introducing autoconf to the build process.

Hopefully we can fix this with a simple set of #ifdefs in a header file
somewhere that defines ssize_t (or anything else we need) appropriately,
or dig into the MS SDK for any references available and include compat
header files.

-Joan

- Original Message -
> From: "Alexander Shorin" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, January 19, 2016 12:15:25 PM
> Subject: Re: Compiling snappy under Windows
> 
> On Tue, Jan 19, 2016 at 8:05 PM, Nick North 
> wrote:
> > I'm not exactly sure what you are proposing here. Are you saying we
> > should
> > run autoconf for the snappy code? There is an earlier commit in
> > couchdb-snappy repository that removed autotools, saying they did
> > not work
> > well with snappy, which makes me a bit cautious about that.
> > Apologies if
> > I've misunderstood your suggestion,
> 
> That's the one of the solutions, but will require to:
> 1) integrate autoconf run from rebar
> 2) make autoconf as build dependency
> 3) ...
> and all these just for a few C++ types?
> 
> I proposed to add preprocessor conditional to catch Windows case and
> inject the right code to make snappy works. Basically, unfold
> autoconf
> conditions manually. That's the idea. I'm not sure if this will help,
> but worth to start from there.
> 
> --
> ,,,^..^,,,
> 

Re: how to force flush a db?

[Joan Touzet]

One thing to note is that your views and your DB may be in different
states when you pull files off the HDD sequentially, if they're large.
If your views are "newer" than the DB file you have, it could cause
issue. I recommend copying the .views subdirectory FIRST, then copying
the database file. This will ensure the views are always the same
age as the DB or older, meaning only a minor amount of catch-up is 
required to update the view to current if at all.

-Joan

- Original Message -
> From: "Clemens Stolle" 
> To: user@couchdb.apache.org
> Sent: Friday, January 15, 2016 3:52:49 AM
> Subject: Re: how to force flush a db?
> 
> Hey Dan,
> I have an app in production and we handle backups the way you're
> describing. Every night we push a zip archive to s3. Works great.
> 
> ---
> Clemens
> 
> > Am 14.01.2016 um 21:44 schrieb Dan Santner :
> > 
> > Thanks for the response.
> > 
> > I should probably ask a different question.
> > 
> > I’ve been using git to take snapshots of my databases in certain
> > states.  Basically i put all the data files under git and then
> > when I have my data the way I want I can freeze it for later
> > replay by committing it to a branch in a repo.
> > 
> > It works really well for me.  I’m thinking of the similar mechanism
> > for backup.  Basically I’ll zip the data directory and store it in
> > S3 periodically as a backup.  I was concerned though that the
> > state of the files might not be restartable if I don’t shut down
> > the couchdb process before snapshotting.
> > 
> > Anyone else doing something like this?
> > 
> >> On Jan 14, 2016, at 1:00 PM, Robert Samuel Newson
> >>  wrote:
> >> 
> >> [couchdb]
> >> delayed_commits=false
> >> 
> >> It’s false by default from 2.0 onward too.
> >> 
> >> When set to true, a timer calls fsync once per second. I’d argue
> >> your forcing isn’t necessary in either case.
> >> 
> >> B.
> >> 
> >>> On 14 Jan 2016, at 17:46, Dan Santner  wrote:
> >>> 
> >>> Is there a way to force couch to flush everything to disk?  right
> >>> now I’m stopping the database to make that happen but would be
> >>> really nice to be able to do that while keeping it running.
> >>> 
> >>> 
> >>> Maybe this isn’t even necessary?
> > 
> 

Re: [POC] Mango Catch All Selector

[Joan Touzet]

Warning: If we start using English text in a response such as this, we'll
need to start externalising strings and internationalising them. We've never
had to do this before because our API is, in general, terse and relies on
HTTP status codes to indicate when something has gone wrong.

I think the current design constraint around text is a good one, and I'm
unconvinced including English text is a good direction.

If you want to take this direction, including a URL to our documentation
instead (which *is* internationalized) is probably a better way to go,
something like:

 {"_warning": "http://docs.couchdb.org/en/2.0.0/."}]



- Original Message -
From: "Robert Kowalski" 
To: dev@couchdb.apache.org
Sent: Wednesday, January 13, 2016 2:47:27 PM
Subject: Re: [POC] Mango Catch All Selector

Hi Garren,

what would selector: null do? Return all docs?

Where in the answer from CouchDB would be the warning? Next to the
resultset, like

[{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
better performance"}] ?

Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :

> Hi Robert,
>
> I think you miss understood me, I don’t want it to be a different endpoint.
> I just don’t want a user to have to do queries like this find({slow:
> true}). I want them to be able to do a query e.g. find({}) or
> find({selector: null}) and then get back the results along with a warning
> message telling them that this query would be slow in production.
> The lower the barrier for entry here the better. I know we want to protect
> our users for when they go to production, but forcing them to add a slow:
> true flag won’t help. It will still require them to read the docs a lot
> more than most people are willing to on a first attempt of something new.
>
> Cheers
> Garren
> > On 12 Jan 2016, at 9:16 PM, Robert Kowalski  > wrote:
> >
> > thank you all for your feedback!
> >
> > i like the idea of the error message with a new url.
> >
> > i agree with garren that it should be a separate endpoint. it takes
> > some complexity off when explaining each endpoint.
> >
> > maybe: `/_find_slow`?
> >
> > On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt  > wrote:
> >>
> >>> On 11 Jan 2016, at 19:55, Tony Sun  > wrote:
> >>>
> >>> Hi Robert,
> >>>
> >>> Building upon what others have stated above, what do you think about
> >>> the following:
> >>>
> >>> 1) Let the user query without creating an index
> >>> 2) Return an error message with a new url that has
> >>> "slow/no_index/developer":true appended at the end. The message clearly
> >>> explains that this query will be slow, and that creating an index will
> be
> >>> more efficient. However, he or she can continue. The error message will
> >>> then have a link to point to our documentation.
> >>> 3) In Fauxton, there is a checkbox or button that also appends the
> >>> "slow/no_index/developer":true to the _find url. If the user clicks it,
> >>> then the same message pops up to notify the user.
> >>
> >>
> >> I like this!
> >>
> >>
> >> Jan
> >> --
> >>
> >>>
> >>>
> >>>
> >>> Tony
> >>>
> >>>
> >>>
> >>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
> wickedg...@gmail.com >
> >>> wrote:
> >>>
> >>>> Just wanted to chime in here as a user - I've run into similar
> >>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
> >>>> where stuff I was working on went smoothly in dev, but stopped once
> >>>> real load was pushed through it (thankfully for me, that was in
> >>>> testing, rather than released to customers).
> >>>>
> >>>> It's a frustrating experience, and I don't think that a reputation for
> >>>> "works until you cross a threshold, and then it doesn't, but only in
> >>>> production" is a good thing to move towards.
> >>>>
> >>>> Perhaps something like adding a key to the returned data along the
> >>>> lines of "_slow_warning": "This query is going to be slow on large
> >>>> data sets. See http://..."; in addition to the ?slow_warning=true
> query
> >>>> param (note that I'm calling it "slow_warning" in both place

Re: [POC] Mango Catch All Selector

[Joan Touzet]

Hi Robert,

I've been thinking about this one for the week or so, and I have a 
simple suggestion:

  Add the query parameter slow=true to enable this behaviour.

This meets all the original requirements:

1. It is not default behaviour
2. You can grep the log files for the word 'slow' and find evidence
3. There is a shorthand, simple way to enable the behaviour
4. Any self-respecting developer will try to remove slow=true, find
   a break, and be forced to learn about indexes
5. It's a bit cheeky, which I think is kind of fun :D

All the best,
Joan

- Original Message -
> From: "William Edney" 
> To: dev@couchdb.apache.org
> Sent: Friday, January 8, 2016 10:27:29 AM
> Subject: Re: [POC] Mango Catch All Selector
> 
> Hi Robert -
> 
> As a builder of UI, API and library code who has also done developer
> training on a variety of technologies, one simple fix might be go
> ahead and
> not require indexes to be built, but then to put a big NOTE at the
> beginning of the "Mango Getting Started" guide (I would assume there
> is
> such a piece of documentation) that states: "Note that the examples
> in this
> document do not require you to build an index, but for performance
> reasons
> we HIGHLY RECOMMEND that you do so. *Click here* for more information
> about
> how to do that" (or some such verbiage).
> 
> My 2 cents.
> 
> Cheers,
> 
> - Bill
> 
> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski 
> wrote:
> 
> > Hi list,
> >
> > At the end of the mail I would like to invite the other folks from
> > the
> > mailing list that build interfaces for humans (APIs, CLIs or even
> > UIs)
> > to chime in again with their opinions. So all people one the ML,
> > the
> > mail is not just a response to Paul, feedback is welcome :)
> >
> > Hi Paul, I agree with the timeout. It could lead to very unpleasant
> > errors which are hard to debug and support.
> >
> > I added some thoughts to the other points you made:
> >
> > > a) know that the slow queries logs exist,
> >
> > Hmm... If I take a look at the 1.x logging it was very
> > straightforward. As a developer you would spin up a CouchDB and you
> > get all the log messages into your terminal. It was quite handy in
> > general for all kind of debugging. That the logs are not displayed
> > directly on stdout/stderr is in my opinion a general 2.x problem.
> > The
> > problem does occur with all kinds of log message we produce in
> > CouchDB
> > for 2.x and is not specific to the slow-query-logging.
> >
> >
> > > Ie, "You can try queries with testing:true, when you're ready to
> > > move to
> > production you can
> > > POST your selector to _index to create the index which allows you
> > > to
> > > remove testing:true".
> >
> > I really like the migration path you mentioned here with the API to
> > create indexes. I am worried to have a too high entry barrier for
> > absolute newcomers, people that you want to play around before they
> > are ready to think about indexes, e.g. by putting coupling the
> > index
> > topic from the beginning to the querying.
> >
> > When I throw too much things to learn on people (which  may not
> > have
> > used a database before), most people get discouraged and does not
> > take
> > a look. The usual things they feel or say are : "too complicated",
> > "I
> > have not enough time", "product XY is easier to use".
> >
> > I would argue that newcomers to a database will launch a high
> > traffic,
> > multi-gigabyte product with the database from day one. Day one is
> > the
> > day where they learn how to query the data and put data into the
> > database. Even for scenarios where people have a running high
> > traffic
> > system, and have used other databases at a medium to large scale I
> > would expect given they migrate to Couch, that they run both
> > systems
> > in parallel for the first time in order to fix the issues that
> > occur
> > during a migration.
> >
> > I think we we share the same goal (getting beginners started
> > quickly)
> > and the cool thing about your suggestion is that everyone gets the
> > required knowledge to run a production system right from the very
> > start. My suggestion leaves some parts out, but reduces the
> > cognitive
> > load required to get the very first basic results, e.g. in a
> > university class setting - or junior developers on their "casual
> > friday 20% time". My big hope is, once those folks build high
> > traffic
> > systems, they remember how easy the usage of CouchDB was and that
> > they
> > start to learn more about CouchDB in order to run it in a system
> > with
> > more than a few thousand documents.
> >
> >
> > For us both I think the "what" is clear, but the "how" is a bit
> > different. I also think this discussion still makes progress, but I
> > am
> > afraid it could stall. I see that we both have very good rudiments
> > and
> > I would like to invite the other folks from the mailing list that
> > build interfaces for humans (APIs, CLIs or even UIs) to chime in
> > again
> > wi

Re: couchdb and static site generation?

[Joan Touzet]

You might want to check out Diana Thayer's Quilter:

https://github.com/garbados/quilter

Written in node.js as requested.

-Joan

- Original Message -
> From: "bryan rasmussen" 
> To: user@couchdb.apache.org
> Sent: Friday, January 1, 2016 2:23:52 PM
> Subject: couchdb and static site generation?
> 
> Hey,
> 
> I haven't been using couchdb for a number of years (due to work
> requirements always suggesting something else but I did make a couple
> medium size sites at one time)
> Now I am starting a personal site and I am thinking I would like to
> do it
> as a static site generator using Couchdb.
> 
> The reason for this is - I have used docpad in the past, and looked
> at all
> the various node.js static site generators and I feel that they are
> all
> inadequate for my needs as well as feeling sort of inefficient. The
> more I
> think about it I feel like I would want to use couchdb, but I mean it
> is
> sort of an intuition at this point because it's been so many years
> since
> I've used it.
> 
> So anyway, I'm hoping for recommendations before I get started -
> especially
> regarding
> 
> 1. does anyone already have a static site generator written in
> couchdb open
> sourced anywhere.
> 2. if you were building a static site generator using couchdb how
> would you
> go about it - any libaries tools you would recommend?
> 
> As for what my current plan is (in case you can see some points to
> improve):
> 
> Couchdb would be used as the document store, the rest api would be
> used to
> generate various static html files that would be saved into a logical
> folder structure.
> 
> The client that builds etc. is in node.js (I've been thinking of
> learning
> elixir [have played with erlang in the past] so if anyone can make a
> good
> argument why that would be a good language to use for this go ahead)
> 
> Data has to be presented in multiple views - a front page view
> (showing
> portions of new content sorted descending)
> subsite views ( showing portions of new content chosen by particular
> metadata sorted descending)
> randomized views for particular collections (generated I suppose once
> per
> day)
> ability to see works by author ( as there may be multiple authors
> involved)
> 
> The actual site will probably just be a very small express.js app
> that
> takes routes and serves the static files, however because of the
> elixir
> thing maybe should use phoenix for this.
> 
> anyway a typical blog but also something that should be adaptable
> enough to
> work as mid-level typical media site.
> 
> Thanks,
> Bryan Rasmussen
> 

Re: [PROPOSAL] Deprecate global functions in query server

[Joan Touzet]

> -2. still doesn’t solve that `function() {}` is not valid JavaScript
> and doesn’t work in newer SpiderMonkeys or other engines. But that
> might be out of scope.

IMO if you're going to tweak anything in the query definitions, you HAVE
to fix this - it's a bridge to us using any other engine and therefore
mandatory as a change at some point in the not too distant fugure.

I appreciate that we probably don't want to cram this change into 2.0,
but I'd ask the assembled people to at least consider it briefly before
agreeing to make it a mandatory 3.0 change.

-Joan

Re: Weekly News timing

[Joan Touzet]

It's fine :) See you tomorrow.

-Joan

- Original Message -
> From: "Katha" 
> To: marketing@couchdb.apache.org
> Sent: Thursday, November 26, 2015 6:18:49 AM
> Subject: Weekly News timing
> 
> Hi all,
> 
> quick question - hope it will be ok, if I send out the weekly news
> tomorrow? Having a rough schedule this week.
> 
> Best regards
> _
> Katharina

Re: Retiring AdvocateHub

[Joan Touzet]

Thanks Noah for getting it started, and Harald for driving this further!

CouchDB does need a social media presence, and AdvocateHub is a great
gamification strategy to drive that further.

-Joan

- Original Message -
> From: "Harald Kisch" 
> To: marketing@couchdb.apache.org
> Sent: Thursday, November 19, 2015 7:00:24 AM
> Subject: Re: Retiring AdvocateHub
> 
> Hi Noah,
> 
> can you give me a list of tasks which are necessary for contribution?
> I am also interested in the up-front investment tasks to get trained
> up.
> 
> It feels like feeding a dying horse but if you have medicine, we
> could get
> it up and running.
> For me the horse looks strong enough and if the the contribution
> takes 1 to
> 2 hours a week in the running phase, I can contribute much longer
> than 6
> months.
> 
> --Harald
> 
> 
> 
> On Thu, Nov 19, 2015 at 12:33 PM, Noah Slater 
> wrote:
> 
> > thanks Klaus <3
> >
> > Harald: for this to make sense you'd probably have to commit about
> > 4 hours
> > per week for a significant period of time (say 6 months at a
> > minimum). it
> > would also require an up-front investment of time to get yourself
> > trained
> > up on the hub
> >
> > I realise that's a lot! is it something you're still interested in?
> >
> > On Thu, 19 Nov 2015 at 12:24 Harald Kisch 
> > wrote:
> >
> > >  Hi Noah,
> > >
> > > i do not like to see such work getting retired.
> > > With 1 or 2 hours a week I would take care about it. Can you tell
> > > me
> > which
> > > actions are necessary to prevent the Advocate Hub from getting
> > > retired?
> > >
> > > --Harald
> > >
> > > On Thu, Nov 19, 2015 at 12:15 PM, Klaus Trainer <
> > klaus_trai...@apache.org>
> > > wrote:
> > >
> > > > On 11/18/2015 05:08 PM, Noah Slater wrote:
> > > > > thanks Johns! any other opinions on this?
> > > >
> > > > No opinion here on this particular issue.
> > > >
> > > > However, I'd like to express my deep gratitude for what you've
> > > > done for
> > > us.
> > > >
> > > > Starting with CouchDB's previous build system, you've cared
> > > > more and
> > > > more about issues that are critical to building a great
> > > > community,
> > which
> > > > are the actual important ones. You've put in a a lot of work
> > > > that
> > > > requires a lot of energy, and can sometimes be draining.
> > > >
> > > > Thank you so much, Noah!
> > > >
> > > >
> > > > To all:
> > > >
> > > > I know it's easier said than done, but let's not feel bad about
> > > > not
> > > > contributing (any)more! It kills the fun that we are supposed
> > > > to have,
> > > > and prevents us from enjoying what we came here for in the
> > > > first place.
> > > >
> > > > Take care everybody!
> > > >
> > > > Best,
> > > > Klaus
> > > >
> > > >
> > > > > On Sun, 15 Nov 2015 at 04:43 Johs Ensby  wrote:
> > > > >
> > > > >> Noah,
> > > > >>
> > > > >> Retire this thing with a good feeling of accomplishment, it
> > > > >> has
> > > surved a
> > > > >> good purpose.
> > > > >> You made us aware of the need for a community to build
> > > > >> content on
> > > Quora
> > > > >> and Stockoverflow and keep doing stuff in SoMe.
> > > > >>
> > > > >> The only thing that heals a burnout is to practice what we
> > > > >> preach;
> > > Relax
> > > > >> Johs
> > > > >>
> > > > >>> On 15. nov. 2015, at 01.14, Noah Slater
> > > > >>> 
> > wrote:
> > > > >>>
> > > > >>> Hey folks,
> > > > >>>
> > > > >>>
> > > > >>> Sorry for not being around much. I've been struggling with
> > > > >>> burnout
> > > and
> > > > >>> I haven't been able to contribute to CouchDB since April.
> > > > >>>
> > > > >>> Unfortunately that means our AdvocateHub program hasn't had
> > > > >>> anybody
> > > > >>> running it, and it's been in steady decline since I left.
> > > > >>>
> > > > >>> Here's a graph of monthly challenge completions:
> > > > >>>
> > > > >>> https://i.imgur.com/yd3IvaS.png
> > > > >>>
> > > > >>> This is a shame. I think AdvocateHub is a great product.
> > > > >>> And I
> > firmly
> > > > >>> believe that an advocate marketing programme could be
> > > > >>> hugely
> > > > >>> beneficial for CouchDB. But it needs someone with the time
> > > > >>> (and the
> > > > >>> spoons) to run it. For the time being, that isn't me.
> > > > >>>
> > > > >>> If someone is prepared to go through the AdvocateHub
> > > > >>> training
> > > > >>> programme, and commit some minimum amount of hours to it on
> > > > >>> a
> > weekly
> > > > >>> basis (four or more is probably advisable) I would be more
> > > > >>> than
> > happy
> > > > >>> to connect you with our account manager at Influitive. I
> > > > >>> could also
> > > > >>> share my private notes and ideas with you.
> > > > >>>
> > > > >>> Otherwise, I propose we retire it.
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> --
> > > > >>> Noah Slater
> > > > >>> https://twitter.com/nslater
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
> 

Re: MapReduce in CouchDB

[Joan Touzet]

Hi Craig,

Neat work, however:

- Original Message -
> From: "Alexander Shorin" 
> IIRC we already have sort of plug-able index engine. If AvanceDB is
> able to provide own as a library under non-GPL license,

This is critical. Would you consider relicensing AvanceDB under the Apache
license? As it stands, with you licensing it as GPL, there is no chance of
this project/code ever being included with CouchDB proper. Licensing will
even make it impossible for us to ship a shim library against which you
could link as a NIF (since you didn't pick LGPL either).

Please reconsider your licensing terms.

Thanks,
Joan Touzet

[jira] [Closed] (COUCHDB-2343) /_config/admins/username fails on master

[Joan Touzet (JIRA)]

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

Joan Touzet closed COUCHDB-2343.


> /_config/admins/username fails on master
> 
>
> Key: COUCHDB-2343
> URL: https://issues.apache.org/jira/browse/COUCHDB-2343
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: HTTP Interface
>Affects Versions: 2.0.0
>Reporter: Joan Touzet
>Priority: Blocker
>  Labels: auth
> Fix For: 2.0.0
>
>
> In a multi-node setup, calling _config/admins/username to create an admin 
> user fails to correctly configure a cluster with a new administrator. This 
> fails for two reasons:
> 1) The call is only processed on a single node, and the admin entry is not 
> replicated
> 2) Even if the call is repeated on all nodes manually, the hashes will be 
> different on each node, which will cause cookie failure when attempting to 
> authenticate via other machines.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [PROPOSAL] Allow rewrites to be JS function

[Joan Touzet]

- Original Message -
> From: "Harald Kisch" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, October 20, 2015 11:45:18 AM
> Subject: Re: [PROPOSAL] Allow rewrites to be JS function
> 
> Extendability and Upgradability with npm - what could be more
> extendable
> and more flexible?

Then run npm/Node alongside CouchDB. The containerization and
whitelisting required for the view server precludes a lot of what you
think you might be getting with "npm/CouchDB" integration. For instance,
views should not be able to open network ports, write to files on disk
or stream data to another database (e.g. MySQL/MariaDB).

You have most of the more experienced developers on this list,
including those who build other systems like PouchDB, telling you
that this invasive approach is substandard and will lead to more
problems than solutions.

-Joan

Re: Fauxton Windows developer question

[Joan Touzet]

Hi Robert,

I'm presently migrating our one Makefile left in couchdb to a Windows
NMakefile, which uses a different syntax.

git shell works but has enough problems that I don't want to rely on
it. Sometimes it's almost as much work to debug a GNU Makefile running
under cygwin as it is to rewrite the entire Makefile as an NMakefile.

It'd be super swell if you could avoid a GNU Makefile.

-Joan

- Original Message -
> From: "Robert Kowalski" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, October 20, 2015 10:12:17 AM
> Subject: Fauxton Windows developer question
> 
> Hey there,
> 
> I am currently working with our old & grown Gruntfile.js [1] together
> with
> the files in tasks/
> 
> The gruntfile has grown over the years and it got really hard to make
> changes to our buildsystem.
> 
> It also has some weird edge cases, as a release is made from the
> dist/debug
> folder, but the debug folder and it's contents is created from the
> task
> that spins up the devserver.
> 
> Anyway... right now I am trying to integrate Babel as react-tools are
> deprecated. After the update I want to update to React 14 (that's
> where my
> current journey began).
> 
> There are some tasks that would perfectly fit into a Makefile because
> they
> don't fit in a one liner as `npm run ` [2] (e.g. finding all
> .less
> files and feed them into the less compiler). I know that some people
> are
> using Windows and I am a super Windows noob.
> 
> Windows Fauxton developers:
> 
> Do Makefiles run in your Windows dev environment (e.g. via git shell
> et.
> al.) or would a make based build for Fauxton exclude you?
> 
> If it would exclude you, do you have a suggestion what to use?
> 
> Best,
> Robert :)
> 
> 
> [1]
> https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js
> [2]
> https://github.com/apache/couchdb-fauxton/blob/master/package.json#L50
> 

Re: [ANNOUNCE] Michelle Phung joins the PMC

[Joan Touzet]

What a climb, Michelle! Super stoked to have you in the PMC.

-Joan

- Original Message -
> From: "Andy Wenk" 
> To: dev@couchdb.apache.org
> Sent: Monday, October 19, 2015 9:42:15 AM
> Subject: Re: [ANNOUNCE] Michelle Phung joins the PMC
> 
> Hey Michell - cool to have you on board ;-) Let's Rock ... and
> Roll!!!
> 
> Cheers
> 
> Andy
> 
> On 19 October 2015 at 14:36, Robert Kowalski  wrote:
> 
> > Congrats Michelle! :)
> >
> > On Mon, Oct 19, 2015 at 12:33 PM, Robert Newson
> > 
> > wrote:
> >
> > > Welcome!
> > >
> > > > On 19 Oct 2015, at 11:08, Alexander Shorin 
> > > > wrote:
> > > >
> > > > Welcome, Michelle!
> > > > --
> > > > ,,,^..^,,,
> > > >
> > > >
> > > >> On Mon, Oct 19, 2015 at 12:59 PM, Garren Smith
> > > >> 
> > > wrote:
> > > >> Congratulations Michelle. This is great news.
> > > >>
> > > >>
> > > >>> On 19 Oct 2015, at 11:52 AM, Jan Lehnardt 
> > > >>> wrote:
> > > >>>
> > > >>> Dear community,
> > > >>>
> > > >>> I am delighted to announce that Michelle Phung joins the
> > > >>> Apache
> > > CouchDB Project Management Committee today.
> > > >>>
> > > >>> Michelle has made outstanding, sustained contributions to the
> > project.
> > > This appointment is an official acknowledgement of their position
> > > within
> > > the community, and our trust in their ability to provide
> > > oversight for
> > the
> > > project.
> > > >>>
> > > >>> Everybody, please join me in congratulating Michelle!
> > > >>>
> > > >>> On behalf of the CouchDB PMC,
> > > >>> Jan
> > > >>> --
> > > >>
> > >
> >
> 
> 
> 
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
> 
> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
> 
> https://people.apache.org/keys/committer/andywenk.asc
> 

Re: [ANNOUNCE] Garren Smith joins the PMC

[Joan Touzet]

Congratulations, Garren! Glad to have you with us.

-Joan

- Original Message -
> From: "Andy Wenk" 
> To: dev@couchdb.apache.org
> Sent: Monday, October 19, 2015 9:41:35 AM
> Subject: Re: [ANNOUNCE] Garren Smith joins the PMC
> 
> Hey Garren,
> 
> finally! welcome on board ;-)
> 
> All the best
> 
> Andy
> 
> On 19 October 2015 at 14:35, Robert Kowalski  wrote:
> 
> > Congrats! \o/
> >
> > On Mon, Oct 19, 2015 at 1:10 PM, Michelle Phung
> > 
> > wrote:
> >
> > > Yay Garren!
> > >
> > > \o/
> > >
> > > > On Oct 19, 2015, at 6:32 AM, Alexander Shorin
> > > > 
> > wrote:
> > > >
> > > > Congratulates, Garren! (:
> > > > --
> > > > ,,,^..^,,,
> > > >
> > > >
> > > > On Mon, Oct 19, 2015 at 1:31 PM, Jan Lehnardt 
> > > > wrote:
> > > >> Dear community,
> > > >>
> > > >> I am delighted to announce that Garren Smith joins the Apache
> > > >> CouchDB
> > > Project Management Committee today.
> > > >>
> > > >> Garren has made outstanding, sustained contributions to the
> > > >> project.
> > > This appointment is an official acknowledgement of their position
> > > within
> > > the community, and our trust in their ability to provide
> > > oversight for
> > the
> > > project.
> > > >>
> > > >> Everybody, please join me in congratulating Garren!
> > > >>
> > > >> On behalf of the CouchDB PMC,
> > > >> Jan
> > > >> --
> > > >>
> > >
> > >
> >
> 
> 
> 
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
> 
> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
> 
> https://people.apache.org/keys/committer/andywenk.asc
> 

Re: PMC members list

[Joan Touzet]

Everyone can read the bylaws for the Apache CouchDB project here:

https://couchdb.apache.org/bylaws.html

-Joan

- Original Message -
> From: "Jan Lehnardt" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, September 22, 2015 6:16:18 AM
> Subject: Re: PMC members list
> 
> In addition to Alexander’s mail:
> 
> > On 22 Sep 2015, at 11:51, Giovanni Lenzi 
> > wrote:
> > 
> > Hi all!
> > 
> > I'm here since some time now, but I still haven't fully understood
> > how many
> > members are in the PMC?
> > 
> > I think it would be useful for the community to have this
> > discussion filled
> > in with the full PMC members list and have this discussion updated
> > each
> > time someone leaves or is elected.
> 
> These things are always and have always been, as per ASF regulations,
> announced on the dev@ mailing list.
> 
> 
> > It would also be useful to mention who the Chairman is and his/her
> > term
> > dates.
> 
> I’m the PMC Chair, I just got renewed for another 12 months last
> week. The PMC Chair is elected ~yearly by the PMC Members.
> 
> The PMC Chair is also the Vice President of CouchDB at the Apache
> Software Foundation. The distinction is because projects within the
> ASF are independent. The highest office at Apache CouchDB is the PMC
> Chair. At the level of the ASF, the PMC Chair is the Vice President
> of the Project, responsible for communicating the project and its
> interests to the Board.
> 
> The office of the PMC Chair/VP is purely administrative, it has no
> special decision or voting rights or anything.
> 
> And for full disclosure, I’m also an ASF Member, e.g. I get to
> decide, along with all other Members ASF-wide policy, the board,
> etc.
> 
> Best
> Jan
> --
> 
> 
> > 
> > Thanks and Best Regards,
> > Giovanni
> 
> 

Re: The future of couchapps

[Joan Touzet]

I'll concur with Alex here. My survey of the PMC members so far has
resulted in 100% of us in agreement with Jan's comments.

This is not a power play, it is a logical, reasoned decision with many
factors that play a part -- not the least of which is that there are so
many great web frameworks out there that do such a better job than we do
with CouchApps. We'd need a massive effort to catch up with them, and a
significant number of developers just to keep pace. Right now, there's
no one working on CouchApps period, as has been repeatedly stated on the
list.

If you are willing to put in the time to develop the Erlang, JavaScript
and possibly C to build the new functionality, and are able to sustain
development on that over the course of the years it would take to match
e.g. Python or Node.JS's community level for web apps...well, let's just
say that I look forward to your GitHub pull requests. :)

Best regards,
Joan



- Original Message -
> From: "Alexander Shorin" 
> To: marketing@couchdb.apache.org
> Sent: Saturday, September 19, 2015 1:45:52 PM
> Subject: Re: The future of couchapps
> 
> Hi John,
> 
> The future of CouchApps is trivial and was already discussed on this
> ML[1]: this feature stalled over 4 years already, it has quite enough
> issues and limitations, it lacks maintainer. If something of these
> won't change in nearest future, CouchApps are doomed. And all
> solutions lies though the hero(es) who will maintain and develop this
> feature.
> 
> The question here is not only about to keep existed code works. It's
> also about vision of what CouchApps are, what they have to be, how to
> evolve them and make really great and useful feature for CouchDB
> users
> and not only.
> 
> Currently, there is no active leader of CouchApp feature in CouchDB
> team, so this place is vacant and we are welcome everyone who would
> like to take this duty on his/her shoulders.  Otherwise CouchApps
> will
> continue to be feature of secondary type, sort of accidental side
> effect from technical decisions of good past days. No need to say
> what
> such state means. They may simply not survive next major release.
> 
> [1]: Follow this thread:
> http://mail-archives.apache.org/mod_mbox/couchdb-marketing/201505.mbox/%3CCAPMhwa5R6CdeQP-m_FHfqYsJ4NDwLYiePuwrsi2bRfzifncRpw%40mail.gmail.com%3E
> - it's long, but has all the same answers.
> 
> --
> ,,,^..^,,,
> 
> 
> On Sat, Sep 19, 2015 at 8:16 PM, Johs Ensby  wrote:
> > Hi all -- both couchapp lovers and skeptics,
> >
> > I want to start a new thread based on the below conversation
> > between Jan and Giovanni at the end of the thread [VOTE]
> > WHY/HOW/WHAT.
> >
> > I am in the group of stakeholders that have a business that rely on
> > CouchDB. And I use couchApps hosted on Cloudant. I would like to
> > see the community grow, not split again and there seems to be a
> > tone developing that I am sorry if I have been a contributor to.
> > Rather than having wide-reaching discussion about dream features
> > of future couchapps, I will try to stay on the subject of a future
> > for couchapps or not.
> >
> > The "watch me" from Jan below is very disturbing to me.
> > I would appreciate seeing some comments from PMC members on this.
> >
> > Johs
> >
> >
> >> On 18. sep. 2015, at 13.52, Jan Lehnardt  wrote:
> >>
> >>> - you don't know if tomorrow some erlang skilled couchapp lover
> >>> won't get
> >>> in and start working on the app part (to say the truth some of
> >>> them were
> >>> already active in the past, but they chose to left just because
> >>> of
> >>> this/yours direction)
> >>
> >> In my last email I specifically suggested for such a person to
> >> step up and I’d welcome them wholeheartedly.
> >>
> >>
> >>> - you can't remove something that ALREADY exists which A LOT of
> >>> people
> >>> like, use and have businesses on top, just because you and a few
> >>> people
> >>> don't like it
> >>
> >> Watch me.
> >
> 

Re: [PROPOSAL] Remove oAuth for 2.0

[Joan Touzet]

I was one of the last people to leverage the CouchDB OAuth provider
in a commercial setting. That project ended nearly 4 years ago now.

What we have today is "2-legged" OAuth 1.0 compatibility that grew
out of functionality Ubuntu was looking for with the now-dead
UbuntuOne desktop functionality. It was a hack, a quick hack, and
ill-informed at that.

What most people wanted, back then, was "3-legged OAuth 1.0."
And we never coded that.

What people want today is full OAuth 2.0 or OpenID style functionality,
both as a consumer (log into Couch with your Twitter credentials) and
as a provider (log into a website using your Couch credentials). This
code serves neither purpose, and it's a long way from being there.

Drop the code from the repo.

-joan

- Original Message -
> From: "Alexander Shorin" 
> To: dev@couchdb.apache.org
> Sent: Thursday, September 17, 2015 5:03:14 PM
> Subject: Re: [PROPOSAL] Remove oAuth for 2.0
> 
> I played around with porting oauth to chttpd and what could I say...
> 
> After reading couch_httpd_oauth sources I understand why everyone
> wanted to get it out (:
> 
> OAuth 1.0 as like as OAuth 2.0 can act as auth provider: with special
> series of requests provider ensures that user credentials are valid
> and then moves it to the callback url.
> At the same time it can auth users without third party services.
> 
> We have last part implemented good: oauth_authentication_handler
> works
> right and I as a user happy with it.
> The part that turns CouchDB into auth provider is implemented by a
> half: we have the API, but it uses stubs.
> 
> So technically we have incomplete implementation of OAuth 1.0
> 
> And that's a good reason to drop it completely. Especially since
> OAuth
> 1.0 is deprecated and contains security issues.
> 
> However, our users still may use what we have in production. Our
> OAuth
> support is not just yet another. It's also special fields in user
> documents where personal token/secrets are defied. It's also special
> group of config options. It's also special auth.oauth object for
> replication task. In other words, there are quite much things we can
> break even with current state of things.
> 
> So I propose to limit our OAuth support to reasonable minimum that
> 100% works (auth provider, user docs, replication tasks). Deprecate
> all of this with 2.0 and eventually remove this in-between 2.0-3.0
> period when we'll have a time to provide better alternative solution
> and spread the work enough about to cause smooth migration.
> 
> Sounds good?
> 
> --
> ,,,^..^,,,
> 
> 
> On Fri, Sep 11, 2015 at 11:55 PM, Robert Newson 
> wrote:
> > +1 to remove oauth.
> >
> > Keen to see new authn and authz options for couchdb but that's a
> > separate topic.
> >
> >
> >
> >> On 11 Sep 2015, at 17:38, Jan Lehnardt  wrote:
> >>
> >> Let’s keep things separate.
> >>
> >> I propose moving broken oAuth support from 2.0. I’m prepared to do
> >> the legwork, it shouldn’t take long.
> >>
> >> If someone steps in and fixes oAuth for 2.0 VERY SOON, I’d be okay
> >> with keeping it.
> >>
> >> At this point, we are not discussing additional features for 2.0.
> >>
> >> If we get JWT, it goes into 2.1.
> >>
> >> Best
> >> Jan
> >> --
> >>
> >>
> >>
> >>> On 11 Sep 2015, at 16:50, Klaus Trainer 
> >>> wrote:
> >>>
> >>> Hi everybody!
> >>>
>  On 09/10/2015 08:20 PM, Alexander Shorin wrote:
>  Seems like there are no much options.
> 
>  I disagree that it's very poor. The only flaws it has is the
>  lack of
>  RSA support (our implementation) and open security issues (as
>  auth
>  protocol). But is there any good alternative?
> >>>
> >>> A good alternative would be to support JSON Web Token (JWT) [1].
> >>> Somebody has already done some work for CouchDB 1.6. in this
> >>> regard [2].
> >>> They managed to outsource authentication to Auth0, while
> >>> validating JWTs
> >>> issued by Auth0, and creating respective CouchDB sessions with
> >>> username
> >>> and roles assigned from the JWT [3, 4].
> >>>
> >>> In addition to what's been done in [2], I'd like CouchDB to be
> >>> able to
> >>> issue JWTs as well, which then could also be used by other
> >>> applications
> >>> for authentication and authorization.
> >>>
> >>> In contrast to OAuth 1.0a (which is implemented in CouchDB), JWT
> >>> is
> >>> conceptionally much simpler. It is easy to set up on servers, and
> >>> easy
> >>> to use for clients (e.g. in the browsers).
> >>>
> >>> Regarding implementing JWT in CouchDB: I'd like to volunteer and
> >>> can
> >>> allocate time for that.
> >>>
> >>> What do you think about supporting JWT?
> >>>
> >>>
> >>> [1] https://tools.ietf.org/html/rfc7519
> >>> [2] https://github.com/softapalvelin/couch_jwt_auth
> >>> [3] https://github.com/softapalvelin/getting-started-todo
> >>> [4] https://auth0.com/
> >>
> >> --
> >> Professional Support for Apache CouchDB:
> >> http://www.neighbourhood.ie/couchdb-support/
> >>
> 

Re: [VOTE] WHY/HOW/WHAT

[Joan Touzet]

My vote and reasoning matches Michelle's. Would be happy to see
more options and an additional vote, if people prefer.

-Joan

- Original Message -
> From: "Michelle Phung" 
> To: marketing@couchdb.apache.org
> Sent: Tuesday, September 15, 2015 4:07:54 PM
> Subject: Re: [VOTE] WHY/HOW/WHAT
> 
> #1: +1
> #2: -1
> reasons are inline
> 
> -michellep
> 
> > On Sep 15, 2015, at 3:51 PM, Jan Lehnardt  wrote:
> > 
> > Hi all,
> > 
> > as promised, here’s the vote for our new Slogan, Mission Statement,
> > and Description.
> > 
> > We have two contestants.
> > 
> > Before I show them to you, here are the rules:
> > 
> > 1. These aren’t final-copy-edit versions, but rough drafts that
> > convey ideas. After voting, we’ll go through them with a
> > fine-toothed comb to get things all shiny.
> > 
> > 2. The proposals don’t mean to capture a laundry list of your
> > favourite features of CouchDB. They are supposed to express the
> > focal point that our community gathers around, the thing that we
> > all have in common, what excites us all about CouchDB. Vote
> > accordingly.
> > 
> > 3. This emails contains two proposals. Vote by replying to this
> > email with your vote just under each proposal where it says “Your
> > Vote Here”.
> > 
> > 4. Vote with +1 (I support this), +/-0 (I’m indifferent, but no
> > harm done either way), -1 (I don’t like this, for reasons A, B and
> > C, (and please do include your reasons)).
> > 
> > 5. You are welcome to qualify your vote with your take on either
> > proposal.
> > 
> > 
> > A note: Johs, I took some inspiration from your WHAT-part, I hope
> > you don’t mind ;) —  I think we are essentially voting on WHY and
> > HOW anyway, as the WHAT is roughly the same idea.
> > 
> > Without further ado, here are our proposals.
> > 
> > * * *
> > 
> > Proposal #1:
> > 
> > Slogan: Data where you need it. (WHY)
> > 
> > Mission Statement: Apache CouchDB lets you access your data where
> > you need it by defining the Couch Replication Protocol that is
> > implemented by a variety of projects and products that span every
> > imaginable computing environment from distributed server-clusters,
> > over mobile phones to web browsers. (HOW)
> > 
> > Description: Store your data safely, on your own servers, or with
> > any leading cloud provider. Your web- and native applications love
> > CouchDB, because it speaks JSON natively and supports binary
> > attachments for all your data storage needs. The Couch Replication
> > Protocol lets your data flow seamlessly between server clusters to
> > mobile phones and web browsers, enabling a compelling,
> > offline-first, user-experience while maintaining high performance
> > and strong reliability. CouchDB comes with a developer-friendly
> > query language, and optionally MapReduce for simple, efficient,
> > and comprehensive data retrieval. (WHAT)
> > 
> > Your Vote Here
> +1
> seems straight-forward, language flows well
> > * * *
> > 
> > Proposal #2:
> > 
> > Slogan: Restful freedom (WHY)
> > 
> > Mission Statement: Data that sync (HOW)
> > 
> > Description:
> > Store your data safely, on your own servers or with any leading
> > cloud provider. Your web applications can follow the data if you
> > want since CouchDB speaks JSON with any file type attached. It
> > lets you run your JavaScript on the server or in the browser. You
> > can start with the smallest of technology stacks and grow to serve
> > millions of users -- following a learning curve that doesn't
> > break. Keep your data in sync and where your users need it to be,
> > on the device of their preference, online or offline. Share,
> > combine, present, receive and update documents via
> > master-to-master replication and let web based services monitor
> > changes for additional processing. (WHAT)
> > 
> > Your Vote Here
> -1
> don’t like the word “leading”, (seems unnecessary, and doesn’t denote
> anything) (this is in both descriptions btw)
> many colloquialisms
> "Share, combine, present, receive and update” is too long a list
> dislike the word ‘if’ used in the description, (making assumptions)
> 
> > * * *
> > 
> > Thanks!
> > Jan
> > --
> > 
> > 
> 
> 

Re: “Yes, and…”, not “But…” (Was: [PROPOSAL] Create des...@couchdb.apache.org mailing list)

[Joan Touzet]

Hit send too soon, see below

- Original Message -
> From: "Joan Touzet" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, September 15, 2015 10:39:01 PM
> Subject: Re: “Yes, and…”, not “But…” (Was: [PROPOSAL] Create 
> des...@couchdb.apache.org mailing list)
> 
> Hey there.
> 
> One thing we need to consider, Michelle:
> 
> The Bylaws for CouchDB and the Apache community guidelines state
> that all official *decisions* for the project must be reached on
> an official mailing list - not a Slack instance or IRC or an in-
> person meeting. We've (the PMC have) fought with this for
> years, and in the end we've always come to the conclusion that
> using

a mailing list gives us exactly what you said would be good:
a permanent record of the choices made, a way to ensure everyone
can participate (everyone has access to Email, but not necessarily
to IRC or Slack, and definitely not being somewhere in person), and
a simple format for proposals that everyone can agree upon. It's
also a push-not-pull format, which ensures everyone who wants to
be involved, can be.

> 
> So in the spirit of Yes And: Please use anything and everything
> you want to help inform the discussion and get creative juices
> flowing. But also please create the design@ mailing list and use
> it to make official decisions for the project when it comes time
> to make [PROPOSAL] and [VOTE] threads.
> 
> Thanks,
> Joan
> 
> - Original Message -
> > From: "Michelle Phung" 
> > To: dev@couchdb.apache.org
> > Sent: Monday, September 14, 2015 10:46:58 AM
> > Subject: Re: “Yes, and…”, not “But…” (Was: [PROPOSAL] Create
> > des...@couchdb.apache.org mailing list)
> > 
> > Hello!
> > 
> > I woke up today, with the first thing on my todo list: submit a
> > ticket to create a design@ML account. (Sry Kxepal!)
> > 
> > But then, I did not expect all the responses :)
> > 
> > It is a pleasant surprise for one of my proposal to generate so
> > many
> > emails.
> > It means that the community is *active*, and that people are
> > passionate and feel empowered enough to have an opinion to make it
> > a
> > better place. And good ideas are always welcome remember?
> > 
> > I really like that everyone is welcome to voice their opinions and
> > thoughts on the mailing list.
> > No one is a mind reader. But reading gives us a secret power to
> > reading thoughts.
> > 
> > The mailing list gives me a searchable, and easy way to keep up
> > with
> > everything, it is nearly real-time,
> > but can also work async, and it also gives people the chance to
> > formulate their thoughts a bit better than IRC.
> > 
> > I thought that a design@ML would be best for this,
> > 
> > HOWEVER, now after reading the discussion, I have changed my mind,
> > and now believe that that hosting design discussions for designers
> > would be better on a platform like medium.com, or at least
> > someplace
> > where we can host screenshots of our ideas.
> > 
> > That is a good idea! I am going to submit a proposal to do that
> > instead of the mailing list idea.
> > 
> > It will *SHOW* we are really trying to make the community a welcome
> > place for designers,
> > in their own language, without the overhead of a ML.
> > 
> > Lets move our platform-for-design-for-CouchDB discussion stuff
> > there.
> > 
> > The other stuff:
> > - You guys are arguing over what will make the CouchDB community
> > better, the MOST. This is a bit silly, but makes me smile, and my
> > heart swell with pride and happiness that everyone is on-board and
> > trying making this better.
> > - All of this is hard to do.
> > - I think everyone is doing a good job.
> > 
> > Michelle
> > 
> > PS. ermouth: I am sorry Cloudant broke somethings of yours. We were
> > trying to make things safer. We did not mean to intentionally break
> > anything.
> > 
> > 
> > > On Sep 14, 2015, at 9:22 AM, ermouth  wrote:
> > > 
> > >> I think it comes back to trust, if we all trust each other
> > >> that we have the best of the project in mind
> > > 
> > > If @kxepal says there is no activity in www@ – he is right. Facts
> > > are
> > > stubborn things. If he predicts there will be no users in design@
> > > with
> > > current approach – he is right.
> > > 
> > > I can‘t imagine @kxepal don‘t trust you, or Robert, or Michelle.
> > > Surely, he
> > > trust. He just pointing out 

Re: “Yes, and…”, not “But…” (Was: [PROPOSAL] Create des...@couchdb.apache.org mailing list)

[Joan Touzet]

Hey there.

One thing we need to consider, Michelle:

The Bylaws for CouchDB and the Apache community guidelines state
that all official *decisions* for the project must be reached on
an official mailing list - not a Slack instance or IRC or an in-
person meeting. We've (the PMC have) fought with this for
years, and in the end we've always come to the conclusion that
using 

So in the spirit of Yes And: Please use anything and everything
you want to help inform the discussion and get creative juices
flowing. But also please create the design@ mailing list and use
it to make official decisions for the project when it comes time
to make [PROPOSAL] and [VOTE] threads.

Thanks,
Joan

- Original Message -
> From: "Michelle Phung" 
> To: dev@couchdb.apache.org
> Sent: Monday, September 14, 2015 10:46:58 AM
> Subject: Re: “Yes, and…”, not “But…” (Was: [PROPOSAL] Create 
> des...@couchdb.apache.org mailing list)
> 
> Hello!
> 
> I woke up today, with the first thing on my todo list: submit a
> ticket to create a design@ML account. (Sry Kxepal!)
> 
> But then, I did not expect all the responses :)
> 
> It is a pleasant surprise for one of my proposal to generate so many
> emails.
> It means that the community is *active*, and that people are
> passionate and feel empowered enough to have an opinion to make it a
> better place. And good ideas are always welcome remember?
> 
> I really like that everyone is welcome to voice their opinions and
> thoughts on the mailing list.
> No one is a mind reader. But reading gives us a secret power to
> reading thoughts.
> 
> The mailing list gives me a searchable, and easy way to keep up with
> everything, it is nearly real-time,
> but can also work async, and it also gives people the chance to
> formulate their thoughts a bit better than IRC.
> 
> I thought that a design@ML would be best for this,
> 
> HOWEVER, now after reading the discussion, I have changed my mind,
> and now believe that that hosting design discussions for designers
> would be better on a platform like medium.com, or at least someplace
> where we can host screenshots of our ideas.
> 
> That is a good idea! I am going to submit a proposal to do that
> instead of the mailing list idea.
> 
> It will *SHOW* we are really trying to make the community a welcome
> place for designers,
> in their own language, without the overhead of a ML.
> 
> Lets move our platform-for-design-for-CouchDB discussion stuff there.
> 
> The other stuff:
>   - You guys are arguing over what will make the CouchDB community
>   better, the MOST. This is a bit silly, but makes me smile, and my
>   heart swell with pride and happiness that everyone is on-board and
>   trying making this better.
>   - All of this is hard to do.
>   - I think everyone is doing a good job.
> 
> Michelle
> 
> PS. ermouth: I am sorry Cloudant broke somethings of yours. We were
> trying to make things safer. We did not mean to intentionally break
> anything.
> 
> 
> > On Sep 14, 2015, at 9:22 AM, ermouth  wrote:
> > 
> >> I think it comes back to trust, if we all trust each other
> >> that we have the best of the project in mind
> > 
> > If @kxepal says there is no activity in www@ – he is right. Facts
> > are
> > stubborn things. If he predicts there will be no users in design@
> > with
> > current approach – he is right.
> > 
> > I can‘t imagine @kxepal don‘t trust you, or Robert, or Michelle.
> > Surely, he
> > trust. He just pointing out real problems, and this is absolutely
> > ortogonal
> > to trust.
> > 
> > Not everyone pointing out a problem can immidiately propose a
> > solution.
> > Issue fixing starts from bug itself, not from patch. And I can‘t
> > imagine,
> > how you can start bug report with ‘Yes, and...’. There is nothing
> > barbarian
> > in ‘It won‘t work in this way’ or ‘But how about this?’.
> > 
> >> That’s the kind of stuff that makes we very very tired
> >> participating here
> > 
> > Sorry, but just repeating your own words: ‘If that makes you want
> > to
> > unsubscribe, farewell’. Writing it not to prick you, but to point
> > out, that
> > if you issue rules about friendliness, you better obey them by
> > yourself
> > first.
> > 
> >> [Alexnder Shorin] What really hurts conversations is
> >> false-positive
> > feedback, when you
> >> have to lie people and lie to yourself about foreign ideas.
> > 
> > Absolutely. +1000.
> > 
> > ermouth
> > 
> > 2015-09-14 15:49 GMT+03:00 Jan Lehnardt :
> > 
> >> 
> >>> On 14 Sep 2015, at 14:42, ermouth  wrote:
> >>> 
>  I’m suggesting a way how we can adopt a proven way
>  If that makes you want to unsubscribe, farewell.
> >>> 
> >>> That is exactly what I called iron ordnung. Extreme
> >>> unfriendliness is
> >> only
> >>> allowed for your here, Jan. The one thing I fear now is that
> >>> people are
> >>> afraid to say ‘but’, or take a contrarian position in general.
> >>> How can we
> >>> avoid that?
> >> 
> >> I think it comes back to trust, if we all trust e

Re: Brainstorm: A new CouchDB tag-line?

[Joan Touzet]

+1

- Original Message -
> From: "Jan Lehnardt" 
> To: marketing@couchdb.apache.org
> Cc: priv...@couchdb.apache.org
> Sent: Wednesday, September 9, 2015 11:45:40 AM
> Subject: Re: Brainstorm: A new CouchDB tag-line?
> 
> I’d like to get this wrapped up and I propose a similar process to
> what we did for the logo:
> 
> 1. Have us (marketing@) come up with a few alternative approaches
> (all addressing WHY, HOW, WHAT, split out in a Slogan (WHY), Mission
> Statement (HOW) and Description (WHAT) that we can use all over our
> messaging.
> 
> 2. Put the candidates to a vote here on marketing@, the top 5-10 (if
> we get that many) then go to a vote on dev@
> 
> 3. From the vote result on dev@, the PMC then makes a decision on the
> final set.
> 
> It’d be great if we get this rounded up by ApacheCon EU (that’s Sept
> 28), and because of that, I propose the following schedule:
> 
> marketing@ vote on Sept 15 (next Tuesday), gives us just under a week
> to drum up a few alternatives
> 
> dev@ vote on Sept 18 right after the marketing@ vote closes. There is
> no more discussion at this point, this is an automatic procedure.
> 
> PMC starts deciding from Sept 21, right after the dev@ vote and we’ll
> try to get this wrapped by Sept 25, so we have a few days to spare,
> and time to prepare materials for the 28th.
> 
> All aboard?
> 
> Best
> Jan
> --
> 
> 
> > On 29 Aug 2015, at 11:56, Jan Lehnardt  wrote:
> > 
> > (repost in the right thread, sorry about that)
> > 
> > Thanks for getting this discussion going again, Joan!
> > 
> > Here is where we discussed this last fall: Thread “New motto?”:
> > http://apache.markmail.org/thread/6k6qtc65vtnse5ls (incomplete
> > results, because the MarkMail interface is weird, but should get
> > you the main parts)
> > 
> > In there, we follow the search for our WHY, which defines our HOW
> > and that in turn defines our WHAT (context
> > http://markmail.org/message/346bxv4v3sq7ofoj)
> > 
> > Noah summed up our discussion back then
> > (http://markmail.org/message/h2dm233yjuphtufw):
> > 
> >> WHY -- Getting your data where ever you need it (mobile,
> >> geolocations, cloud, etc)
> > 
> >> HOW -- Sync protocol (with CouchDB as the reference
> >> implementation)
> > 
> >> WHAT -- Erlang, MapReduce, CouchDB Query, REST, JSON, JavaScript,
> >> etc., etc.
> > 
> > 
> > The slogan we are looking for now is addressing the WHY and the WHY
> > only. The HOW and the WHAT also deserve treatment though, but
> > these need to live elsewhere.
> > 
> > Let’s attempt to organise this a little:
> > 
> > Project name: Apache CouchDB
> > 
> > Nickname: CouchDB
> > 
> > Slogan: Data where you need it. (WHY)
> > 
> > Mission Statement: Apache CouchDB aims to foster an ecosystem of
> > software that can flexibly share data with each other by defining
> > a universal synchronisation protocol. (HOW)
> > 
> > Description: CouchDB is the focal point of the Couch Sync Protocol
> > suite which is implemented by an ecosystem of projects that all
> > work in concert to fulfil a universal vision: being able to share
> > and access data where it has the most value, from cross
> > data-center cluster to mobile phones. CouchDB is an
> > Erlang-implementation of the Couch Sync Protocol with a strong
> > focus on reliability, durability and scaling. CouchDB uses HTTP
> > for its API, JSON for documents, and a developer-friendly query
> > language and optionally MapReduce for efficient data retrieval.
> > (WHAT)
> > 
> > * * *
> > 
> > Let’s collect variations of this and counter examples, but let’s
> > keep the same form:
> > 1. Address the WHY, HOW and WHAT
> > 2. Define: Name, Nickname, Slogan, Mission Statement and
> > Description (we can rename the labels later, for now it is
> > important to get the copy text for the WHY, HOW and WHAT right).
> > 
> > 
> > * * *
> > 
> > FWIW: PouchDB nicked the “The database that syncs” from an email of
> > mine on dev@ two years ago, when this was discussed first (and
> > kudos to them for realising it is a great slogan and running with
> > it!). I see no harm in the two projects sharing this, or
> > coordinating, e.g. CouchDB: The database that syncs. PouchDB: The
> > JavaScript database that syncs, or somesuch. (not saying this is a
> > proposal of mine, but if anyone wants to advocate it, I’d be happy
> > to listen and hear a proposal).
> > 
> > * * *
> &

Re: CouchDB _rewrite

[Joan Touzet]

Proedurally, CouchDB 2.0 is effectively in feature freeze - we need to
get it out the door, it is far overdue.

Looking at changing basic functionality like _rewrite can come after
2.0 is done, in the 3.0 timeframe.

-Joan

- Original Message -
> From: "Johs. E" 
> To: "d...@couchdb.apache.org Developers" 
> Cc: marketing@couchdb.apache.org
> Sent: Friday, September 4, 2015 8:21:12 AM
> Subject: CouchDB _rewrite
> 
> Fellow CouchDB enthusiasts,
> 
> Let me quote a dialogue I had the other day with a colleague on
> Couchapps and _rewrite:
> 
> > > I would like to know what is so horrible with the vhost/rewrite
> > > of CouchDB
> > You must concentrate all rules in one place, that is totally out of
> > idea ‘one app – one ddoc’
> > Capturing mechanics is outrageously ugly and limiting. You can‘t
> > capture on query, only on path, and in very limiting manner.
> > Obsolete for at least 15 years.
> > Rule lists are flat – they must be trees, since it‘s json, not SQL
> > table of directory with files.
> > It‘s all very brittle, error prone and imposes all possible hurdles
> > during debug – no err messages, no log, no validator.
> > And most important: it creates illusion, that it can fit everything
> > – but it only fits small static-like sites.
> > > Is it something that could be fed to the developers?
> > 
> > Don‘t think anybody of them is interested. This functions assumed
> > obsolete or impractical by the vast majority of community, as I
> > see. And I agree with them.
> 
> Still with its limitations, I love _rewrite
> You direct the vhost to db/_design/api/_rewrite
> using so-called “unsafe” rewrites, you create an API for your many
> databases and their couchapps there.
> It works beautifully.
> That is at Cloudant. I think I learned from an earlier discussion
> that the lack of a “default vhost” is a problem outside Cloudant.
> Now Cloudant does not offer SSL unless you enter into a relationship
> with your local IBM organization and buy a dedicated cluster under a
> std IBM contract, so
> 
> Of course I would like to see a better rewrite function, my priority
> would be
> A tree structure of rules
> Capture query in the “to”
> That would be a great enhancement to go with version 2.0
> 
> br
> Johs
> 
> 

Re: CouchDB _rewrite

[Joan Touzet]

Proedurally, CouchDB 2.0 is effectively in feature freeze - we need to
get it out the door, it is far overdue.

Looking at changing basic functionality like _rewrite can come after
2.0 is done, in the 3.0 timeframe.

-Joan

- Original Message -
> From: "Johs. E" 
> To: "dev@couchdb.apache.org Developers" 
> Cc: market...@couchdb.apache.org
> Sent: Friday, September 4, 2015 8:21:12 AM
> Subject: CouchDB _rewrite
> 
> Fellow CouchDB enthusiasts,
> 
> Let me quote a dialogue I had the other day with a colleague on
> Couchapps and _rewrite:
> 
> > > I would like to know what is so horrible with the vhost/rewrite
> > > of CouchDB
> > You must concentrate all rules in one place, that is totally out of
> > idea ‘one app – one ddoc’
> > Capturing mechanics is outrageously ugly and limiting. You can‘t
> > capture on query, only on path, and in very limiting manner.
> > Obsolete for at least 15 years.
> > Rule lists are flat – they must be trees, since it‘s json, not SQL
> > table of directory with files.
> > It‘s all very brittle, error prone and imposes all possible hurdles
> > during debug – no err messages, no log, no validator.
> > And most important: it creates illusion, that it can fit everything
> > – but it only fits small static-like sites.
> > > Is it something that could be fed to the developers?
> > 
> > Don‘t think anybody of them is interested. This functions assumed
> > obsolete or impractical by the vast majority of community, as I
> > see. And I agree with them.
> 
> Still with its limitations, I love _rewrite
> You direct the vhost to db/_design/api/_rewrite
> using so-called “unsafe” rewrites, you create an API for your many
> databases and their couchapps there.
> It works beautifully.
> That is at Cloudant. I think I learned from an earlier discussion
> that the lack of a “default vhost” is a problem outside Cloudant.
> Now Cloudant does not offer SSL unless you enter into a relationship
> with your local IBM organization and buy a dedicated cluster under a
> std IBM contract, so
> 
> Of course I would like to see a better rewrite function, my priority
> would be
> A tree structure of rules
> Capture query in the “to”
> That would be a great enhancement to go with version 2.0
> 
> br
> Johs
> 
> 

Re: CouchDB Weekly News – Submissions

[Joan Touzet]

Hi Katharina,

My talk's video recording is now online.

https://www.youtube.com/watch?v=iKKkKkWATDo

-Joan

- Original Message -
> From: "Katharina Jockenhöfer" 
> To: u...@couchdb.apache.org, market...@couchdb.apache.org, 
> dev@couchdb.apache.org
> Sent: Thursday, September 3, 2015 7:45:10 AM
> Subject: CouchDB Weekly News – Submissions
> 
> Hello all!
> 
> please send me submissions for the CouchDB Weekly News if you have
> any!!
> 
> Especially for
> - News in the CouchDB and PouchDB universe
> - Opinions, good articles/talks
> - Interesting use cases
> - CouchDB related events
> 
> Your support is much appreciated.
> 
> Have a great day!
> Katharina
> 

Re: [ANNOUNCE] Clemens Stolle elected as CouchDB committer

[Joan Touzet]

Welcome!

- Original Message -
> From: "Klaus Trainer" 
> To: dev@couchdb.apache.org
> Sent: Friday, August 28, 2015 6:06:54 AM
> Subject: Re: [ANNOUNCE] Clemens Stolle elected as CouchDB committer
> 
> Welcome Clemens :)
> 
> 
> On 08/27/2015 01:47 PM, Robert Kowalski wrote:
> > Dear community,
> > 
> > I am pleased to announce that the CouchDB Project Management
> > Committee
> > has elected Clemens Stolle as a CouchDB committer.
> > 
> > Apache ID: klaemo
> > 
> > IRC nick: klaemo
> > 
> > Twitter: @klaemo
> > 
> > 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 Clemens'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 Clemens!
> > 
> > On behalf of the CouchDB PMC,
> > Robert :)
> > 
> 

Re: Brainstorm: A new CouchDB tag-line?

[Joan Touzet]

Just a point that "The database that syncs" is PouchDB's tagline.
Probably should take it out of the running.

I knew I'd seen it somewhere :D

The PMC will take the feedback from this discussion and decide what
to do next. A vote is not necessarily the best next step here.

-Joan

- Original Message -
> From: "Mike Broberg" 
> To: marketing@couchdb.apache.org
> Sent: Thursday, August 27, 2015 9:21:04 AM
> Subject: Re: Brainstorm: A new CouchDB tag-line?
> 
> 
> 
> Thanks, Adam. So we don't all agree and that's cool, but how do we
> come to a consensus on the tag lines? Should we put a few of them to
> a community vote?
> 
> ---
> 
> Documents, Applications, Replication, REST. Data wherever you need it
> Sync. Shard. REST. Apache CouchDB: The database that
> {replicates|syncs}
> ---
> 
> Those all seem like recent options to me. Am I missing any proposed
> tag lines?
> 
> I know there are some Apache community rules for making that happen,
> but I'm not familiar with the mechanics. Thank you. --Mike
> --
> Mike Broberg | IBM Cloud Data Services | 200 State Street, Boston, MA
> 02109 | mbrob...@us.ibm.com
> --
> 
> Inactive hide details for Adam Kocoloski ---08/17/2015 11:21:39
> PM---Thanks for digging that one up Broberg! I’m partial to “Adam
> Kocoloski ---08/17/2015 11:21:39 PM---Thanks for digging that one up
> Broberg! I’m partial to “Data wherever you need it” - replication,
> sh
> 
> From: Adam Kocoloski 
> To: marketing@couchdb.apache.org
> Date: 08/17/2015 11:21 PM
> Subject: Re: Brainstorm: A new CouchDB tag-line?
> 
> 
> 
> 
> Thanks for digging that one up Broberg! I’m partial to “Data wherever
> you need it” - replication, sharding, mobile, REST can all be viewed
> through that same lens.
> 
> Adam
> 
> > On Aug 10, 2015, at 11:30 AM, Tim Black 
> > wrote:
> > 
> > While I like "The database that syncs" and "Data wherever you need
> > it"
> > best, perhaps the recommendation below could be reworded "Sync
> > documents
> > & applications via REST."
> > 
> > Tim
> > 
> > On 08/10/2015 10:05 AM, Miles Fidelman wrote:
> >> Mike Broberg wrote:
> >>> 
> >>> I also like what Joan cited below, and agree that reinforcing
> >>> replication is important. "Apache CouchDB: The database that
> >>> {replicates|syncs}."
> >>> 
> >> 
> >> Leaves out way too much. Personally, I think that REST is
> >> critical.
> >> 
> >> More like
> >> 
> >> jav...@candeira.com wrote:
> >>> 
> >>> During the logo discussion some time ago I suggested this
> >>> three-word
> >>> tagline:
> >>> 
> >>> Sync. Shard. REST.
> >> 
> >> I'd kind of go more with something like:
> >> Documents, Applications, Replication, REST.
> >> 
> >> Miles Fidelman
> >> 
> >> 
> >> 
> > 
> 
> 
> 
> 
> 

Brainstorm: A new CouchDB tag-line?

[Joan Touzet]

Hey everyone, 

I don't know where we landed on this discussion last time, but I'm
fairly sure we didn't come to any sort of agreement.

Our current tag-line for CouchDB is pretty unwieldy:

 "Apache CouchDB is a database that uses JSON for documents,
  JavaScript for MapReduce indexes, and regular HTTP for its API"

With the addition of mango, it's also inaccurate. I'm sure we can do
better!

Previously I remember seeing the suggestion:

  "Apache CouchDB: The database that {replicates|syncs}."

I'm finding that really snappy. If you had to pick a single feature that
CouchDB does better than anyone else, it's the multi-master replication.
It does leave out a lot of great things we do, though.


Here's the taglines of some of our "competitors":

"The Apache Cassandra database is the right choice when you need
scalability and high availability without compromising performance."

"Apache HBase™ is the Hadoop database, a distributed, scalable, big
data store."

"The Apache™ Hadoop® project develops open-source software for reliable,
scalable, distributed computing."

"CouchBase 3.0: A distributed database engineered for performance,
scalability, and simplified administration."

"MongoDB: Agility, scalability, performance. Pick three."

"Redis is an open source, BSD licensed, advanced key-value cache and 
store."

"Riak KV is a distributed NoSQL database that is highly available,
scalable and easy to operate"

"ElasticSearch: Search & Analyze Data in Real Time"


What other ideas do you have for a tagline for CouchDB? The only rules
are: one sentence, the shorter the better, and focused on CouchDB's
unique strength(s).

-Joan


Disclaimer: This is brainstorming only. The discussion may or may not
lead to a new CouchDB tagline. Please, no negativity. 

Re: couchdb question

[Joan Touzet]

Hi Mahesh,

I am replying to the CouchDB Users' mailing list as well. You may
find more help there than just my response. I recommend you subscribe
to the list to see any other responses and to get in touch with other
CouchDB users.

- Original Message -
> From: "Mahesh Kanniah" 
> To: woh...@atypical.net
> Sent: Thursday, July 16, 2015 2:20:58 AM
> Subject: couchdb question
> 
> 
> Joan,
> Just saw a video on couchdb by you. Impressive!

Thank you for your kind words!

> I have a couple of questions on couchdb. I would be happy if you can
> share your thoughts on the same.
> 
> 
> I will give a background of what i am working on. I am making an all
> in one organizer that stores all your contacts, todos, financials
> and pretty much everything a person would want to store all the way
> from BMI to pills and documents from passports to credit cards and
> so on. Synced across their phones/tablets and pc.
> 
> 
> I am using pouchdb on the client end for the replication and it works
> pretty well at least under test environment. What i am confused is
> how do i store the data correctly in the first place.
> 
> 
> So Joan is a USER. She has different documents like todos and bank
> statement records.
> 
> 
> Here is are the questions.
> 
> 
> 1. Should joan be given a single database. The per user database
> system?
> And should she store all the documents in the single database. If
> each document has a different schema wouldn't it be taxing to filter
> / query them. But again as finally the user is going to filter them
> OFFLINE on their devices (phones) is it just as simple as replicate
> the data and do all the filtering client side and shut the case?

Yes, database per user is a good model for this setup. Filtering by
document type is a very common CouchDB data model.

 
> 2. Couchdb has this revisioning system. It maintains revisions which
> i suppose is a good thing. Now 99.99% of the time my user or anyone
> is just happy to get the latest data. Is there some funda of telling
> couchdb not to store revisions or is it a part of couchdb that the
> revisions are essentially important to make sure the synchronization
> is effected correctly? I mean is it like hey if you want
> synchronization then it needs to have revisions.

Do not think of _rev as a revisioning system. It is only used to ensure
that data is stored consistently across multiple replicas, especially
when updates are done to multiple replicas and replicated with each
other (so-called multi-master replication).

> 3. In couchdb when a document is deleted there is nothing like
> deletion but a revision setting the document to a state of RETIRED.

_deleted: true, though depending on the delete method all other fields
are typically removed (by using the HTTP DELETE verb, for instance)

> This retired documents will keep growing. For ex. i make 1
> records and delete all of them. When i bring in a fresh device and i
> do my first time sync it is going to get me all the 1 records
> and then finally mark them off as deleted whereas the active
> documents might be a handful.

Filtered replication can remove these so-called tombstones if there
is a very high volume of deleted documents. You can use views to 
determine the %age of tombstones in a db and use filtered replication
to remove them if necessary.

> Would it be wise that retired documents be re-used ?
> Like for ex. I Create a bank statement record and instead of
> inserting it into the database i check if there is a retired
> document available. If it is available i update that instead and
> mark it as active than creating a new document.

No, because when deleted using the best method available all old fields
are removed from the document. If you want to keep old documents, then
do not use the DELETE method but create your own delete, such as 
an inactive: true/false field. In this setup your data will always
grow (no documents will ever be deleted) but you can always undelete
any document you need. The choice is yours depending upon the data
access methodology you want.

Hope this helps,
Joan Touzet

Re: Windows PR #2

[Joan Touzet]

And letting people know I'll validate this Wednesday, I am 
unavailable Tuesday.

Thanks Paul!

-Joan

- Original Message -
> From: "Paul Davis" 
> To: dev@couchdb.apache.org, "Joan Touzet" 
> Sent: Tuesday, July 14, 2015 2:43:13 AM
> Subject: Re: Windows PR #2
> 
> Just a note on this thread that there's a PR open for the khash
> issue.
> 
> https://github.com/apache/couchdb-khash/pull/3
> 
> Yay. Now bedtime.
> 
> On Mon, Jul 13, 2015 at 5:04 PM, Joan Touzet 
> wrote:
> > - Original Message -
> >> From: "Dave Cottlehuber" 
> >> To: dev@couchdb.apache.org
> >> Sent: Monday, July 13, 2015 4:19:58 PM
> >> Subject: Re: Windows PR #2
> >>
> >> On Mon, 13 Jul 2015, at 09:56 PM, Joan Touzet wrote:
> >> > I intend to publish it in detail once we have the khash issue
> >> > sorted out, but in short:
> >> >
> >> > Windows 7 VM
> >> > MSVC 2013 Community Edition
> >> > Erlang 17.5 (didn't want to jump right to 18.x yet)
> >> > Latest Mozilla build chain (for Spidermonkey only)
> >> > ICU latest, binary download only
> >> >
> >> > For Spidermonkey, I have a minor source tree tweak that allows
> >> > this build chain to work correctly a) without your crazy
> >> > setup in glazier and b) against MSVC 2013 which was not
> >> > out when 1.8.5 was released. I also build it 64-bit, but
> >> > haven't been able to test it yet (because of khash).
> >>
> >> re (a), nice! Not needing the extra shell malarkey is a big help.
> >> One less toolchain :D
> >>
> >> I have tried in the past just unpacking the pre-compiled official
> >> erlang release and putting it in the right place beside the source
> >> tarball, which also worked but I'm a little nervous about whether
> >> that is a legitimate approach or not. That could get us down to
> >> just erlang + MSVC which would be a huge step forwards in
> >> simplicity.
> >
> > Oh, I wasn't building Erlang either, I was using the official
> > binary
> > downloads. The only thing I was building was SM1.8.5. So yup, we're
> > in good shape.
> >
> > I just need help with the khash changes proposed by Paul, I'm at a
> > loss as to where to start.
> >
> > -Joan
> 

Re: Windows PR #2

[Joan Touzet]

- Original Message -
> From: "Dave Cottlehuber" 
> To: dev@couchdb.apache.org
> Sent: Monday, July 13, 2015 4:19:58 PM
> Subject: Re: Windows PR #2
> 
> On Mon, 13 Jul 2015, at 09:56 PM, Joan Touzet wrote:
> > I intend to publish it in detail once we have the khash issue
> > sorted out, but in short:
> > 
> > Windows 7 VM
> > MSVC 2013 Community Edition
> > Erlang 17.5 (didn't want to jump right to 18.x yet)
> > Latest Mozilla build chain (for Spidermonkey only)
> > ICU latest, binary download only
> > 
> > For Spidermonkey, I have a minor source tree tweak that allows
> > this build chain to work correctly a) without your crazy
> > setup in glazier and b) against MSVC 2013 which was not
> > out when 1.8.5 was released. I also build it 64-bit, but
> > haven't been able to test it yet (because of khash).
> 
> re (a), nice! Not needing the extra shell malarkey is a big help.
> One less toolchain :D
> 
> I have tried in the past just unpacking the pre-compiled official
> erlang release and putting it in the right place beside the source
> tarball, which also worked but I'm a little nervous about whether
> that is a legitimate approach or not. That could get us down to
> just erlang + MSVC which would be a huge step forwards in
> simplicity.

Oh, I wasn't building Erlang either, I was using the official binary
downloads. The only thing I was building was SM1.8.5. So yup, we're
in good shape.

I just need help with the khash changes proposed by Paul, I'm at a
loss as to where to start.

-Joan

Re: Windows PR #2

[Joan Touzet]

I intend to publish it in detail once we have the khash issue
sorted out, but in short:

Windows 7 VM
MSVC 2013 Community Edition
Erlang 17.5 (didn't want to jump right to 18.x yet)
Latest Mozilla build chain (for Spidermonkey only)
ICU latest, binary download only

For Spidermonkey, I have a minor source tree tweak that allows 
this build chain to work correctly a) without your crazy
setup in glazier and b) against MSVC 2013 which was not
out when 1.8.5 was released. I also build it 64-bit, but
haven't been able to test it yet (because of khash).

-Joan

- Original Message -
> From: "Dave Cottlehuber" 
> To: dev@couchdb.apache.org
> Sent: Sunday, July 12, 2015 3:29:59 AM
> Subject: Re: Windows PR #2
> 
> On Sun, 12 Jul 2015, at 02:06 AM, Joan Touzet wrote:
> > https://github.com/apache/couchdb-couch/pull/69
> > 
> > Same thing.
> > 
> > Message to follow with important release-blocking info.
> 
> Also +1 super!
> 
> What erlang, windows + msvc  setup are you using for this?
> 
> A+
> Dave
> 

Re: Windows build blocked by khash NIF

[Joan Touzet]

I scoured the mailing lists but was unable to find any sort of patch
for this, submitted or not. It's certainly not landed in v18.0.x.

Perhaps Paul is aware of the patch as a starting place at least?

- Original Message -
> From: "Adam Kocoloski" 
> To: dev@couchdb.apache.org, "Joan Touzet" 
> Sent: Saturday, July 11, 2015 10:08:43 PM
> Subject: Re: Windows build blocked by khash NIF
> 
> There’s a comment in the code where we declare make_hash2() which
> states
> 
> > // There's a pending patch to expose this in the NIF API in newer
> > Erlangs.
> 
> Did that patch ever land?
> 
> Adam
> 
> > On Jul 11, 2015, at 8:54 PM, Joan Touzet  wrote:
> > 
> > Alex says:
> >> On Sun, Jul 12, 2015 at 3:14 AM, Joan Touzet 
> >> wrote:
> >>>  1) Build a custom beam.smp.dll on Windows that exports
> >>>  make_hash2
> >> 
> >> Sounds as the right solution, but how it will complicate build
> >> process?
> > 
> > It means that Windows builds have to have a custom built Erlang
> > with patches that we write. Windows builds will never be able to
> > run
> > against stock Erlang builds from erlang.org. We will be responsible
> > for
> > rebuilding and patching as new versions of Erlang are released,
> > e.g. for
> > security patches.
> > 
> >>>  2) Revert to the old-style ets approach on Windows,
> >>>  conditionally
> >>> using khash only on *NIX.
> >> 
> >> Sounds as the simplest solution, but won't it cause any issues?
> > 
> > Bob Newson proposed this solution. It's going to take a bunch of
> > build
> > magic to make happen, as we have to load the khash app only when
> > not
> > running on a Windows platform. The old code should be around
> > somewhere,
> > but I've not looked at it in a long while.
> > 
> >> Also, how about ask on erlang-questions@ about export make_hash2?
> >> Sure, it won't solve problems for now, but could help in the
> >> future.
> > 
> > If you want to ask please be my guest, my time is limited.
> > 
> 
> 

Re: Windows build blocked by khash NIF

[Joan Touzet]

Alex says:
> On Sun, Jul 12, 2015 at 3:14 AM, Joan Touzet 
> wrote:
> >   1) Build a custom beam.smp.dll on Windows that exports make_hash2
> 
> Sounds as the right solution, but how it will complicate build
> process?

It means that Windows builds have to have a custom built Erlang
with patches that we write. Windows builds will never be able to run
against stock Erlang builds from erlang.org. We will be responsible for
rebuilding and patching as new versions of Erlang are released, e.g. for
security patches.

> >   2) Revert to the old-style ets approach on Windows, conditionally
> >  using khash only on *NIX.
> 
> Sounds as the simplest solution, but won't it cause any issues?

Bob Newson proposed this solution. It's going to take a bunch of build
magic to make happen, as we have to load the khash app only when not
running on a Windows platform. The old code should be around somewhere,
but I've not looked at it in a long while.

> Also, how about ask on erlang-questions@ about export make_hash2?
> Sure, it won't solve problems for now, but could help in the future.

If you want to ask please be my guest, my time is limited.

Windows build blocked by khash NIF

[Joan Touzet]

Hello everyone,

Progress on the Windows build was surprisingly smooth, thanks to native
MSVC build chain support in rebar, and improved in the version I am
running locally (2.6.0).

Unfortunately, we have a release blocker on Windows in the khash NIF.
This NIF expects to call an Erlang BEAM VM internal function,
make_hash2(). This function is *not* exported in erl_interface, and only
works on *NIX platforms because the khash .so NIF is loaded into a
calling binary that has make_hash2 defined internally.

It is very naughty that we do this, and I'm disappointed this code made
it into the tree in its current state. But such is life ^_^;

On Windows, the BEAM VM is self-contained in a dll (beam.smp.dll) which
is called by a nearly stub-sized Erlang executable (erl.exe).  The
beam.smp.dll exports only 3 functions, none of which are make_hash2().

Further complicating things, on Windows any DLL that calls an
external requires that external function to be declared in a .lib
or .def file sourced from the original. I attempted faking a 
beam.smp.def/beam.smp.lib of the form:

EXPORTS
make_hash2

and linking, but to no avail - again because make_hash2 is optimized
away inside of the beam.smp.dll, not externally referenceable.

In short, we have three options:

  1) Build a custom beam.smp.dll on Windows that exports make_hash2

  2) Revert to the old-style ets approach on Windows, conditionally
 using khash only on *NIX.

  3) Ship CouchDB 2.0 without a Windows build.

My research about this time last year indicated that Windows downloads
of CouchDB actual exceeded downloads of couchdb.tar.gz from
http://couchdb.apache.org/, on the order of ~1 DLs per month total
(between 500-2000 per month more than the tarball.) My guess is that a
lot of developers use it for local developing or prototyping purposes.
Either way, it seems the Windows build is popular, and we drop support
for it in 2.0 at our peril.

Thoughts?

Windows PR #2

[Joan Touzet]

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

Same thing.

Message to follow with important release-blocking info.

Windows PR #1

[Joan Touzet]

https://github.com/apache/couchdb-b64url/pull/3

Can I get a +1 before I merge this?

More Windows build details to come.

Re: [PROPOSAL] Workflow with forked repos

[Joan Touzet]

Alex wrote:

> - When need knocks the door, we merge upstream into master, where our
> local changes happens;

We will need to be careful about this not to undo the changes
we need for ourselves, for instance re-introducing a binary rebar or
clobbering our .travis files as you point out.

As such merging upstream should be done into another branch where work
is done and a PR is issued before we merge *that* branch into master.

-Joan

Re: [master] rebar failing get-deps on win64

[Joan Touzet]

Update: deleting the entire src/ tree allowed this to proceed. I
remember running into this issue while building bigcouch, and I'm
not sure there is a good fix other than updating make dist-clean
to forcibly remove the entire src/ tree (today we just remove
src/docs).

What do you think of such a make target? There's no other way to
readily recover from a failed get-deps (due to e.g. poor network
connectivity during a git clone)

-Joan

- Original Message -
> From: "Joan Touzet" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, June 30, 2015 11:05:23 PM
> Subject: [master] rebar failing get-deps on win64
> 
> Hi there, I'm in the process of trying to get CouchDB 2.0 ported
> to Windows. I've reproduced the configure script in PowerShell
> script and am proceeding to work on the Makefiles, but I'm running
> into a get-deps issue where it fails to pull the couch_index deps.
> 
> As my time is limited on this project, might anyone have any ideas
> to help me out?
> 
> Here's the complete output of a clean followed by a get-deps:
> 
> PS C:\workspace\couchdb> rebar -r clean
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_index
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_mrview
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_replicator
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_plugins
> WARN:  Expected c:/workspace/couchdb/src/docs to be a raw dependency
> directory, but no directory found.
> WARN:  Expected c:/workspace/couchdb/src/fauxton to be a raw
> dependency directory, but no directory found.
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/ibrowse
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/mochiweb
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/snappy
> ==> b64url (clean)
> ==> cassim (clean)
> ==> lager (clean)
> ==> couch_log (clean)
> ==> config (clean)
> ==> chttpd (clean)
> ==> couch (clean)
> ==> couch_epi (clean)
> ==> rel (clean)
> ==> couchdb (clean)
> PS C:\workspace\couchdb>
> PS C:\workspace\couchdb>
> PS C:\workspace\couchdb> rebar get-deps
> 
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_index
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_mrview
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_replicator
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_plugins
> WARN:  Expected c:/workspace/couchdb/src/docs to be a raw dependency
> directory, but no directory found.
> WARN:  Expected c:/workspace/couchdb/src/fauxton to be a raw
> dependency directory, but no directory found.
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/ibrowse
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/mochiweb
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/snappy
> ==> b64url (get-deps)
> ==> cassim (get-deps)
> ==> lager (get-deps)
> ==> couch_log (get-deps)
> ==> config (get-deps)
> ==> chttpd (get-deps)
> ==> couch (get-deps)
> ==> couch_epi (get-deps)
> ==> rel (get-deps)
> ==> couchdb (get-deps)
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_index
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_mrview
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_replicator
> WARN:  Directory expected to be an app dir, but no app file found
> in ebin/ or src/:
> c:/workspace/couchdb/src/couch_plugins
> WARN:  Expected c:/workspace/couchdb/src/docs to be a raw dependency
> directory, but no directory found.
> WARN:  Expected c:/workspace/couchdb/src/fauxton to be a raw
> dependency directory, but

Re: ApacheCon Core & Big Data EU

[Joan Touzet]

I have two talks submitted, one is a tutorial for CouchDB 2.0 (Big Data)
and one is on Communities and Codes of Conduct (Core).

My arm could be twisted to propose a third, but without a funding source
to attend (TAC is still down and I haven't heard back from the Linux
foundation) I will be unable to attend.

-Joan

- Original Message -
> From: "Benjamin Young" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, June 30, 2015 10:40:14 PM
> Subject: ApacheCon Core & Big Data EU
> 
> Hi all!
> 
> In case you missed it, the Call for Proposals ends tomorrow (July 1)
> for ApacheCon: Core EU in Budapest, October 1-2:
> http://events.linuxfoundation.org/events/apachecon-core-europe/program/cfp
> 
> Apache: Big Data EU is the 3 days prior, September 28 - 30th in the
> same location. It's CfP ends on the 10th:
> http://events.linuxfoundation.org/events/apachecon-core-europe/program/cfp
> 
> I've submitted one talk to both, and would encourage anyone
> considering submitting to hurry up and do so! ;)
> 
> I asked around in IRC and there's a handful of folks submitting. I'd
> love to see if we could land a "mini-summit" for Apache
> CouchDB-which would essentially amount to our having about 6 talks
> accepted so we'd have our own track.
> 
> Regardless, I'd love to get as many of as can together at ApacheCon
> to meet-up, exchange notes, and dive deeper into the cushions of
> CouchDB. There's so much great stuff happening for CouchDB right
> now, it really just needs vocal champions. :)
> 
> If you submit, it'd be great to know here on the list, so we can get
> a sense of who's hoping to go-as that might give us the opportunity
> for a "mini-summit" or BarCamp Apache space or some such.
> 
> Thanks, all!
> Benjamin
> --
> bigblue...@apache.org
> http://bigbluehat.com/
> 

[master] rebar failing get-deps on win64

[Joan Touzet]

Hi there, I'm in the process of trying to get CouchDB 2.0 ported
to Windows. I've reproduced the configure script in PowerShell
script and am proceeding to work on the Makefiles, but I'm running
into a get-deps issue where it fails to pull the couch_index deps.

As my time is limited on this project, might anyone have any ideas
to help me out?

Here's the complete output of a clean followed by a get-deps:

PS C:\workspace\couchdb> rebar -r clean
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_index
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_mrview
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_replicator
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_plugins
WARN:  Expected c:/workspace/couchdb/src/docs to be a raw dependency directory, 
but no directory found.
WARN:  Expected c:/workspace/couchdb/src/fauxton to be a raw dependency 
directory, but no directory found.
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/ibrowse
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/mochiweb
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/snappy
==> b64url (clean)
==> cassim (clean)
==> lager (clean)
==> couch_log (clean)
==> config (clean)
==> chttpd (clean)
==> couch (clean)
==> couch_epi (clean)
==> rel (clean)
==> couchdb (clean)
PS C:\workspace\couchdb>
PS C:\workspace\couchdb>
PS C:\workspace\couchdb> rebar get-deps

WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_index
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_mrview
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_replicator
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_plugins
WARN:  Expected c:/workspace/couchdb/src/docs to be a raw dependency directory, 
but no directory found.
WARN:  Expected c:/workspace/couchdb/src/fauxton to be a raw dependency 
directory, but no directory found.
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/ibrowse
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/mochiweb
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/snappy
==> b64url (get-deps)
==> cassim (get-deps)
==> lager (get-deps)
==> couch_log (get-deps)
==> config (get-deps)
==> chttpd (get-deps)
==> couch (get-deps)
==> couch_epi (get-deps)
==> rel (get-deps)
==> couchdb (get-deps)
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_index
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_mrview
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_replicator
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_plugins
WARN:  Expected c:/workspace/couchdb/src/docs to be a raw dependency directory, 
but no directory found.
WARN:  Expected c:/workspace/couchdb/src/fauxton to be a raw dependency 
directory, but no directory found.
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/ibrowse
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/mochiweb
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/snappy
WARN:  Directory expected to be an app dir, but no app file found
in ebin/ or src/:
c:/workspace/couchdb/src/couch_index
ERROR: Dependency dir c:/workspace/couchdb/src/couch_index failed application 
validation with reason:
{missing_app_file,"c:/workspace/couchdb/src/couch_index"}.
ERROR: 'get-deps' failed while processing C:/workspace/couchdb: rebar_abort

Re: ApacheCon EU 2015 and track registration

[Joan Touzet]

And FYI I have submitted my talk for this track which is now entitled

"Communities matter: Developing and Enforcing the Apache Code of Conduct"

A separate talk for CouchDB is also being submitted.

-Joan

- Original Message -
> From: "Bertrand Delacretaz" 
> To: "Pierre Smits" 
> Cc: "Noah Slater" , "Joan Touzet" , 
> "Bertrand Delacretaz"
> , "Maxim Solodovnik" , 
> apachecon-discuss@apache.org
> Sent: Monday, June 29, 2015 9:23:15 AM
> Subject: Re: ApacheCon EU 2015 and track registration
> 
> Hi,
> 
> On Thu, Jun 11, 2015 at 11:32 PM, Pierre Smits
>  wrote:
> > ...A few months ago I contacted you about building a track for the
> > upcoming
> > ApacheCon EU 2015 event in Budapest on Oct 1st-2nd. ...
> 
> FYI I have now submitted my talks including "Will the Apache Maturity
> Model save your project?"
> 
> -Bertrand
> 

[jira] [Commented] (COUCHDB-2390) Fauxton config, admin sections considered dangerous in 2.0

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606230#comment-14606230
 ] 

Joan Touzet commented on COUCHDB-2390:
--

/cc @davisp [~rnewson] [~janl]

If we are documenting single-node installs of CouchDB 2.0 as running against 
the node-local port (5986) then I think we are done here. If we are instead 
recommending users hit 5984 on a single node DB with 2.0 then more work is 
required.

> Fauxton config, admin sections considered dangerous in 2.0
> --
>
> Key: COUCHDB-2390
> URL: https://issues.apache.org/jira/browse/COUCHDB-2390
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: BigCouch, Fauxton
>Reporter: Joan Touzet
>Assignee: Ben Keen
>Priority: Blocker
> Fix For: 2.0.0
>
>
> In Fauxton today, there is are 2 sections to edit config-file settings and to 
> create new admins. Neither of these sections will work as intended in a 
> clustered setup.
> Any Fauxton session will necessarily be speaking to a single machine. The 
> config APIs and admin user info as exposed will only add that information to 
> a single node's .ini file.
> We should hide these features in Fauxton for now (short-term fix) and correct 
> the config /admin creation APIs to work correctly in a clustered setup 
> (medium-term fix).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: CouchDB utc_id behavior

[Joan Touzet]

now() is not guaranteed to be monotonically increasing if the system
clock rolls backwards, which various things can cause.

You should look into setting up ntpd for your two machines at the very
least.

-Joan

- Original Message -
> From: "Nick North" 
> To: user@couchdb.apache.org
> Sent: Monday, June 15, 2015 12:14:50 PM
> Subject: Re: CouchDB utc_id behavior
> 
> The utc_id algorithm uses Erlang's now() function for generating
> timestamps. This is guaranteed to be monotonic increasing, but not
> necessarily to be in very close correspondence with the operating
> system
> clock all the time, especially if you call it very frequently.
> However, I'm
> surprised that calls seconds apart are giving this problem. Are your
> machines VMs? There can be clock problems when they are suspended and
> reactivated, with clocks initially having the time when the machine
> was
> suspended, and then jumping forward, but that's unlikely if they are
> in
> fairly constant use. For what it's worth, I use utc_id timestamps for
> sorting documents, and have not seen this problem, but that doesn't
> help
> you very much.
> 
> Nick
> 
> On Mon, 15 Jun 2015 at 16:42 Kiril Stankov 
> wrote:
> 
> > Hi,
> >
> > nope, this is not the case.
> > The newer document has older ID, this is the problem.
> >
> > 05188de92ef02f < 05188e0805067f
> >
> > But
> > 05188de92ef02f
> > was created after
> > 05188e0805067f
> >
> >
> > 
> > *With best regards,*
> > Kiril Stankov,
> >
> > On 15-Jun-15 6:08 PM, Alexander Shorin wrote:
> > > Time resolution is in microseconds, so difference in one second
> > > generated notable "leap" forward.
> > > --
> > > ,,,^..^,,,
> > >
> > >
> > > On Mon, Jun 15, 2015 at 5:10 PM, Kiril Stankov
> > > 
> > wrote:
> > >> Hi all,
> > >>
> > >> I have two CouchDB (v1.6.1) servers, fully synchronized between
> > >> them
> > >> (master-to-master).
> > >> The uuids algorithm is utc_id.
> > >> The servers are synchronized via ntp and there is practically no
> > >> time
> > offset
> > >> between them.
> > >> I notice a strange behavior of the ID's of newly posted
> > >> documents.
> > >> In some cases, posting to server1, will generate ID, which is
> > >> later
> > than a
> > >> subsequent post to server 2.
> > >> E.g., posting to server 1 generates ID:
> > >> 05188e0805067f_1
> > >> and then, few seconds later, posting to server 2 generates:
> > >> 05188de92ef02f_2
> > >> As you see, the timestamp of the second message is earlier than
> > >> the
> > first
> > >> (_1 & _2 are suffixes for the two servers).
> > >> This is causing me a big mess, as I use the timestamp to sort
> > >> and order
> > >> documents.
> > >> Any idea why this happens?
> > >> Can someone, please, shed more light on how CouchDB "reads" the
> > >> time
> > for the
> > >> generation of the ID?
> > >> Or if you have an idea what may be causing this behavior.
> > >>
> > >> Thanks in advance!
> > >>
> > >> 
> > >> *With best regards,*
> > >> Kiril Stankov,
> > >>
> >
> >
> 

Re: [PROPOSAL] GitHub issues

[Joan Touzet]

> > On 03 Jun 2015, at 21:46, Joan Touzet  wrote:
> > 
> >>> The system of record needs to remain JIRA.
> >> 
> >> Why?

Breaking in here again - this question makes it sound like you are
arguing against the system of record being JIRA. See below...

> > 
> > Because (ASF Member hat on) if GH goes away, the project would be
> > crippled, severely so. Losing the institutional memory of what
> > is going on is a serious problem.
> 
> That’s why I suggested the option of a sync bridge like we do with
> PRs
> (which are just issues with a patch attached).

If a new GH Issue is created, are you proposing an Infra bot
creates/owns the issue in JIRA? If so then JIRA is still the system
of record and I have little-to-no issue.

> 
> > Because otherwise you need to migrate a couple thousand bugs
> > out of JIRA, including all history, into GH, which is problematic
> > and
> > will certainly result in a loss of fidelity.
> 
> Why? I didn’t suggest retiring JIRA.

I thought you were. My mistake. If we are just considering GH Issues
as a frontend to JIRA, and JIRA remains the system of record, similar
to how GH is just a front end for getting things officially merged
into our ASF git repo, I am fine.

> > Do not conflate system performance with reason for existence and
> > utility. Would you feel differently if performance was up to par?
> 
> I find the UI overly complex, uninviting and downright confusing, no
> matter the performance, but the fact that it takes 30-60 seconds for
> every interaction makes me going to JIRA the rarest occasion. I can’t
> imagine how this feels to the regular / drive contributor, because I
> have the patience to sit through this.

I regularly use a JIRA instance with zero performance issues and it's
a joy to use, especially the task planning board where cards are
dragged around. It's really not far off from the Trello user experience
except there are more things that can be filled in.

> > We should definitely take up this issue with Infra *separately* as
> > the inability for us to do our work within the system clearly is
> > having a material impact.
> 
> +1.

As you are the one having the most issues, can you start the discussion
with Infra? ;)

Re: [PROPOSAL] GitHub issues

[Joan Touzet]

> > The system of record needs to remain JIRA.
> 
> Why?

Because (ASF Member hat on) if GH goes away, the project would be 
crippled, severely so. Losing the institutional memory of what
is going on is a serious problem.

Because otherwise you need to migrate a couple thousand bugs
out of JIRA, including all history, into GH, which is problematic and
will certainly result in a loss of fidelity.

Because even the GH employees I'm friends with tell me that Issues
is nowhere near feature rich enough even for their own work, and
especially not when having to interface with other organizations
(such as corporate sponsors/participants). I admit this is opinion
and hearsay but it bears repeating since right now the argument seems
to be "I like GH issues, let's use it instead,"

> > GH Issues is no replacement for JIRA; the fidelity of the system is
> > vastly different.
> 
> We barely use any JIRA features that GH issues doesn’t do :)

I consider this a failing on our part. My illness has stood in the way
of me being more involved in cleaning it up, but with proper tending
it could be every bit as enjoyable as we'd all like it to be IMO.
 
> Every JIRA page I try to load takes at least 1 minute (I’m not
> exaggerating).

Do not conflate system performance with reason for existence and
utility. Would you feel differently if performance was up to par?

We should definitely take up this issue with Infra *separately* as
the inability for us to do our work within the system clearly is
having a material impact.


> I could see a mirror system where GH issues create JIRA issues and
> comments
> are synced both ways, but I’d be fine without that and only have
> GitHub
> notifications go into notifications@c.a.o so we have all content in
> ASF-land.

Tracking comments on issues on a mailing list is no substitute for an
ASF-hosted issue tracker. In fact, since you are discussing changing
the system of record to GH Issues entirely, I am updating my feelings
to -1, full stop.

-Joan

Re: [PROPOSAL] GitHub issues

[Joan Touzet]

Personally I'm -0.5 on this.

The system of record needs to remain JIRA. GH Issues is no replacement
for JIRA; the fidelity of the system is vastly different.

We need more people cleaning up JIRA and making that environment
make more sense, not to add clutter to the pile by enabling issues.

Wouldn't it be more reasonable to have a GH PR result in a JIRA ticket
created by an anonymous user that sent an email out, and allowed
updating via replying to that email?

-Joan

- Original Message -
> From: "Jan Lehnardt" 
> To: dev@couchdb.apache.org
> Sent: Wednesday, June 3, 2015 3:01:47 PM
> Subject: Re: [PROPOSAL] GitHub issues
> 
> 
> > On 03 Jun 2015, at 20:57, Robert Kowalski  wrote:
> > 
> > Hi list,
> > 
> > I would like to propose that we additionally enable GitHub issues
> > for
> > our GitHub repos and would like to send this email to Infra:
> 
> Oh, I like this! :)
> 
> I’m +1, let’s try to make this happen!
> 
> Best
> Jan
> --
> 
> > 
> > 
> > Hi infra team,
> > 
> > I got an question regarding contributions and I would like to find
> > out
> > what is required and how we (CouchDB) can help.
> > 
> > We are trying a lot to make contributing to CouchDB easier to
> > attract
> > more contributors and grow our community. We see a lot of benefits
> > in
> > allowing contributors to use GitHub when working on CouchDB. We’re
> > already using the already extensive GitHub / ASF integration and it
> > is
> > working very well for us.
> > 
> > I would like to know what is required to use "GitHub issues" for
> > CouchDB. Registering a separate new account is a hurdle not many
> > potential contributors (from code contributions to bug reports and
> > feedback) are willing to take and we are trying to make it as easy
> > as
> > possible to contribute to CouchDB. Quite often even our fresh
> > elected
> > committers don't have a Jira account and they create it after their
> > election, but they all have GitHub accounts.
> > 
> > We really want to make it as easy as possible for our potential
> > contributors and having GitHub issues enabled would help us a lot!
> > We
> > could mirror the GitHub issues to Jira so we still have them all
> > recorded in our Jira.
> > 
> > We would like to find out what is required to make it happen. We
> > would
> > also love to help you with that!
> > 
> > 
> > Best,
> > Robert
> 
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
> 
> 

Re: [DISCUSSION] nmo to the ASF

[Joan Touzet]

Thanks for the info on the separate repos. I assumed that since
we already have Couch scattered across a large # of repos.

It's all about what sort of build instructions we put in the "main"
CouchDB distribution. As long as the main build script doesn't
auto-forcibly-invoke building of all of these other tools, I'm fine.

Assuming the above is true I'm +1.

-Joan

- Original Message -
> From: "Jan Lehnardt" 
> To: dev@couchdb.apache.org, "Joan Touzet" 
> Sent: Wednesday, June 3, 2015 2:06:41 PM
> Subject: Re: [DISCUSSION] nmo to the ASF
> 
> 
> > On 03 Jun 2015, at 19:35, Joan Touzet  wrote:
> > 
> > Is the intent with all of these contributions to ship them in
> > a contrib/ tree? We're starting to get cluttered with tools and
> > languages, and with couchdb-python also in the wings as potential
> > contribution, I am concerned about the build process for the
> > tool mandating npm, python, etc.
> 
> I see them in different repos with their own build/release cycles
> that aren’t bound to core CouchDB.
> 
> The CouchDB distribution then can choose to bundle whatever latest
> version of whatever tool when its time to release comes up. I see
> it making more sense for nmo (I think of it as Fauxton-CLI) and less
> for couchdb-python and nano, but this is all open for debate, my
> main point here is that these are not bound to an Apache CouchDB
> Release necessarily.
> 
> Does this address your concerns?
> > 
> > -Joan
> > 
> > - Original Message -
> >> From: "Jan Lehnardt" 
> >> To: dev@couchdb.apache.org
> >> Sent: Wednesday, June 3, 2015 9:32:00 AM
> >> Subject: Re: [DISCUSSION] nmo to the ASF
> >> 
> >> 
> >>> On 03 Jun 2015, at 15:24, Alexander Shorin 
> >>> wrote:
> >>> 
> >>> On Wed, Jun 3, 2015 at 4:12 PM, Jan Lehnardt 
> >>> wrote:
> >>>>> On 03 Jun 2015, at 15:09, Alexander Shorin 
> >>>>> wrote:
> >>>>> 
> >>>>> On Wed, Jun 3, 2015 at 4:01 PM, Jan Lehnardt 
> >>>>> wrote:
> >>>>>>> On 03 Jun 2015, at 14:43, Alexander Shorin 
> >>>>>>> wrote:
> >>>>>>> 
> >>>>>>> On Wed, Jun 3, 2015 at 1:40 PM, Jan Lehnardt 
> >>>>>>> wrote:
> >>>>>>>>> On 03 Jun 2015, at 04:38, Alexander Shorin
> >>>>>>>>> 
> >>>>>>>>> wrote:
> >>>>>>>>> 
> >>>>>>>>> Hi Robert,
> >>>>>>>>> 
> >>>>>>>>> What's the rationale of your donation?
> >>>>>>>> 
> >>>>>>>> The benefit then is that we can ship it with CouchDB :)
> >>>>>>>> 
> >>>>>>>> I’m +1000, I’ve wanted something like this forever.
> >>>>>>> 
> >>>>>>> I'm not sure that we'll have consensus on shipping nodejs
> >>>>>>> tools,
> >>>>>>> especially with current state of nodejs.
> >>>>>> 
> >>>>>> The current state of Node.js is fine.
> >>>>> 
> >>>>> I wouldn't say that: node.js is dead, io.js develops quite
> >>>>> fast,
> >>>>> but
> >>>>> they provides broken releases for Windows and Linux quite often
> >>>>> (2.1.0
> >>>>> was broken for instance for me and I had to wait for 2.2.1).
> >>>> 
> >>>> Node.js is not dead. Please stop posting FUD.
> >>>> 
> >>>> The io.js and Node.js projects are going to be merged in the
> >>>> future, work
> >>>> is currently ongoing. Node.js has stable releases all around,
> >>>> there is no
> >>>> technical reason, not to bet on it. There is a significant
> >>>> community and
> >>>> industry around Node.js/io.js.
> >>> 
> >>> I don't watch the TV. Good news then (:
> >> 
> >> Hahahah :D
> >> 
> >> Best
> >> Jan
> >> --
> >> 
> >> 
> 
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
> 
> 

Re: [DISCUSSION] nmo to the ASF

[Joan Touzet]

Is the intent with all of these contributions to ship them in
a contrib/ tree? We're starting to get cluttered with tools and
languages, and with couchdb-python also in the wings as potential
contribution, I am concerned about the build process for the
tool mandating npm, python, etc.

-Joan

- Original Message -
> From: "Jan Lehnardt" 
> To: dev@couchdb.apache.org
> Sent: Wednesday, June 3, 2015 9:32:00 AM
> Subject: Re: [DISCUSSION] nmo to the ASF
> 
> 
> > On 03 Jun 2015, at 15:24, Alexander Shorin 
> > wrote:
> > 
> > On Wed, Jun 3, 2015 at 4:12 PM, Jan Lehnardt 
> > wrote:
> >>> On 03 Jun 2015, at 15:09, Alexander Shorin 
> >>> wrote:
> >>> 
> >>> On Wed, Jun 3, 2015 at 4:01 PM, Jan Lehnardt 
> >>> wrote:
> > On 03 Jun 2015, at 14:43, Alexander Shorin 
> > wrote:
> > 
> > On Wed, Jun 3, 2015 at 1:40 PM, Jan Lehnardt 
> > wrote:
> >>> On 03 Jun 2015, at 04:38, Alexander Shorin 
> >>> wrote:
> >>> 
> >>> Hi Robert,
> >>> 
> >>> What's the rationale of your donation?
> >> 
> >> The benefit then is that we can ship it with CouchDB :)
> >> 
> >> I’m +1000, I’ve wanted something like this forever.
> > 
> > I'm not sure that we'll have consensus on shipping nodejs
> > tools,
> > especially with current state of nodejs.
>  
>  The current state of Node.js is fine.
> >>> 
> >>> I wouldn't say that: node.js is dead, io.js develops quite fast,
> >>> but
> >>> they provides broken releases for Windows and Linux quite often
> >>> (2.1.0
> >>> was broken for instance for me and I had to wait for 2.2.1).
> >> 
> >> Node.js is not dead. Please stop posting FUD.
> >> 
> >> The io.js and Node.js projects are going to be merged in the
> >> future, work
> >> is currently ongoing. Node.js has stable releases all around,
> >> there is no
> >> technical reason, not to bet on it. There is a significant
> >> community and
> >> industry around Node.js/io.js.
> > 
> > I don't watch the TV. Good news then (:
> 
> Hahahah :D
> 
> Best
> Jan
> --
> 
> 

Re: On Plugins and Extensibility

[Joan Touzet]

My mistake :) 

- Original Message -
> From: "Paul Davis" 
> To: dev@couchdb.apache.org, "Joan Touzet" 
> Sent: Wednesday, May 27, 2015 1:51:33 PM
> Subject: Re: On Plugins and Extensibility
> 
> On Wed, May 27, 2015 at 11:55 AM, Joan Touzet 
> wrote:
> > I've skimmed the entire thread, and it seems like Ilya is trying to
> > solve a much bigger problem than Paul has outlined. Ilya's approach
> > is
> > more all-encompassing but involves a lot of "make-work" just to get
> > the
> > system back to its current state. Meanwhile, Paul is trying to
> > respond
> > to some requests for enhancement (presumably coming thru
> > IBM/Cloudant)
> > and is suggesting just enough functionality to fix that.
> >
> > Unless there are more developers outside of IBM willing to
> > contribute
> > code towards Ilya's proposal my guess is that IBM won't approve the
> > resources for such a vast change, and I'm not seeing people rushing
> > to
> > help implement this approach who are well acquainted with the couch
> > codebase.
> >
> > Paul, consider this a vote of support in favour of your proposal,
> > subject
> > to the concerns already raised. What does Bob have to say?
> >
> > -Joan
> 
> This is actually in response to the CouchDB Community's concern that
> the number of extension points being defined in the config files was
> growing to the point where it was confusing and misleading since
> they're a mostly different type of configuration. This lead to the
> vendor specific plugin proposal that was accepted as a good approach
> at solving that issue. Ilya did some work on this via plugerl. When
> reviewing that I realized that we have at least three places
> (couch_stats, chttpd handlers, plugerl, and I keep thinking I'm
> forgetting one more) where we have roughly the same issue of trying
> to
> connect various parts of the code base in a configurable manner (at
> the release level). So rather than have three different approaches I
> thought it'd be useful to take a step back and try and design
> something that could solve each of these cases in a single spot
> rather
> than having multiple implementations of roughly the same
> functionality.
> 
> So no, this isn't motivated by IBM. Its motivated by not wanting to
> have three implementations of basically the same thing in CouchDB.
> 

Re: On Plugins and Extensibility

[Joan Touzet]

I've skimmed the entire thread, and it seems like Ilya is trying to 
solve a much bigger problem than Paul has outlined. Ilya's approach is
more all-encompassing but involves a lot of "make-work" just to get the
system back to its current state. Meanwhile, Paul is trying to respond
to some requests for enhancement (presumably coming thru IBM/Cloudant)
and is suggesting just enough functionality to fix that.

Unless there are more developers outside of IBM willing to contribute
code towards Ilya's proposal my guess is that IBM won't approve the
resources for such a vast change, and I'm not seeing people rushing to
help implement this approach who are well acquainted with the couch
codebase.

Paul, consider this a vote of support in favour of your proposal, subject
to the concerns already raised. What does Bob have to say?

-Joan

Re: [NEWS] request

[Joan Touzet]

Agree that this should be a news@ mailing list, and is a superset of
all posts that go to announce@ - all announcements also hit news, but
weekly news posts don't go to announce@.

FYI the Apache standard is to use plain text emails. I personally will
ignore all HTML formatted emails.

https://www.apache.org/foundation/mailinglists.html

-Joan

- Original Message -
> From: "Nick North" 
> To: marketing@couchdb.apache.org, fiat...@gmail.com
> Sent: Thursday, May 21, 2015 9:23:36 AM
> Subject: Re: [NEWS] request
> 
> How about calling the list n...@couchdb.apache.org? More descriptive
> and
> allows change of frequency if it ever becomes desirable.
> 
> Nick
> 
> On Thu, 21 May 2015 at 13:47 Jan Lehnardt  wrote:
> 
> > We could also set up a new mailing list wee...@couchdb.apache.org
> > and
> > people
> > can subscribe to that and we post the weekly there.
> >
> >
> > > On 21 May 2015, at 14:23, Giovanni P  wrote:
> > >
> > > What if they used, by themselves, some of these services:
> > > https://www.google.com.br/search?q=rss+to+mail?​
> > >
> > > On Thu, May 21, 2015 at 8:49 AM, Ingo Radatz
> > > 
> > > wrote:
> > >
> > >> I can confirm that it is a request from many people. I had a
> > >> chat with
> > >> Lena about it at the CouchDB day in Hamburg and have documented
> > >> it in
> > the
> > >> Advocate Hub Forum.
> > >>
> > >> A possible solution is to use a RSS feed or your mailing list
> > announcement
> > >> mail as trigger to send an email to all subscribers via Mailgun
> > >> or
> > Sendgrid
> > >> or Mailchimp (sending emails is easy but managing a subscriber
> > >> list is
> > what
> > >> they can provide to us).
> > >>
> > >> Ingo
> > >>
> > >>> On 21 May 2015, at 13:20, Katharina Jockenhöfer <
> > ka...@thehoodiefirm.com>
> > >> wrote:
> > >>>
> > >>> Hi!
> > >>>
> > >>> We've had a request on Facebook - someone is asking to get the
> > >>> Weekly
> > >> News via email.
> > >>>
> > >>
> > https://www.facebook.com/permalink.php?story_fbid=651970961501798&id=507603582605204&comment_id=651979058167655¬if_t=share_comment
> > >> <
> > >>
> > https://www.facebook.com/permalink.php?story_fbid=651970961501798&id=507603582605204&comment_id=651979058167655¬if_t=share_comment
> > >>>
> > >>> Should I forward him to the mailing list? Was there ever a
> > >> discussion/need to make the news subscribable via email?
> > >>>
> > >>> Best
> > >>> Katharina
> > >>
> > >>
> >
> > --
> > Professional Support for Apache CouchDB:
> > http://www.neighbourhood.ie/couchdb-support/
> >
> >
> 

Re: Two names: CouchDB & Couch App Server

[Joan Touzet]

I'll take this one:

- Original Message -
> From: "Javier Candeira" 

> c) If I understand correctly, there would be still only one product:
> CouchDB 2.0 which stores and serves your data, replicates, clusters,
> shards
> it *and* it also serves couchapps. The separation between CouchDB and
> CouchAppServer would only be in the documentation/marketing, not in
> the
> software shipped. Correct?

Not in the software. Maybe in the .ini file(s). Certainly in the
deployment (likely to be single-node, not clustered.)

-Joan

Re: the future of couchapp

[Joan Touzet]

One additional data point here. I mention "serious customers" as
narrowly defined in this email as the thousands-to-millions of $
customers. CouchApps probably have a place in the lower end of the
market, i.e. shared instance users who have lightweight needs for
their applications and are customers of IrisCouch or SmileApps. I
wasn't trying to say there isn't a market for this :) The business
case to be made for them is very different, i.e. razor thin margins
across thousands to millions of people. Such an approach wasn't
logical for Cloudant - the shared instances don't drive the company
like the dedicated instances do. Because of this data I think
CouchApps as a primary user story is very hard road to walk for us.

- Original Message -
> From: "Joan Touzet" 
> To: marketing@couchdb.apache.org
> Cc: "Mike Broberg" , smet...@uk.ibm.com
> Sent: Saturday, May 9, 2015 2:26:26 PM
> Subject: Re: the future of couchapp
> 
> Hi Miles,
> 
> DISCLAIMER: I am not speaking as an official representative of IBM or
> Cloudant. I have cc'ed Mike Broberg, who can speak for them if
> necessary. (I also want him to be aware of what I am saying here).
> 
> *** TL;DR: the people who are willing to spend anywhere from
> thousands to millions of dollars on a CouchDB-based solution aren't
> interested in CouchApps. I think the discussion to date is missing
> this, and as such, is entirely unrepresentative of the current
> market for Apache CouchDB.
> 
> The answer is that there are practically no customers of Cloudant/IBM
> who are banking on CouchApps for any serious need. Every client that
> I can think of - meaning they have a dedicated cluster, and aren't
> using the shared cluster service - are using either a traditional
> three-tier app server structure (Node.JS, Python, PHP, Ruby, Java,
> .NET, etc.) or are doing client-side development on mobile platforms
> (iOS + TouchDB, Android + PouchDB) where they are replicating back to
> the Cloudant clusters for data exchange. In all of these scenarios,
> replication is the "killer feature" for CouchDB, with the REST
> interface a close second, and the ease of unstructured JSON data as
> a third.
> 
> Cloudant built out a document-level (and field-level!) security
> solution for one customer, about two years ago now. While there was
> initial interest, performance considerations lead to the solution
> being backburnered for further consideration. Even in that situation,
> CouchApps weren't the primary concern -- database-level enforcement
> of security rules *was*.
> 
> Within Cloudant, perhaps Simon Metson was the primary proponent of
> using CouchApps for serious purposes. He used them in the "For
> Developers" section of the website to help demonstrate various key
> features of the platform, including the new MongoDB-inspired Mango
> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
> picked up on this and built a documentation framework on top of
> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
> unsecured content, read-only, displayed in different formats based
> upon what the end user needs, and self-hosted by CouchDB (so you
> can view the product's documentation using the product itself).
> More information on this use is at:
> 
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
> 
> 
> 
> 
> 
> - Original Message -
> > From: "Miles Fidelman" 
> > To: marketing@couchdb.apache.org
> > Sent: Friday, May 8, 2015 11:21:28 AM
> > Subject: Re: the future of couchapp
> > 
> > Let's be clear.
> > (Good) marketing isn't about selling a solution to folks who don't
> > have
> > a problem in the first place, it's about it's identifying problems
> > for
> > which we offer a solution.
> > 
> > And.. it occurs to me that Cloudant has been doing market research
> > and
> > "real" marketing - perhaps some folks from Cloudant might share
> > some
> > findings related to CouchDB (as opposed to those that might relate
> > to
> > their commercial extensions and services)?
> > 
> > Miles Fidelman
> > 
> > 
> > 
> > Giovanni Lenzi wrote:
> > >> translates user@ decisions in "how to drive them to the public"?
> > > or maybe better how to drive dev@ implemented features to the
> > > public ?
> > >
> > > 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi
> > > :
> > >
> > >> Got it, Joan. Thanks for the useful reminder, consi

On Marketing and Development working together! :)

[Joan Touzet]

I wanted to clarify my reply to Johs for this mailing list, as regards
the role of this mailing list. For this post, I have my Apache CouchDB
PMC hat on.

At the moment, few if any active developers for CouchDB are also on this
list. (I think Jan, Robert K. and myself are the only ones.) That means
that the current discussion about CouchApps is somewhat of an echo
chamber. We could, as a group, come up with the most amazing plan of
what *we* think would be the best things to implement next, but without
working *WITH* the development organization to help prioritize them
in light of ongoing work, the effort is wasted.

I will not let marketing@ become an echo chamber ungrounded in the
realities of open source software development.

Further, I don't want to see us building some sort of adversarial
relationship between CouchDB marketers and CouchDB developers. Despite
allegations to the contrary, there is *no* secret cabal trying to kill
CouchApps. Jan's original proposal was *NEVER* about removing the
functionality for shows, lists, or direct HTTP access to attached .html,
.css, .js or other resources. It was about the fact that, within the
world of people using CouchDB for serious tasks, those functions are
secondary, even tertiary to CouchDB's data store, replication, and
REST/JSON interface. We should be working to tighten that message up
into a single sentence that isn't full of jargon, something that attracts
people to the database. Again, no dev is going to kill off CouchApps as
a feature.

Finally: the official description of this mailing list is:

"Marketing List   Subscribe · Post · Unsubscribe
A place to co-ordinate on CouchDB marketing activities"

Please keep that in mind. It is not a place to coordinate future
functionality or to drive the development group in a specific direction.
I agree that any development organization that ignores their user base,
both potential and current, is in peril. It is within the mission of
this group to help find out what users of CouchDB need, as well as to
get the message out as to what CouchDB is capable of doing. But the
primary function is to help get the word out about what we do, not what
we might do.

Thanks for your time.
Joan