Re: [ANNOUNCE] Nick Vatamaniuc joins the PMC

[Robert Kowalski]

Welcome Nick, congrats!

On Mon, Nov 13, 2017 at 1:24 PM, Andy Wenk  wrote:
> Hey Nick - welcome on bord ;-)
>
> All the best
>
> Andy
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> GPG public key:
> http://pgp.mit.edu/pks/lookup?op=get=0x45D3565377F93D29
>
>
>
>> On 13. Nov 2017, at 08:22, Garren Smith  wrote:
>>
>> Welcome Nick. This is awesome.
>>
>> On Mon, Nov 13, 2017 at 7:30 AM, Nick Vatamaniuc  wrote:
>>
>>> Thanks everyone for the warm welcome. It's an honor to be a member of the
>>> Apache CouchDB PMC.
>>>
>>> On Sun, Nov 12, 2017 at 8:29 AM, Robert Samuel Newson 
>>> wrote:
>>>
 Congratulations Nick, well deserved, and welcome aboard!

 B.

> On 12 Nov 2017, at 03:39, Paul Davis 
 wrote:
>
> Hooray and welcome, Nick!
>
>
> On Sat, Nov 11, 2017 at 2:45 PM Joan Touzet  wrote:
>
>> Congratulations! Welcome, Nick!
>>
>> - Original Message -
>> From: "Alexander Shorin" 
>> To: priv...@couchdb.apache.org
>> Sent: Saturday, 11 November, 2017 1:31:36 PM
>> Subject: Re: [ANNOUNCE] Nick Vatamaniuc joins the PMC
>>
>> Hooray to Nick! And welcome!
>> --
>> ,,,^..^,,,
>>
>>
>> On Sat, Nov 11, 2017 at 4:40 PM, Jan Lehnardt  wrote:
>>> Forgot to CC private@
>>>
 Begin forwarded message:

 From: Jan Lehnardt 
 Subject: [ANNOUNCE] Nick Vatamaniuc joins the PMC
 Date: 11. November 2017 at 17:38:39 GMT+1
 To: dev 
 Reply-To: dev@couchdb.apache.org

 Dear community,

 I am delighted to announce that Nick Vatamaniuc joins the Apache
>> CouchDB Project Management Committee today.

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

 On behalf of the CouchDB PMC,
 Jan
 —

>>>
>>


>>>
>

Re: [PROPOSAL] Drop PDF / texinfo documentation builds

[Robert Kowalski]

good idea, +1

On Sat, Mar 18, 2017 at 9:14 AM, Jan Lehnardt  wrote:

> +1
>
> Cheers
> Jan
> --
>
> > On 18 Mar 2017, at 05:55, Joan Touzet  wrote:
> >
> > Hi everyone,
> >
> > I'd like to propose dropping the PDF and texinfo targets from our
> > documentation build, or at the very least, having them not be part of
> > the default target / not standard deliverables for the project.
> >
> > We'd continue to build HTML documentation as part of the workflow,
> > naturally, as well as the man pages.
> >
> > I don't have any solid numbers, but I'm fairly sure most people use
> > https://docs.couchdb.org/ or a locally installed copy for their
> > documentation for CouchDB rather than the PDF documentation. I
> > personally can't remember the last time I opened the docs in PDF form. I
> > also have never seen anyone refer to the PDF docs on the mailing lists,
> > IRC or Slack when asking for advice or support.
> >
> > I've also never seen anyone use or talk about the texinfo target, and
> > I've not used them myself.
> >
> > Dropping this dependency will allow us to drop TeX/LaTeX from our build
> > chain, which speeds up build times by about 90 seconds and reduces the
> > size of containers currently being built for our Jenkins CI workflow.
> > It also means CouchDB devs don't have to install 0.5-1.5GB worth of
> > toolset.
> >
> > I've captured this in JIRA as
> > https://issues.apache.org/jira/browse/COUCHDB-3329 and have PRs ready
> > to fire off if people agree.
> >
> > Your thoughts?
> >
> > -Joan
>

Re: Benchmarking CouchDB Views

[Robert Kowalski]

Nice, thank you Alex!

On Fri, Mar 17, 2017 at 10:25 AM, Alexander Shorin  wrote:

> FYI:
> https://medium.com/@excieve/benchmarking-couchdb-views-
> abb7a0a891b2#.y8os5bk3v
>
> --
> ,,,^..^,,,
>

[ANNOUNCE] Michael Hall elected as CouchDB committer

[Robert Kowalski]

Dear community,

I am pleased to announce that the CouchDB Project Management Committee
has elected Michael Hall as a CouchDB committer.

Apache ID: mhall119

IRC nick: mhall119

Twitter: @mhall119

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 Michael'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 Michael!

On behalf of the CouchDB PMC,
Robert :)

[PLANNING] CouchDB 2.1

[Robert Kowalski]

Hi,

I wanted to test the waters regarding a CouchDB 2.1 release. Since 2.0
a few new features and many bug fixes have landed.

I know its holiday season soon and I wanted to kick off the discussion
about a release date for 2.0.1 or 2.1.0.

One thing that worries me (correct me if I am wrong): I think
releasing CouchDB depends much on Joan and Jan right now, which is bad
(bus factor etc).

I don't know much about the internals of the build process for our
releases, but I would volunteer to automate the (jenkins?-)build for
snaps.

Best,
Robert

Re: Publisher account for CouchDB snap

[Robert Kowalski]

Everything set up, I think we have to figure out when the next release happens.

On Fri, Dec 16, 2016 at 2:04 PM, Robert Kowalski <r...@kowalski.gd> wrote:
> Hi Micheal,
>
> thank you so much! You are doing awesome work!
>
> I registered an account: https://cldup.com/1cbKxu0igy.png
>
> Let's chat on IRC regarding the next steps, I don't know how to use
> snap on my Mac.
>
> Best,
> Robert
>
>
> On Fri, Dec 16, 2016 at 3:04 AM, Michael Hall <mhall...@gmail.com> wrote:
>> Over the past few months, with help from rnewsom, jan and others, we've
>> been able to create a Snap[1] package for CouchDB 2.x that I would like
>> to make available through the Snap Store.
>>
>> The Snap Store encourages upstreams to publish their packages
>> themselves, rather than depending on distro developers to do so.
>> Registering a package in the store is currently limited to individual
>> accounts, there's no support yet for teams, which means that someone
>> would need to register "apache-couchdb" as a developer account in the
>> store. They can then share upload rights for the couchdb snap with other
>> individuals, but it needs to be owned by someone to start with.
>>
>> On IRC there was some discussion about how to approach this, with the
>> suggestion that someone on the PMC could register the owning account,
>> using the ASF mailing address[2] and their own email. This should
>> require very little work to setup, and almost no work after the initial
>> setup. So I'm asking if anyone on the PMC would be willing to take this
>> up and help us get the snap package published to users.
>>
>> [1] http://snapcraft.io
>> [2] yes it's asked for, and I agree it shouldn't be needed
>>
>> --
>> Michael Hall
>> mhall...@gmail.com

Re: Publisher account for CouchDB snap

[Robert Kowalski]

Hi Micheal,

thank you so much! You are doing awesome work!

I registered an account: https://cldup.com/1cbKxu0igy.png

Let's chat on IRC regarding the next steps, I don't know how to use
snap on my Mac.

Best,
Robert


On Fri, Dec 16, 2016 at 3:04 AM, Michael Hall  wrote:
> Over the past few months, with help from rnewsom, jan and others, we've
> been able to create a Snap[1] package for CouchDB 2.x that I would like
> to make available through the Snap Store.
>
> The Snap Store encourages upstreams to publish their packages
> themselves, rather than depending on distro developers to do so.
> Registering a package in the store is currently limited to individual
> accounts, there's no support yet for teams, which means that someone
> would need to register "apache-couchdb" as a developer account in the
> store. They can then share upload rights for the couchdb snap with other
> individuals, but it needs to be owned by someone to start with.
>
> On IRC there was some discussion about how to approach this, with the
> suggestion that someone on the PMC could register the owning account,
> using the ASF mailing address[2] and their own email. This should
> require very little work to setup, and almost no work after the initial
> setup. So I'm asking if anyone on the PMC would be willing to take this
> up and help us get the snap package published to users.
>
> [1] http://snapcraft.io
> [2] yes it's asked for, and I agree it shouldn't be needed
>
> --
> Michael Hall
> mhall...@gmail.com

Re: Fauxton does not URLencode its links

[Robert Kowalski]

Hi Garth,

I think it is already fixed on master:
https://github.com/apache/couchdb-fauxton/commit/1aa4ca6f34a718c294a06a1301f39fe05f157a1c


On Wed, Nov 30, 2016 at 10:25 PM, Garth Gutenberg
 wrote:
> Hey folks.  Fauxton is not URL encoding any of its navigation links in
> Couch 2.0.  It's a pretty major issue for us as all of our databases use
> slashes in their names, which makes navigating around Fauxton unbearable.
>
> I created a ticket for it here https://issues.apache.
> org/jira/browse/COUCHDB-3229 .
>
> Can someone please take a look at this issue?

Re: [ANNOUNCE] Benjamin Anderson elected as CouchDB committer

[Robert Kowalski]

Welcome, Mr Anderson. :D

On Tue, Nov 1, 2016 at 9:18 PM, Kyle Snavely  wrote:
> Three cheers for Ben!
>
> On Tue, Nov 1, 2016 at 3:58 PM, Joan Touzet  wrote:
>
>> Welcome, Ben! Glad to have you officially in the team.
>>
>> -Joan
>>
>> - Original Message -
>> > From: "Robert Samuel Newson" 
>> > To: dev@couchdb.apache.org
>> > Sent: Tuesday, November 1, 2016 3:46:36 PM
>> > Subject: [ANNOUNCE] Benjamin Anderson elected as CouchDB committer
>> >
>> > Dear community,
>> >
>> > I am pleased to announce that the CouchDB Project Management
>> > Committee has elected Benjamin Anderson as a CouchDB committer.
>> >
>> > Apache ID: banjiewen
>> >
>> > IRC nick: banjiewen
>> >
>> > Twitter: banjiewen
>> >
>> > 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 Ben'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 Ben!
>> >
>> > On behalf of the CouchDB PMC,
>> >
>> > Robert Samuel Newson
>> >
>> >
>>

Re: CouchDB 2.0 as Snap

[Robert Kowalski]

wow thats super cool!

thank you!

On Mon, Sep 19, 2016 at 11:47 PM, Michael Hall  wrote:

> Thanks to help from Jan and Wohali on IRC, I was able to manually build
> couchdb from the 2.0.x branch, and then snap-package the resulting
> binary. I have attached the snapcraft.yaml used for this. Put this file
> in a directory with the couchdb directory built in ./rel/, then run
> "snapcraft snap" to build couchdb_2.0_amd64.snap
>
> The snap package will create a systemd service file for running couchdb
> as a daemon, but due to the way it launches a background epmd process
> this isn't working right (systemd thinks it failed to start and keeps
> trying to restart it until it givesup). Because of that, I've also
> included a /snap/bin/couchdb.run which will manually kick it off, but
> this should only be temporary until the daemon process can be fixed.
>
> One last caveat, you'll need to copy /snap/couchdb/current/etc/*.ini
> into /var/snap/couchdb/current/ and mkdir /var/snap/couchdb/current/data
> before running it. This could be done at runtime either by couchdb
> itself, or with a custom wrapper script for the snap command.
>
> Michael Hall
> mhall...@gmail.com
>
> On 09/19/2016 01:19 PM, Jan Lehnardt wrote:
> >
> >> On 19 Sep 2016, at 19:13, Michael Hall  wrote:
> >>
> >> Maybe I'm using the wrong branch, because the Makefile has an "install"
> >> target but not a "release" target. I'm using developer-preview-2.0, if
> >> that's not the correct one, which should I use?
> >
> > Please use the `2.0.x` branch.
> >
> > Best
> > Jan
> > --
> >
> >>
> >> Michael Hall
> >> mhall...@gmail.com
> >>
> >> On 09/19/2016 12:10 PM, Jan Lehnardt wrote:
> >>> Heya, nice effort here :)
> >>>
> >>> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only
> >>> insofar as it is useful for CouchDB and not for tools that expect
> >>> autotools-like behaviour.
> >>>
> >>> Over time, we want to make it so that the CouchDB install procedure
> >>> fits right into normal tooling, but we are not there yet.
> >>>
> >>> Especially, `make install` is not available in 2.0. Instead, we
> >>> have `make release` which produces a location independent directory
> >>> `./rel/couchdb` that you can move into your system where you need it.
> >>>
> >>> There is no way to externalise log files or so from a setup perspective
> >>> (although it can be configured in local.ini).
> >>>
> >>> HTH
> >>>
> >>> Best
> >>> Jan
> >>> --
> >>>
>  On 19 Sep 2016, at 17:48, Michael Hall  wrote:
> 
>  I have attached the snapcraft.yaml file I've started. This is used by
>  the snapcraft tool to build and package a .snap file (just run
>  `snapcraft snap` in the same directory as this file).
> 
>  You can see that most of it is dedicated to grabbing the source,
>  specifying build dependencies (build-packages) and runtime
> dependencies
>  (stage-packages). The 'autotools' plugin will run the standard
>  "./configure; make; make install" steps on the source, and while the
>  output of those claims to be successful, make returns with a non-zero
>  status code ($?=2) which causes snapcraft to abort after building.
> 
>  As mentioned previously, this could be significantly simplified if it
>  could use the build processes already in place. In that case the
>  snapcraft.yaml would only need to be pointed to the local directory
>  containing the binary files needed to include in the .snap package. If
>  somebody wants to give that a try, I can put together a new
>  snapcraft.yaml that will do that.
> 
> 
>  Michael Hall
>  mhall...@gmail.com
> 
>  On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
> > It would be nice to have two snap packages:
> > - CouchDB 2.0 UN-CLUSTERED
> > - CouchDB 2.0 CLUSTERED VERSION
> >
> > That will encourage a lot of "standalone" CouchDB users to upgrade
> to a 2.0
> > version without the clustering overload stuff, and thus make a big
> pool of
> > 2.0 testers and bug-reporters!
> > Teo
> >
> >
> > On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall 
> wrote:
> >
> >> First off, congratulations on the upcoming 2.0 release!
> >>
> >> I would love to see this new version available as a Snap package for
> >> users of Ubuntu 16.04 LTS, since the archive version will be frozen
> on
> >> 1.6.0 for the next 5 years of it's lifecycle.
> >>
> >> Snaps are self-contained packages that include all of the
> dependencies
> >> they need, which lets them run as you (the upstream) intended
> across new
> >> releases of Ubuntu, Debian, Arch, and many other distros. They run
> in a
> >> sandbox that protects them from changes made to the user's system,
> but
> >> with a number of optional interfaces if you need deeper interaction
> or
> >> to share data with other apps.
> 

Rebar 3

[Robert Kowalski]

Hey,

I would like to make it possible to write Elixir for CouchDB extensions.

Right now we are using rebar 2 to compile our Erlang and C code. There
is a plugin for rebar to compile Elixir:
https://github.com/yrashk/rebar_elixir_plugin which is not maintained
any more. I have compiled Elixir for CouchDB, but it is an aweful hack
as the plugin was written for Elixir 0.9

This is the main reason why I would like to switch CouchDB to rebar 3.

rebar 3 seems to be the way to build / manage Erlang deps right now
and if nothing speaks against it, I just continue to work on the
topic.


Best,
Robert

Re: Fauxton Viz Guide 2.0

[Robert Kowalski]

wow thats amazing! good work!

On Mon, Sep 12, 2016 at 12:13 AM, Michelle Phung 
wrote:

> Hey Andrea,
>
> Just wanted to let you know that I am nearly finished with the Fauxton
> Visual Guide that you designed from a few months ago, and also thank you
> for doing such an amazing job!
>
> You can see a preview here:
> https://michellephung.github.io/fauxton-viz-guide-2
>
> I am probably going to open the PR to get it to replace the old one at
> http://couchdb.apache.org/fauxton-visual-guide/index.html in a few days.
>
> There are a few things I still have to fix up, and some content I need to
> get information about, so that I can put it in there.
>
> Anyways, I hope you like it, and thank you for making it so cool!
>
> -Michelle
>

Re: Fauxton, Docker and Selenium

[Robert Kowalski]

awesome, thank you! we should put it into the news!

On Wed, Jul 20, 2016 at 8:57 AM, Garren Smith  wrote:
> Hi All,
>
> I wrote an article on how and why we using Docker and Selenium to test
> Fauxton. It possible could we add it to this weeks CouchDB newsletter
>
> https://medium.com/@garrensmith/consistent-selenium-testing-with-docker-f2d5a24a1bc5
>
> Cheers
> Garren

[DISCUSSION] Limiting the allowed size for documents

[Robert Kowalski]

Hello list,

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.

In any case you can't or should not try to submit a similar sized
document, because you hit a limit. The user can't do what they want
(put a big JSON into Couch) and additionally a lot of work is created
to fix the issue.

I was wondering if we can tackle the root cause instead? This would
help to maintain CouchDB in production systems.

I don't want to push this into 2.0. I want to spark a discussion how
we can get rid of small day-to-day operation issues. The goal is to
make CouchDB easier to run and provide a more pleasant experience for
everyone.

Some limits from other databases:

Postgres: 1GB -
https://www.postgresql.org/docs/current/static/datatype-character.html
Dynamo: 400 KB -
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#limits-data-types
Mongo BSON Doc: 16 megabytes - https://docs.mongodb.com/manual/reference/limits/
Couchbase: 20 MB -
http://developer.couchbase.com/documentation/server/current/clustersetup/server-setup.html

Re: [ANNOUNCE] Nolan Lawson elected as CouchDB committer

[Robert Kowalski]

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: Closing in on 2.0

[Robert Kowalski]

I have a bug we are recently running into.

Our CI system for Fauxton uses fresh builds of 2.0. We _sometimes_ get
a 503 error from Couch when we try to create our test database. We
boot Couch and wait 30 seconds, raising to 120 seconds did not help.

Example build: https://travis-ci.org/robertkowalski/couchdb-fauxton#L4039

It looks like the 503 comes from:
https://github.com/apache/couchdb-chttpd/blob/be1e959504ac7b0332110a9918365ff20937bc43/src/chttpd.erl#L863

The 503 error stays for the whole 30min our testsuite runs, so giving
it more time after boot probably also wouldn't help.

Our setup for travis is quite standard, we get the Couch master, build
it, and run ./dev/run, see
https://github.com/apache/couchdb-fauxton/blob/master/.travis.yml

On Tue, Apr 19, 2016 at 9:54 AM, Michael Fair  wrote:
>> blockers, not new work. And, yes, I still believe you are proposing
>> something major, with ramifications that require real thought.
>>
>
>
> Thanks guys :)
>
> Mike

2.0 testing

[Robert Kowalski]

Hi there,

Ben found a pretty interesting bug in 2.0 and I can comfirm the bug.

If you POST a doc into the replicator database a replication is kicked
off and finishes successfully (usual 5984 port which maps to 15984 via
haproxy).

The problem is that the DB is replicated to the backdoor ports (15986)
and is not visible on the other ports.

I opened a Jira ticket to track the issue:
https://issues.apache.org/jira/browse/COUCHDB-2980

Best,
Robert :)

Re: db/_all_conflicts

[Robert Kowalski]

want to make sure make the right trade-offs on the storage/indexing 
> level, and, while not making everyone pay for the overhead, make it really 
> easy to opt into this feature. (Unless we all agree that the performance hit 
> for 2. is worth it :)
>
>
> Best
> Jan
> --
>
>
>
>
>>
>>
>> On 14 March 2016 at 14:07, Sebastian Rothbucher <
>> sebastianrothbuc...@googlemail.com> wrote:
>>
>>> Hi Robert,
>>>
>>> this looks awesome already! I don't want to be the spoiler in this, but
>>> wouldn't conflicts occur recently, e.g. using _changes (descending) might
>>> do the trick of limit-ing? (Still you'd discard docs that simply don't have
>>> conflicts, but probably way not that many)
>>>
>>> If that doesn't do the trick: just forget what I just said ;-)
>>>
>>> Best
>>>Sebastian
>>>
>>> On Mon, Mar 14, 2016 at 2:58 PM, Robert Kowalski <r...@kowalski.gd> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> it is hackweek for the Fauxton team and I am lucky enough to be able
>>>> to work on whatever I want :)
>>>>
>>>> Conflicts are an integral part of CouchDB. Right now I dream of making
>>>> conflict-resolution a first class citizen in Couch. Conflict
>>>> resolution requires a lot of manual steps. The idea is to give the
>>>> user all the tools they need to easily solve conflicts, and also to
>>>> help them to avoid conflicts in the future.
>>>>
>>>> To empower every user to detect and solve conflicts easily on their
>>>> own, instead of writing some custom bash/js scripts and custom view
>>>> hackery I would like to have a list of conflicts in Fauxton for every
>>>> database.
>>>>
>>>> The list, provided by Couch, shows which documents have conflicts. I
>>>> can then click on the conflicting doc and get a nice diffing editor
>>>> which helps me to solve the conflict. Here's an early draft: [1]
>>>>
>>>> Discussing the matter in couchdb-dev we thought about serverside
>>>> filtering of _all_docs - which is a problem for large databases.
>>>>
>>>> Another option is a new endpoint, e.g. /db/_all_conflicts. Behind this
>>>> endpoint is an index which is listing the conflicting documents.
>>>>
>>>> Jan and Alex suggested the index could be opt-in. They suggested an
>>>> "auto-warmer" - it would update the index every 1000 doc updates or
>>>> so. This way not every doc write would get slower. In later iteration
>>>> we could even expose the "auto-warming" feature to other views.
>>>>
>>>> Do you want to join me on my quest to provide the best conflict
>>>> resolution tools and education?
>>>> What do you think about it?
>>>>
>>>> Best,
>>>> Robert :)
>>>>
>>>> [1]
>>>>
>>> https://cloud.githubusercontent.com/assets/298166/13741539/c4ecf6d0-e9ce-11e5-84c5-502b0989c290.png
>>>>
>>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>

db/_all_conflicts

[Robert Kowalski]

Hi folks,

it is hackweek for the Fauxton team and I am lucky enough to be able
to work on whatever I want :)

Conflicts are an integral part of CouchDB. Right now I dream of making
conflict-resolution a first class citizen in Couch. Conflict
resolution requires a lot of manual steps. The idea is to give the
user all the tools they need to easily solve conflicts, and also to
help them to avoid conflicts in the future.

To empower every user to detect and solve conflicts easily on their
own, instead of writing some custom bash/js scripts and custom view
hackery I would like to have a list of conflicts in Fauxton for every
database.

The list, provided by Couch, shows which documents have conflicts. I
can then click on the conflicting doc and get a nice diffing editor
which helps me to solve the conflict. Here's an early draft: [1]

Discussing the matter in couchdb-dev we thought about serverside
filtering of _all_docs - which is a problem for large databases.

Another option is a new endpoint, e.g. /db/_all_conflicts. Behind this
endpoint is an index which is listing the conflicting documents.

Jan and Alex suggested the index could be opt-in. They suggested an
"auto-warmer" - it would update the index every 1000 doc updates or
so. This way not every doc write would get slower. In later iteration
we could even expose the "auto-warming" feature to other views.

Do you want to join me on my quest to provide the best conflict
resolution tools and education?
What do you think about it?

Best,
Robert :)

[1] 
https://cloud.githubusercontent.com/assets/298166/13741539/c4ecf6d0-e9ce-11e5-84c5-502b0989c290.png

Re: [POC] Mango Catch All Selector

[Robert Kowalski]

the new behaviour for mango landed this week on master, i hope you all enjoy it!

please report any bugs, problems, feedback and also praise :)

On Mon, Jan 18, 2016 at 11:59 AM, Jan Lehnardt <j...@apache.org> wrote:
> This is awesome: +1
>
>
>> On 18 Jan 2016, at 00:16, Robert Kowalski <r...@kowalski.gd> wrote:
>>
>> Heya,
>>
>> thanks again for all the feedback! I built a prototype and added a demo 
>> video!
>>
>>> 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/.”}]
>>
>> I really like this idea! I thought long about it and I think it grows
>> the scope of the current task. Right now all strings CouchDB returns
>> to the user are written in English. The current message that no index
>> exists is also in english. Sadly our documentation is not
>> internationalised yet - afaik no language has a complete translation
>> and the translations are not available as a website or in any other
>> public form. I stopped translating to German myself as the promised
>> integration into the doc build was never finished in ~1.5 years. For
>> the specific task right now I would like to keep the scope as small as
>> possible. This does not mean that I would stand in the way if folks
>> want to add i18n to the project and its sub-projects and have the
>> tooling and time to maintain it.
>>
>>
>> Because a prototype speaks more than 1000 posts I hacked a prototype
>> which includes the warning that was proposed by Garren. You can check
>> it out at https://github.com/apache/couchdb-mango/pull/27 - or watch
>> the video: https://cloudup.com/cEnbWqbX5Y7
>>
>> What do you think?
>>
>> On Wed, Jan 13, 2016 at 11:58 PM, Jan Lehnardt <j...@apache.org> wrote:
>>>
>>>> On 13 Jan 2016, at 23:41, Joan Touzet <woh...@apache.org> wrote:
>>>>
>>>> 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/.”}]
>>>
>>> bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
>>> something like this!
>>>
>>> Great discussion everyone. I like how we are all making this idea better 
>>> together :)
>>>
>>> Best
>>> Jan
>>> --
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> - Original Message -
>>>> From: "Robert Kowalski" <r...@kowalski.gd>
>>>> 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 

What Have We Learned From This Open Source Project?

[Robert Kowalski]

a lot of truth here for OSS maintainers and worth a read, as we maintain OSS:

http://taskwarrior.org/docs/advice.html

enjoy!

Best,
Robert :)

http://theclibook.com

Re: [ANNOUNCE] Ilya Khlopotov elected as CouchDB committer

[Robert Kowalski]

yay! welcome! :)

On Sun, Feb 7, 2016 at 3:43 PM, Klaus Trainer  wrote:
> Welcome Ilya :)
>
> Best,
> Klaus
>
>
> On 02/06/2016 12:15 AM, Alexander Shorin wrote:
>> Dear community,
>>
>> I am pleased to announce that the CouchDB Project Management Committee
>> has elected Ilya Khlopotov as a CouchDB committer.
>>
>> Apache ID: iilyak
>>
>> IRC nick: iilyak
>>
>> Twitter: N/A
>>
>> 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 Ilya'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 Ilya!
>>
>> On behalf of the CouchDB PMC,
>> Alexander Shorin
>>
>> --
>> ,,,^..^,,,
>>

Re: RailsGirls Summer of Code

[Robert Kowalski]

> We're stable community (;

cool that you want to volunteer as we are such a stable community. :))

On Mon, Jan 25, 2016 at 1:16 AM, Alexander Shorin <kxe...@gmail.com> wrote:
> On Mon, Jan 25, 2016 at 3:10 AM, Robert Kowalski <r...@kowalski.gd> wrote:
>> is there anyone for couchdb core available? it would be cool to join
>> forces on one topic that requires changes in fauxton and the core.
>
> Wouldn't regular workflow be enough for such kind cooperation: ask
> question on dev@ ML / #couchdb-dev -> get the answer?  Or you assume
> something different that involves to be on the hot line for some hours
> at some time?
>
>> i'm a bit sad to see just the same faces every year volunteering, do
>> you have an idea how to make things better and to motivate folks?
>
> We're stable community (;
>
> --
> ,,,^..^,,,

Re: RailsGirls Summer of Code

[Robert Kowalski]

hey jan,

i'm up for fauxton!

is there anyone for couchdb core available? it would be cool to join
forces on one topic that requires changes in fauxton and the core.

i'm a bit sad to see just the same faces every year volunteering, do
you have an idea how to make things better and to motivate folks?

On Thu, Jan 21, 2016 at 8:41 AM, Andy Wenk  wrote:
> Hey Jan,
>
> this is a great idea and it would be awesome, if someone would be up for
> coaching. I personally have no slot unfortunately to do so.
>
> All the best
>
> Andy
>
> On 20 January 2016 at 18:00, Jan Lehnardt  wrote:
>
>> Hey all,
>>
>> The RailsGirls Summer of code happens again this year and applications for
>> projects close in eleven days.
>>
>> RGSoC is like Google Summer of Code, except that for a focus on students,
>> they focus on getting women* in technology.
>>
>> We’ve participated with Hoodie last year and it was a great success. Each
>> project gets at most one team, so coaching overhead is a lot less as with
>> GSoC.
>>
>> In addition, RGSoC teams come with their own support group and external
>> coaches, so it is a lot more likely that something comes of the project.
>>
>> And I bet we could apply separately for CouchDB and Fauxton, since they
>> are vastly different projects.
>>
>> If you need more convincing: over the past four years, 90% of RGSoC
>> applicants have found a steady job in IT, many of them switching careers.
>> I’ve witnessed a number of these transitions and they are one of the
>> prouder moments in my open source life.
>>
>> Before you ask, despite the name, RGSoC is open for all open source
>> projects, regardless of the programming language.
>>
>> Here’s the application procedure:
>> http://railsgirlssummerofcode.org/guide/projects/
>>
>> Should CouchDB participate? Who’d be up for coaching?
>>
>> Best
>> Jan
>> --
>> * http://railsgirlssummerofcode.org/students/application/#eligibility
>>
>>
>
>
> --
> 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: Documentation for CI

[Robert Kowalski]

Hi Bastian,

you can also just send them as PR to
https://github.com/apache/couchdb-documentation

I would prefer the official docs as single point of truth in the
long-term, right now we have at least 4 sources (official docs,
repository readmes, old-wiki, new-wiki) as possible sources and many
sources are outdated. It's even worse: some are updated, some not,
which makes it hard to decide which are still relevant and which not.

On Sun, Jan 24, 2016 at 12:26 PM, Bastian Krol
 wrote:
> Hi folks,
>
> I'd like to put up some documentation around the CI efforts somewhere. Would
> the Confluence wiki be a good place for this? Or would you like to see this
> somewhere else?
>
> If Confluence is the right spot, it would be nice if one of you could grant
> me write access (user name bastiankrol).
>
> Suggestions where to put this in the page hierarchy in Confluence are also
> welcome - most of the sections seem to be more targeted at users, not so
> much at developers?
>
> Cheers
>
>   Bastian

Re: [POC] Mango Catch All Selector

[Robert Kowalski]

Heya,

thanks again for all the feedback! I built a prototype and added a demo video!

> 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/.”}]

I really like this idea! I thought long about it and I think it grows
the scope of the current task. Right now all strings CouchDB returns
to the user are written in English. The current message that no index
exists is also in english. Sadly our documentation is not
internationalised yet - afaik no language has a complete translation
and the translations are not available as a website or in any other
public form. I stopped translating to German myself as the promised
integration into the doc build was never finished in ~1.5 years. For
the specific task right now I would like to keep the scope as small as
possible. This does not mean that I would stand in the way if folks
want to add i18n to the project and its sub-projects and have the
tooling and time to maintain it.


Because a prototype speaks more than 1000 posts I hacked a prototype
which includes the warning that was proposed by Garren. You can check
it out at https://github.com/apache/couchdb-mango/pull/27 - or watch
the video: https://cloudup.com/cEnbWqbX5Y7

What do you think?

On Wed, Jan 13, 2016 at 11:58 PM, Jan Lehnardt <j...@apache.org> wrote:
>
>> On 13 Jan 2016, at 23:41, Joan Touzet <woh...@apache.org> wrote:
>>
>> 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/.”}]
>
> bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
> something like this!
>
> Great discussion everyone. I like how we are all making this idea better 
> together :)
>
> Best
> Jan
> --
>
>
>
>>
>>
>>
>> - Original Message -
>> From: "Robert Kowalski" <r...@kowalski.gd>
>> 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 <r...@kowalski.gd
>>> <javascript:;>> 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 <j...@apache.org
>>> <javascript:;>> wrote:
>&g

Re: [POC] Mango Catch All Selector

[Robert Kowalski]

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 <r...@kowalski.gd
> <javascript:;>> 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 <j...@apache.org
> <javascript:;>> wrote:
> >>
> >>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun...@gmail.com
> <javascript:;>> 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 <javascript:;>>
> >>> 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 places only to
> >>>> increase discoverability; without the url param, the no-index query
> >>>> wouldn't work at all). Bikeshed the name as needed.
> >>>>
> >>>> I'd like to see a lot more URLs in CouchDB error messages in general,
> >>>> actually - I would find it very useful when trying to determine what's
> >>>> going wrong to have a URL right there in the logs that I can get more
> >>>> information from.
> >>>>
> >>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <woh...@apache.org
> <javascript:;>> wrote:
> >>>>> Hi Robert,
> >>>>>
&

Re: [POC] Mango Catch All Selector

[Robert Kowalski]

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 <j...@apache.org> wrote:
>
>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun...@gmail.com> 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 places only to
>>> increase discoverability; without the url param, the no-index query
>>> wouldn't work at all). Bikeshed the name as needed.
>>>
>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>> actually - I would find it very useful when trying to determine what's
>>> going wrong to have a URL right there in the logs that I can get more
>>> information from.
>>>
>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <woh...@apache.org> wrote:
>>>> 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" <bed...@technicalpursuit.com>
>>>>> 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
>>>>&

Re: [POC] Mango Catch All Selector

[Robert Kowalski]

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
with their opinions - of course I'm also looking forward to your
answer :)

Best,
Robert :)

On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis  wrote:
>>> - is a timeout solving the root cause or the symptoms? Could it be a
>>> temporary or additional step as in conjunction with query optimisation
>>> tooling?
>>
>> It really depends. From my CouchDB admin and user perspective, this
>> doesn't seem so important to me right now. However, I recognize that
>> there are different usage scenarios with different requirents (e.g. the
>> ones at Cloudant).
>
> I don't think there's anything special about Cloudant in this
> discussion. Its just a question of how do we allow new users the
> ability to easily test and learn the selector/query API while also
> preventing them from going too far without creating indexes for their
> queries. The slow queries messages are fine, but just as any other
> database they don't really prompt the developer to make the correct
> change. Ie, the developer has to be savvy enough to a) know that the
> slow queries logs exist, b) understand that creating an index would
> speed things up, and then c) know which index to create based on the
> logged query.
>
> In my experience, the group of users that we're concerned about in
> this discussion most likely don't know about any of those three
> things, hence why the current API is designed to force them to learn
> about and understand indexes as part of learning the API. Granted the
> `_id > null` trick muddies that learning process. I would think that
> replacing the _id trick with `"testing": true` or similar would be an
> obvious indication to users that this is a dev/debug type feature and
> when they went to production they would still be pushed to using an
> 

Re: [POC] Mango Catch All Selector

[Robert Kowalski]

 AM, Sebastian Rothbucher <
> sebastianrothbuc...@googlemail.com> wrote:
>
>> Hi Robert,
>>
>> I'm with you that the easier we can make it for s/o to get started the
>> better.
>> And I think falling back to a full table scan with a log written is a good
>> and easy way to go. I'd even set the log level to info or even warning to
>> make it clear that there's a problem with huge data sets. And hopefully,
>> people run some load test before going into production ;-)
>>
>> The only other idea I had (a button "use default index" in Fauxton that
>> modifies the selector) looks daft on second thought
>>
>> - I do like your idea though
>>
>> Best
>> Sebastian
>>
>>
>> On Mon, Jan 4, 2016 at 8:04 PM, Paul Davis <paul.joseph.da...@gmail.com>
>> wrote:
>>
>> > Hey all,
>> >
>> > I meant to reply to the ticket on pouchdb-find but got distracted by
>> > the holidays.
>> >
>> > I wanted to note that the original motivation for rejecting a selector
>> > that doesn't have an index was to avoid the specific situation where a
>> > user has a query that appears to run quite quickly in testing/dev but
>> > fails or results in timeouts in production due to a different data
>> > set. This was definitely a deviation from the MongoDB approach. The
>> > last I read their docs on this they mentioned in a couple places that
>> > while an index is not required there are limits on result set sizes
>> > and (I think?) query time. I made the choice that rather than fail
>> > eventually to fail quickly and hopefully be descriptive of why the
>> > query failed. For instance, there should be a note in the error
>> > response when no index is available that describes which fields could
>> > be indexed to satisfy the query.
>> >
>> > On the other hand, once we had users actually playing with this
>> > feature there were quite a few instances of, "I just want to try this
>> > query without waiting for an index to build." and I made the clever
>> > suggestion that just adding the {"$and": [Query, {"_id": {"$gt":
>> > null}}]} wrapper would cause a full table scan. That's obviously a
>> > hack and I was fine with that because it seemed like an obvious hack
>> > that would motivate users to create the appropriate index before
>> > moving to production.
>> >
>> > On the flip side it seems like for some people the hack is a hurdle
>> > into learning the query capabilities as well as adding to the overhead
>> > of learning CouchDB in general. And this particular feature was aimed
>> > directly at providing an easier on-ramp to CouchDB for people coming
>> > from other databases. Given what I've read here and elsewhere perhaps
>> > what might be easiest would be to add a feature along the lines of
>> > "developing": "true" to the _find request body that would enable the
>> > _all_docs fold. This would provide two benefits in that internally we
>> > could throw different errors in specific cases. For instances, some
>> > selectors fail because they can't run against a map/reduce index (ie,
>> > $or) and that won't change no matter what map/reduce indexes are
>> > added. If we just wrap the the _all_docs hack this changes the
>> > behavior which would probably surprise new users.
>> >
>> > On the other hand, indexes can be operationally quite costly and
>> > require planning to handle capacity so I would definitely avoid
>> > automatically creating them from the _find endpoint. Perhaps we could
>> > add a feature for the _index endpoint that accepts a selector and
>> > figures out the index to create. Which I think is along the lines of
>> > what Dale mentioned but with a slightly more on purpose interaction
>> > from the user.
>> >
>> > Paul
>> >
>> > On Mon, Jan 4, 2016 at 8:05 AM, Garren Smith <gar...@apache.org> wrote:
>> > > Hi Robert,
>> > >
>> > > This is cool. I think it links in with this
>> > https://issues.apache.org/jira/browse/COUCHDB-2928 <
>> > https://issues.apache.org/jira/browse/COUCHDB-2928> and this
>> > https://github.com/nolanlawson/pouchdb-find/issues/138 <
>> > https://github.com/nolanlawson/pouchdb-find/issues/138>
>> > >
>> > > Cheers
>> > > Garren
>> > >
>> > >> On 04 Jan 2016, at 2:33 PM, Dale 

[POC] Mango Catch All Selector

[Robert Kowalski]

Hi list,

I hope you had awesome holidays!

The whole holidays I thought about an idea I had and today I
implemented a prototype which still has some bugs and isn't complete
yet.

I want to find out if there is general interest and if it would be
worth to spend more time.

The problem I am trying to solve is that I usually have a hard time
explaining people how views work. Now we got Mango and I can just say:
we use a syntax similar to MongoDB's query language _but you have to
create an index before you can use it_.

At this point I usually look into sad, big eyes because no one
understands why they have to create an index first and I feel there is
another entry barrier for newcomers. If trying anyway given they have
decided for CouchDB the user gets a error back: "no index available
for this selector".

The idea of this patch is to just fallback on the "give me all docs
and i filter afterwards"-trick that people usually use (if they know
it) when they just want to test something, without creating an index
which can take time for creation and requires further knowledge.
Additionally the user is warned that they can create an index to make
the queries faster.

What do you think? Is that something worth to work on further? The PR
is at https://github.com/apache/couchdb-mango/pull/27

You can test it with basic queries on a database which does not have
indexes for the fields you want to query created yet.


Best,
Robert :)

Re: CouchDB on DigitalOcean

[Robert Kowalski]

Awesome idea Clemens!

Check your twitterwebs :)

On Sat, Dec 19, 2015 at 5:53 PM, Clemens Stolle
 wrote:
> Hey there,
> yesterday, Jan said something like „sweet, 0 to CouchDB cluster in 120 
> seconds“ on IRC. That got me thinking.
> Currently there is no pure CouchDB SaaS offering (at least that I’m aware 
> of). Don’t worry, I’m not proposing we’d build something like that. ;)
>
> It would be pretty sweet though, if we were able to offer a DigitalOcean 
> image (or "one-click app“ as they call it). That'd get us from 0 to CouchDB 
> in 55s. :D
> Is that something the community would be interested in?
>
> DO is arguably the easiest VPS provider and really popular in the developer 
> community. It would also benefit projects like PouchDB, because interested 
> users could easily spin up an instance and test out that whole 
> replication/syncing miracle. Also MongoDB, Redis and others are already 
> present on DO.
>
> I have no idea you we’d go about doing that, though. Does anyone know folks 
> at DO?
>
> Cheers,
> Clemens

Re: Applied for official Docker image

[Robert Kowalski]

cool thank you <3

On Thu, Dec 17, 2015 at 11:28 PM, Clemens Stolle  wrote:
> Hey couch potatoes,
>
> I just submitted CouchDB to the "official-images" repo. If the review goes 
> well, CouchDB will have an official Docker image soon (like pretty much every 
> database out there). That means users will be able to "docker run couchdb" 
> instead of "docker run klaemo/couchdb".
>
> You can check the status at 
> https://github.com/docker-library/official-images/pull/1288.
>
> I submitted version 1.6.1 as well as 2.0-dev. That should make it pretty easy 
> for people to give 2.0 a spin. Of course, I'll add future releases as they 
> come out. When the review goes through, I might ask you for help with the 
> Readme for the Docker registry.
>
> Let me know, if you have any questions or concerns.
>
> Cheers,
> Clemens

Re: Let's cut a Nano release

[Robert Kowalski]

Hi I got sad news:

https://issues.apache.org/jira/browse/INFRA-10252

On Fri, Sep 18, 2015 at 4:43 PM, Jan Lehnardt <j...@apache.org> wrote:
> Great stuff, thanks! :)
>
> Jan
> --
>
>> On 18 Sep 2015, at 10:37, Robert Kowalski <r...@kowalski.gd> wrote:
>>
>> Hi!
>>
>> Update for all: I tested a transfer of a test repo together with Daniel,
>> who is part of the ASF infra team to github.com/apache. The way of the repo
>> was:
>>
>> robertkowalski -> Humbedooh -> apache
>>
>> The redirects still work with a "hop" in between over an ASF-root-person.
>>
>> I guess the last thing we need now to happen is that GitHub ships the new
>> permissions API that they have announced recently.
>>
>> It is a small success on our way, but also a big one because it proves that
>> our idea works :)
>>
>> On Fri, Sep 4, 2015 at 9:09 PM, Robert Kowalski <r...@kowalski.gd> wrote:
>>
>>> Hi Nuno,
>>>
>>> thanks for offering your help!
>>>
>>> I don't think we wait for something from you, we are just trying to
>>> somehow get the repo transferred to the ASF so we can retain the
>>> issues. One thing we have to get working on the ASF side for it is to
>>> enable GitHub issues for the repo which are disabled by default. I
>>> know Infra at least plans to support GitHub issues once GitHub
>>> released their new permissions API.
>>>
>>> Once we figured out the nitty gritty details with infra we'll ping
>>> you, but until then don't worry! :)
>>>
>>>
>>> On Fri, Sep 4, 2015 at 3:47 PM, Nuno Job <nunojobpi...@gmail.com> wrote:
>>>> Guys, to make sure are you waiting on any action on my behalf?
>>>>
>>>>
>>>>
>>>>
>>>> Happy to do whatever apache seems fit, a single official email from
>>> apache and I’ll get it done,
>>>>
>>>>
>>>>
>>>>
>>>> Take care,
>>>>
>>>> Nuno
>>>>
>>>>
>>>> —
>>>> Sent from Mailbox
>>>>
>>>> On Fri, Sep 4, 2015 at 1:26 AM, Robert Kowalski <r...@kowalski.gd> wrote:
>>>>
>>>>> Somehow I got no answer on the ML - I opened a Jira ticket:
>>>>>
>>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-10252
>>>>> On Mon, Aug 17, 2015 at 4:26 PM, Johannes Jörg Schmidt
>>>>> <schm...@netzmerk.com> wrote:
>>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>>> Hash: SHA256
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am in favor of a repo transfer because
>>>>>>
>>>>>> - - the redirect
>>>>>> - - issues and issue history
>>>>>> - - pull requests (there are two currently open where I do not have any
>>>>>> opinion, sorry!)
>>>>>> - - startgazers
>>>>>> - - wiki
>>>>>>
>>>>>> If that would be possible in any way it would be awesome.
>>>>>>
>>>>>> :) Johannes
>>>>>>
>>>>>> On 12.08.2015 03:38, Robert Kowalski wrote:
>>>>>>> i think infra could just accept the repo once there is a
>>>>>>> possibility in having github issues for asf projects
>>>>>>>
>>>>>>> i have transferred a lot of repos (but not with the asf). the cool
>>>>>>> thing is that you get a redirect for free, keep all your previous
>>>>>>> issues, wikis, PRs etc...
>>>>>>>
>>>>>>> On Wed, Aug 12, 2015 at 3:34 AM, Jason Smith
>>>>>>> <jason.h.sm...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Right, good point, Alexander.
>>>>>>>>
>>>>>>>> In that case, I would say, let's not do an actual GitHub
>>>>>>>> "transfer." There are only a few tickets. I think we could move
>>>>>>>> the key ones over by hand ourselves; and in the fullness of time,
>>>>>>>> it won't much matter.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Aug 12, 2015 at 2:39 AM, Robert Kowalski
>>>>>>>> <r...@kowalski.gd> wrote:
>>>>>>>>
>>>>>>

Got Apache CouchDB?

[Robert Kowalski]

Hi!

I am compiling a list of companies or products using CouchDB for a few 
reasons:

 - showcase logos and user stories of successful CouchDB development for a 
new website on http://couchdb.apache.org
- solicit private feedback about making CouchDB better
- help companies to hire experienced CouchDB developers
- identify new CouchDB core contributors from other companies

What we need from you:

- Company name
- Product name or use case
- Is it in production or development?
- Contact information for further questions
- Link to logo if we can showcase your company on the new site
- User quote (with attribution) about your CouchDB user experience (up to 
300 characters)

Please reply to this email or on 
https://github.com/robertkowalski/couch-labs/issues/1 if the information is 
public, or email robertkowal...@apache.org

Best,
Robert

Re: Fauxton Windows developer question

[Robert Kowalski]

Hi Joan,

thanks for the input. That is a good reason not to use Makefiles.

Hi Sebastian,

thanks for the response.

One thing I stumbled upon was that a production release is created
from the code the dev-server creates in the debug folder, but only
parts of it. (the compiled css and static assets are taken from
dist/debug -- while the js is taken from app/)

Transpiled JS code is created next to source code in the same folder -
which is then used to create a production release using requirejs in
the source dir plus transpiled less from dist/debug and other assets
that the dev-server (which serves the dev environment) creates(!). The
way how different filetypes are compiled, to which target they are
compiled and how output from our debug-server is used for production
releases makes it hard to understand and maintain the Gruntfile,
especially if you try to compose parts of it. As I already mentioned,
it is nearly impossible right now to switch to babel. A brush up would
be nice, but it means a rewrite of large parts of the Gruntfile
anyway.

Sadly that is not the only big issue we have, another issue is that
every `npm install` will build a production release on the client in
order to provide a standalone Fauxton installation. The way it should
work is that an "npm publish" creates a release artifact which gets
published to npm and contains everything that is needed already,
including the transpiled code for standalone installs.

I could go on with other issues that annoy me right now and are quite
different to standard build/release processes.

Why are the paths on the filesystem for dependencies like a swf file
not transparent to the Fauxton app? Instead the app itself knows if it
(the app itself) is a bundled release or not and decides at runtime(!)
based on this state which dependency it should include from where.
This is another workaround to deal with the different locations of
static assets in dist/debug (swf, fonts, images and css) and the
js-sourcefiles in app/ which are differently used for releases and the
debug server. It is important to note that we need this workaround
because it is not possible to fix the root cause in a proper timeframe
without rewriting large parts of the way releases are built.

Regarding grunt, Gulp & friends: this post sums my problems with
Grunt up very well:
http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ - it
just takes 5min to read and I could not have written it better.

I already spent multiple hours of work trying to brush up our
Gruntfile, and because I keep running into walls with it was the
reason why I wrote the initial mail.

I go with splitting out small parts of the build process and make them
composable, independent of the current task runner. We can use them as
standalones on the console or in Grunt, like we do with other tasks
already [1]. It just felt a bit odd to reimplement a `$(shell find
app/ -name '*.less')` in 9 lines of JavaScript [2] -- that is why I
had the idea to use a Makefile, next to the nice fact that builds with
make are idempotent. shelljs looks interesting for tasks like finding
all less files in a folder, I will try it out and maybe use it.

Best,
Robert

[1] https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js#L390
[2] https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js#L77-L86

On Mon, Oct 26, 2015 at 9:59 PM, Sebastian Rothbucher
<sebastianrothbuc...@googlemail.com> wrote:
>
> Hi,
>
> if it was me, I'd avoid plain makefiles, too. At least for fauxton. What
> about sticking with Grunt? We could still do some work to brush up the
> Gruntfile. And with a few tweaks, it's portable, even on Win (in fact: I
> found another one this WE).
>
> Best
> Sebastian
>
> On Tue, Oct 20, 2015 at 6:03 PM, Joan Touzet <woh...@apache.org> wrote:
>
> > 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" <r...@kowalski.gd>
> > > 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
> > >

Fauxton Windows developer question

[Robert Kowalski]

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] Garren Smith joins the PMC

[Robert Kowalski]

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

Re: [ANNOUNCE] Michelle Phung joins the PMC

[Robert Kowalski]

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

Fabric worker timeouts and availability of replicas

[Robert Kowalski]

Hi,

I am currently taking a look at fabric and rexi.

Given I open a doc, a CouchDB cluster returns the document.

It also returns a doc, given not all replicas (r) are available and the
*cluster is aware of it*: if the co-ordinator knows that there are fewer
than r replicas available, it returns the document with a 200.


When a worker is not available *right now*, and the call to one of them
just times out (so the cluster is not aware that one node is unavailable),
the Cluster will return a general timeout error instead of a result [1],
even if just one of the worker fails.

Should the cluster return a result instead in those cases?


[1]
https://github.com/apache/couchdb-fabric/blob/405922c5dff36e0f5822e9a3422243f217d8d0e4/src/fabric_doc_open.erl#L61

Re: Let's cut a Nano release

[Robert Kowalski]

Hi!

Update for all: I tested a transfer of a test repo together with Daniel,
who is part of the ASF infra team to github.com/apache. The way of the repo
was:

robertkowalski -> Humbedooh -> apache

The redirects still work with a "hop" in between over an ASF-root-person.

I guess the last thing we need now to happen is that GitHub ships the new
permissions API that they have announced recently.

It is a small success on our way, but also a big one because it proves that
our idea works :)

On Fri, Sep 4, 2015 at 9:09 PM, Robert Kowalski <r...@kowalski.gd> wrote:

> Hi Nuno,
>
> thanks for offering your help!
>
> I don't think we wait for something from you, we are just trying to
> somehow get the repo transferred to the ASF so we can retain the
> issues. One thing we have to get working on the ASF side for it is to
> enable GitHub issues for the repo which are disabled by default. I
> know Infra at least plans to support GitHub issues once GitHub
> released their new permissions API.
>
> Once we figured out the nitty gritty details with infra we'll ping
> you, but until then don't worry! :)
>
>
> On Fri, Sep 4, 2015 at 3:47 PM, Nuno Job <nunojobpi...@gmail.com> wrote:
> > Guys, to make sure are you waiting on any action on my behalf?
> >
> >
> >
> >
> > Happy to do whatever apache seems fit, a single official email from
> apache and I’ll get it done,
> >
> >
> >
> >
> > Take care,
> >
> > Nuno
> >
> >
> > —
> > Sent from Mailbox
> >
> > On Fri, Sep 4, 2015 at 1:26 AM, Robert Kowalski <r...@kowalski.gd> wrote:
> >
> >> Somehow I got no answer on the ML - I opened a Jira ticket:
> >>
> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-10252
> >> On Mon, Aug 17, 2015 at 4:26 PM, Johannes Jörg Schmidt
> >> <schm...@netzmerk.com> wrote:
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>>
> >>> Hello,
> >>>
> >>> I am in favor of a repo transfer because
> >>>
> >>> - - the redirect
> >>> - - issues and issue history
> >>> - - pull requests (there are two currently open where I do not have any
> >>> opinion, sorry!)
> >>> - - startgazers
> >>> - - wiki
> >>>
> >>> If that would be possible in any way it would be awesome.
> >>>
> >>> :) Johannes
> >>>
> >>> On 12.08.2015 03:38, Robert Kowalski wrote:
> >>>> i think infra could just accept the repo once there is a
> >>>> possibility in having github issues for asf projects
> >>>>
> >>>> i have transferred a lot of repos (but not with the asf). the cool
> >>>> thing is that you get a redirect for free, keep all your previous
> >>>> issues, wikis, PRs etc...
> >>>>
> >>>> On Wed, Aug 12, 2015 at 3:34 AM, Jason Smith
> >>>> <jason.h.sm...@gmail.com> wrote:
> >>>>
> >>>>> Right, good point, Alexander.
> >>>>>
> >>>>> In that case, I would say, let's not do an actual GitHub
> >>>>> "transfer." There are only a few tickets. I think we could move
> >>>>> the key ones over by hand ourselves; and in the fullness of time,
> >>>>> it won't much matter.
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 12, 2015 at 2:39 AM, Robert Kowalski
> >>>>> <r...@kowalski.gd> wrote:
> >>>>>
> >>>>>> Yes
> >>>>>>
> >>>>>> On Tue, Aug 11, 2015 at 12:25 PM, Alexander Shorin
> >>>>>> <kxe...@gmail.com> wrote:
> >>>>>>
> >>>>>>> On Tue, Aug 11, 2015 at 1:21 PM, Robert Kowalski
> >>>>>>> <r...@kowalski.gd>
> >>>>>> wrote:
> >>>>>>>> 3. Can you chime in at [1] ? Can you open the link? I
> >>>>>>>> basically asked
> >>>>>>> infra
> >>>>>>>> if we can have Github issues enabled in all our subprojects
> >>>>>>>> and if
> >>>>> they
> >>>>>>> can
> >>>>>>>> migrate nano for us together with issues, wiki,
> >>>>>>>> closed/open/prs etc.
> >>>>> If
> >>>>>>> you
> >>>>>>>> can not open the link, please ping me!
> >>>>>>>
> >>>>>>> That's only possible if you'll transfer original GH nano
> >>>>>>> repository to Apache GH account. This also means that current
> >>>>>>> couchdb-nano have to be removed.
> >>>>>>>
> >>>>>>> -- ,,,^..^,,,
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>> -BEGIN PGP SIGNATURE-
> >>> Version: GnuPG v2
> >>>
> >>> iQEcBAEBCAAGBQJV0e78AAoJED+W7gN+c0gcHLsH/2kii63zT8IWA/a90OS1WGKI
> >>> 1mCic03mVeU6grm5C3lGpgx22Y+RyyPjB9VH6sCvqGwjeb5DeooLAp0iLsR2V8OZ
> >>> bML/Ptr3bUsf5LzmnEAnDKOTOlmQRCwQj3FOhWwmMjLPXK3zcZPqE0Xs1px3w/Mr
> >>> lyjy7nfQb53SuOq4u70C1BpllvDnwFrQntbxkVam9d4OD66Dh+J1cMNPWhidIZWr
> >>> pKWkv8np9cpf52DaFORSLyQd5i/mXpfIAL/CRA5DzYoKcCm/lEGkuZDr2a6cSbGy
> >>> T3KRLU4m3EMDCb7kuquLz1+gTe1+zpVXtpThobfCUdaTTtnidyd/zIclLBSZx1g=
> >>> =WWJd
> >>> -END PGP SIGNATURE-
>

Re: Project Fauxton Feedback

[Robert Kowalski]

Hi Eli,

you can try to modify [1] and [2]

Happy hacking,
Robert :)


[1]
https://github.com/apache/couchdb-fauxton/blob/5de1fe6682fc5a9dee44022498357febd73c3600/settings.json.default#L67

[2]
https://github.com/apache/couchdb-fauxton/blob/730e856dcc6f8716e1a797d6bf0fabe27a62cbc9/tasks/helper.js#L17

On Thu, Sep 17, 2015 at 9:34 PM, Eli Stevens (Gmail) <wickedg...@gmail.com>
wrote:

> Is there a recommended way to `grunt couchapp_deploy` to a non-local
> CouchDB instance? None of our DB hosts have git installed (meant to
> match our production deployment hosts in terms of installed packages,
> so we explicitly don't want git there).
>
> Alternatively, is there a way to get fauxton master without having to
> keep a local repo up to date? I know that bower can interact with
> github directly, but I'm not sure if there's something similar for
> npm.
>
> Cheers,
> Eli
>
>
> On Thu, Sep 17, 2015 at 9:26 AM, Michelle Phung <michel...@apache.org>
> wrote:
> > Hi Eli,
> >
> > We don’t use a schedule for the NPM package or Fauxton releases. The
> reason being is because we enjoy being able to fix bugs and merge them, and
> have that code be the latest code everyone works off of. The master branch
> moves FAST, from my point of view.  Fauxton comes standard shipped with
> CouchDB, and that is considered the latest stable tested release.  The NPM
> Fauxton package is a fairly new development for us, but auxiliary to all
> the other things we have to do :)
> >
> > Unfortunately, the npm package fauxton@1.0.3 is a bit outdated (4
> months), and we haven’t integrated a work flow that updates it every time
> we commit a fix, but I will bring that up moving forward for us.
> >
> > I am going to bug Robert K. to show me how to update the node package
> tomorrow, and so it should be updated soon! hopefully it’ll be available
> over the weekend/next week for you guys.
> >
> > Try the github repo in the meantime though!
> >
> > :)
> > Michelle
> >
> >> On Sep 16, 2015, at 8:32 PM, Eli Stevens (Gmail) <wickedg...@gmail.com>
> wrote:
> >>
> >> I just (mostly) followed the instructions at (except for the -g part,
> >> since I didn't want it global):
> >>
> >> https://www.npmjs.com/package/fauxton
> >>
> >> And ran the following:
> >>
> >> npm install fauxton
> >> cd node_modules/fauxton/node_modules/.bin/ ; ./grunt couchapp_deploy
> >>
> >> Which had references to "fauxton@1.0.3 node_modules/fauxton" in the
> output.
> >>
> >> Does that answer the question?
> >>
> >> Aside, is what I did the best way to get a mostly-stable version of
> >> fauxton? I assumed that would be more stable that pulling directly
> >> from git. This goes back to my earlier question about releases; it's
> >> not clear what the best way to get something new and usable is.
> >>
> >> Thanks,
> >> Eli
> >>
> >> On Wed, Sep 16, 2015 at 3:06 PM, Michelle Phung <michel...@apache.org>
> wrote:
> >>> Hi Eli,
> >>>
> >>> JIRA is the place for bugs.
> >>>
> >>> Its kind of tough to get people to look at it though, since there’s a
> lot going on with JIRA, and its a little endless.
> >>>
> >>> I thought we fixed the problem you described though.
> >>> Did you pull from https://github.com/apache/couchdb-fauxton, the
> master branch?
> >>>
> >>> Michelle
> >>>
> >>>
> >>>
> >>>> On Sep 16, 2015, at 5:50 PM, Eli Stevens (Gmail) <
> wickedg...@gmail.com> wrote:
> >>>>
> >>>> Where is the appropriate place to file bugs against Fuaxton? Most
> >>>> recent I see in JIRA is Feb. 15th of this year.
> >>>>
> >>>> As of a couple of hours ago when I updated my install, the view query
> >>>> options UI wasn't respecting start and end keys (though the link to
> >>>> the raw JSON is correct).
> >>>>
> >>>> On Wed, Aug 19, 2015 at 11:34 AM, Eli Stevens (Gmail)
> >>>> <wickedg...@gmail.com> wrote:
> >>>>> I agree with kexpal's comment on the PR; large documents would make
> >>>>> this very, very painful.
> >>>>>
> >>>>> I was asking for a view checkbox that would result in a 3rd column
> for
> >>>>> view results (key / value / optional doc) that defaulted to off, so
> >>>>> that I could include it when appropria

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

[Robert Kowalski]

Hi Johs,

there is some more material I know of which completes the talk from Isaac.

 - A talk which tries to take a look what motivates people in Open Source
and what happens when at some point some people are paid to do certain
tasks in the project [1]

 - The book "Producing Open Source Software", written by the author of our
neighbors at the ASF that maintain the svn project - which was also part of
Isaacs talk as further reference [2]

 - Parts of "Natalia Berdys: The web experience in the autistic spectrum"
[3]

In the end it is all about input and output. You throw things into your
mail, that get's read by real people. Real people are behind that screen,
and these people have feelings. These people get feelings when they read
your response.

I am not sure what you mean by avoiding conflict or enforcing conflict to
build a skyscraper. I think you can build a good skyscraper or also a
smaller project if your group is able to give proper feedback. If your
group is not able to give proper feedback to everyone on a regular basis
building everything gets harder - if not impossible.


[1]
http://bofh.nikhef.nl/events/FOSDEM//2012/maintracks/k.1.105/Caret_and_Stick.webm
[2] http://producingoss.com/
[3] https://www.youtube.com/watch?t=2=7nnAYB1mb9E


On Tue, Sep 15, 2015 at 7:37 PM, Johs Ensby <j...@b2w.com> wrote:

> Robert,
>
> the video that you recommended caught my interest and I saw the whole
> thing trough again and took a closer into the philosophy behind it. The NVC
> ideology didn't pass my standards, I am afraid.
> The danger of totally abandoning the concept of objective truth is that
> you end up with everybody's feelings as the only sacred thing in this world.
> To avoid conflict to maximize your transaction with people (you get what
> you need and I get what I need) can be good in a short-term business
> relation, but not if you try to build a good machine or sky scraper.
>
> Would be interesting to know if anyone know of a paper that deals with the
> difference in values and beliefs in the best OSS teams.
>
> Johs
>
>
>
> > On 15. sep. 2015, at 02.48, Johs Ensby <j...@b2w.com> wrote:
> >
> > Thanks for this video, Robert
> > Very interesting, any other input like this that captures knowhow about
> how to make OSS communities productive and compassionate would be highly
> appreciated
> >
> > Johs
> >
> >
> >> On 14. sep. 2015, at 19.35, Robert Kowalski <r...@kowalski.gd  r...@kowalski.gd>> wrote:
> >>
> >> I would really recommend this talk which explains a lot of Human-Human
> >> interactions in communities:
> https://www.youtube.com/watch?v=PSv7GIX-XQ0 <
> https://www.youtube.com/watch?v=PSv7GIX-XQ0>
> >>
> >> I would be really interested in your feedback about it as a possible
> >> building block for further discussions about Jan's and Jason's mails.
> >
>
>

Re: A Plan: Remove pre-commit, jshint, code style requirements from couchdb-nano

[Robert Kowalski]

Hey there,

just as a report how we are doing it with Fauxton:

the Fauxton project also has a styleguide in order to make reviews and
reading code easier for everyone. At one point it turned out to reduce a
lot of work for the reviewers if we test automatically for the coding style
as part of our testsuite.

We don't use commit hooks for it, but the CI will fail if the automatic
coding style check and also the testsuite was not successful. the style
check is runs before the unit tests run, which run before the integration
tests. Red tests (that include tests for style) are a no-go for a merge in
Fauxton.

I don't think the checks must be enforced on a pre/post-commit-hook-level
but somewhere they should notify the proposer of the change to make the
live of the reviewer easier - in case you think code style is important for
your project. I also want to not that some sub projects of CouchDB have no
styleguide at all and that it can be a positive thing or a negative thing.
Having one worked out well for Fauxton.

I also think that deploying with a red CI might be OK in exceptional cases,
but in these cases the deploying person should be aware why the test fails
in 100%, and know the reasons why it is not fixable right now.

In the recent past I have seen people saying they would know why the
integration tests fails, delivering buggy releases.

I think it is a small boundary and not everyone who says they know why the
tests fail is 100% sure why they really fail (and deploys broken releases
therefore). But I have worked with people that were so deep into the
testsuites and the project they maintained in the past that they were able
to predict that.

In short I support whatever you decide for I just wanted to share my
experiences, maybe it helps :)

On Tue, Sep 15, 2015 at 2:54 PM, Jason Smith 
wrote:

> Hi, Dale.
>
> On Tue, Sep 15, 2015 at 7:26 PM, Dale Harvey  wrote:
>
> >
> > I just wanted to clarify, are you speaking about removing as a
> "pre-commit
> > hook", or removing the requirements for those checks to pass before
> > merging?
> >
>
> I am speaking about removing the pre-commit hook only--the mechanical thing
> that that runs automatically when one commits.
>
> The tests and checks would make brilliant push hooks, or perhaps Travis
> tests for pull requests. However they are a bit much as a *commit* hook.
>
> A separate conversation: should the tests pass for merging. I would say:
> yes if it's smart; no if it's dumb: they need not pass for merging, at
> least not automatically, mechanically. The reason is that we should merge
> pull requests liberally, accepting contributions from all, then commit on
> top of those to correct for style. I won't have some sort of angry
> Calvinist robot telling me I can't merge a pull request. (If we can be
> clever, for example to require all tests pass for the master branch but not
> feature branches, then yes I would love that.)
>

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

[Robert Kowalski]

+1 Jason :)

Especially: someone wrote it in their spare time, spent the whole night on
it, and feels really miserable the day after.

On Tue, Sep 15, 2015 at 1:08 PM, Jason Smith 
wrote:

> Thanks, Jan.
>
> On Tue, Sep 15, 2015 at 5:18 PM, Jan Lehnardt  wrote:
> >
> > 3. if you disagree with employing a “Yes, and…”-style in the CouchDB
> > community, make a counter proposal that you think gets us to a better
> > culture.
> >
>
> TL;DR = We are doing that; but what is "better"? To me, it means fun and
> enjoyable.
>
> ## Long version
>
> I think everybody is indeed making proposals for better culture. However,
> it sounds to me like we never really defined "better" (at least in this
> thread). Different (successful) communities can make different conclusions
> about that.
>
> The code of conduct is a rough guide of "good" culture. It sets the minimum
> standard, but not the maximum
>
> Apache CouchDB is not a corporate, professional product; it is an open
> source, volunteer project. It should *not* meet professional standards, but
> it should rather meet fun standards. In other words, if it feels like a
> job, a slog, to work on CouchDB, then that's just no fun. At its best,
> CouchDB is fun and relaxed.
>
> I mean: let's just step back and look at CouchDB for a moment. Like, what
> are we even talking about? We have embedded JavaScript inside of Erlang,
> and the whole thing is a web server. That is on its face just completely
> bonkers. That's great! It's beautiful! But it's bonkers, no question. I
> would enjoy a community that is similarly light-hearted and leisurely.
>
> When I read a post on the list, I pretend somebody wrote it in their spare
> time, and my own objective when engaging them is to try to make them feel
> like it was *leisure* time well-spent.
>

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

[Robert Kowalski]

Oh wow, so much feedback!

I think Jason and Jan (and also me with my initial post) are trying to
advocate a more positive way of giving feedback.

I would really recommend this talk which explains a lot of Human-Human
interactions in communities: https://www.youtube.com/watch?v=PSv7GIX-XQ0

I would be really interested in your feedback about it as a possible
building block for further discussions about Jan's and Jason's mails.



On Mon, Sep 14, 2015 at 6:58 PM, Jan Lehnardt  wrote:

>
> > On 14 Sep 2015, at 18:49, ermouth  wrote:
> >
> >> Have you ever played "Dungeons and Dragons"?
> >
> > Sorry, I played Civilization. What I learned was that saying ‘No’ at
> right
> > moment is much more important to have excellent score, then saying ‘Yes’
> > each time )
> >
> >> For example, in the oauth2 discussion
> >
> > As for oAuth, I think @CouchDB has a lot of readers, and asking them does
> > anyone use oauth, is more elegant way to decide should feature be
> dropped.
>
> I already know the answer :) — Also, why didn’t you bring that up in that
> thread?
>
> Best
> Jan
> --
>
> >
> > ermouth
> >
> > 2015-09-14 17:38 GMT+03:00 Jason Smith :
> >
> >> Have you ever played "Dungeons and Dragons"?
> >>
> >> I think the "yes-and" style is more about continuing the momentum of the
> >> conversation, and also having fun!
> >>
> >> The "yes-and" style is independent of your opinion about the matter, or
> the
> >> facts of its consequences. To me, it is about being Socratic: say
> "Sure!"
> >> and then ask what the next steps are, or what the expected consequences
> >> will be.
> >>
> >> For example, in the oauth2 discussion, I think Jan used a bit of
> "yes-and"
> >> style, when he said "Yes, let's keep oauth2, provided a developer fixes
> its
> >> bugs; otherwise not." And I think the community collectively answered:
> >> "Yes, let's throw it out."
> >>
> >> On Mon, Sep 14, 2015 at 8:22 PM, 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 each other, that we
> >> have
>  the best of the project in mind, we shouldn’t have a problem
> >> disagreeing
>  with each other.
> 
>  If you come at this is discussion from “if this happens, I’ll leave
> the
>  project”, then you probably don’t trust me to make good suggestions
> >> about
>  our culture. How can  I improve that?
> 
> 
> > Without phrases ‘You don‘t like it? Farewell’, surely.
> 
>  I’m sorry for the harsh tone, but I’m also really fed up with lazy
> >>> excuses
>  of why we shouldn’t be a better community, and I especially called
> this
> >>> out
>  in my original message, and now we already have a number of messages
> on
>  this thread that have nothing to do with the actual issue. That’s the
> >>> kind
>  of stuff that makes we very very tired participating here.
> 
>  Best
>  Jan
>  --
> 
> 
> 
> 
> >
> > 

Re: [PROPOSAL] Create an account for designers to contribute to CouchDB

[Robert Kowalski]

> more ideas?

Slack

On Mon, Sep 14, 2015 at 5:19 PM, Michelle Phung 
wrote:

> Hello,
>
> I would like to open an account on a platform for CouchDB designers,
> design advocates, and design enthusiasts.
>
> It is a place to discuss all things design related with respect to CouchDB.
> It could be a good place for people to learn about design.
>
> there are some design threads on github, which let people comment, and it
> supports inline comments with screenshots, but maybe some designers are not
> on github.
>
> medium.com is another option.
>
> more ideas?
>
> Michelle Phung

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

[Robert Kowalski]

That was not was I was pointing out, please read my mail at [1] again, I
mentioned:

 - making proposals _in general_ is hard and the feedback is not
encouraging, because of the way feedback is given
 - feedback is sometimes not very constructive, and requires a few other
persons that step in to get feedback that you can work with
 - i have gotten this type of feedback multiple times in the past in this
project and could imagine it makes it hard for people to start working with
us in such an environment

I also want to add that there is also nobody requesting from you to give
wrong feedback to a very bad idea. Nobody said that.

What actually happens regularly is that a good idea with good intentions
maybe has a small weakness how it could be realized, for example an idea
how we could improve CouchDB. What then happens is that the special type of
feedback you get is something like "that won't work" and then you are
suddenly in the position where you have to defend the idea (which has some
nits) in an _all or nothing way_.

This is the opposite to feedback that will let you refine the parts of your
idea that has issues immediately.  But by getting feedback like "that is
impossible" or "that won't work" you often get into the position where you
have to defend the overall idea and your intention and that can feel quite
tedious.

I think we should aim to give feedback to ideas without the need of other
people stepping in to get a good result.

Btw. did you see the video? What do you think?

[1]
http://mail-archives.apache.org/mod_mbox/couchdb-dev/201509.mbox/%3CCAJ1bcfH93V8HypHBbPNzOx1T7bN-iWBts2SZor8X1oSmq1DPLA%40mail.gmail.com%3E

On Mon, Sep 14, 2015 at 8:56 PM, ermouth <ermo...@gmail.com> wrote:

> >  a more positive way of giving feedback
>
> Ok, lets build a tree to compare sugar floods with reality )
>
>1. Michelle proposed design@ ML, good intention – but no realistic
> plan.
>1. Everybody agree, ML created, and dies right after birth for well seen
>   reasons.
>   2. Someone says ‘We already have www@, that is abandoned’ – and
>   discussion starts.
>2. Majority insists idea is good as is – but still no plan or prognosis
>on obstacles. Also majority begin to depress the only person, who dared
> to
>express doubts vocally. Pressure is not direct – this community is
> highly
>civilized – but collectively mixing in some aside principles and rules
> is
>highly effective way to isolate and fade out any opinion.
>1. Everybody (as well as person, who initially criticized) agrees with
>   majority, ML created and dies right after birth for well seen
> reasons.
>   2. Someone other enumerates very low level problems directly, saying
>   ‘ML is irrelevant, because it lacks this, that and forth’.
>3. Majority still insists idea is good and increase pressure using aside
>principles and rules.
>1. Everybody agrees, ML created and dies right after birth for well seen
>   reasons.
>   2. Someone begin to think, how to workaround possible obstacles and
>   shows alternatives.
>
> You can by yourself choose, which steps and approach might produce death of
> idea before it was born, and which steps made idea stronger.
>
> I played school theater zillion years ago, and know, that ‘yes-and’ is good
> for solving on-stage stalls. Nothing for that zillions years after proved
> me, that restricted lexical patterns are good for improving real things )
>
> Time to time negative feedback is a key for any open system‘s stability
> regulation and sustainable grow. Sugar floods only good when you make jam.
> It‘s tasty, surely, but it can‘t grow, because sugar is conservant.
>
> BR
>
>
> ermouth
>
> 2015-09-14 20:35 GMT+03:00 Robert Kowalski <r...@kowalski.gd>:
>
> > Oh wow, so much feedback!
> >
> > I think Jason and Jan (and also me with my initial post) are trying to
> > advocate a more positive way of giving feedback.
> >
> > I would really recommend this talk which explains a lot of Human-Human
> > interactions in communities: https://www.youtube.com/watch?v=PSv7GIX-XQ0
> >
> > I would be really interested in your feedback about it as a possible
> > building block for further discussions about Jan's and Jason's mails.
> >
> >
> >
> > On Mon, Sep 14, 2015 at 6:58 PM, Jan Lehnardt <j...@apache.org> wrote:
> >
> > >
> > > > On 14 Sep 2015, at 18:49, ermouth <ermo...@gmail.com> wrote:
> > > >
> > > >> Have you ever played "Dungeons and Dragons"?
> > > >
> > > > Sorry, I played Civilization. What I learned was that saying ‘No’ at
> > > right
> > > > moment is 

Re: [PROPOSAL] Create des...@couchdb.apache.org mailing list

[Robert Kowalski]

>  While idea is good and clear, I don't believe that we can attract
> enough people to have this ML alive. Suddenly, our active part of
> community is quite small and here question lays in dimension to make
> their life easy and to not loose even them

That's a good point, sometimes I ask myself if our community is so small
because it is so hard to make proposals and because of the type of feedback
they receive.

I sometimes get the feeling many proposals with good intentions are not
getting much constructive feedback at some point from a few persons. There
is almost always someone how says something negative that is not helpful
for anyone, like: "that is impossible" or "that does not make sense to me"
or "we don't attract enough people for that".

It is important to note that there is usually no suggestion included how we
could fix the problem instead.

Taking a look at my proposals these responses don't help me to continue to
try to make the project better. I am suddenly in the situation where I have
to defend why something is not "impossible". These responses also don't
encourage me to stick to the proposal I submitted. They also cause a lot of
friction for me and make me sad, sometimes angry.

When I would have read these feedbacks 1-2 years ago when I was very new to
the project they would have made me go away from the project.

In the future I would be super happy to hear questions or suggestions like
"how can we attract enough people to make a possible design ML a thriving
place for many designers?" instead - if someone thinks that this might be a
problem.

For proposals that I've written in the past months it would help me to work
further on the proposed idea and motivate me to try to improve CouchDB and
I think it would also apply to others.



I am +1 on the design ML. I am also +1 on every experiment to make it
easier for designers to participate in CouchDB.

On Thu, Sep 10, 2015 at 8:04 PM, Alexander Shorin  wrote:

> On Thu, Sep 10, 2015 at 8:50 PM, Michelle Phung 
> wrote:
> > You didn’t say it like that exactly in irc :P but you did allude to it :)
> >
> > I thought you meant that if I opened a design@ML that people would use
> it sparsely as they used the www@ML sparsely. :)
>
> Then I was not clear (: Sorry.
>
> > We could reuse www@ but its a narrow label for all things design.
> > Although www@ML as a name is not very descriptive as to what is being
> discussed (for new people).
> >
> > I’d like the design@ML to be an umbrella for design discussions. and
> people know right away its about design.
> > It will be like a door for designers to come to couchDB through.
>
> Since our design topics are www-related, it makes hard to decide where
> to start topic about some, let's say, Fauxton feature. On one hand,
> it's www-related, however, without design bits users cannot use it.
> Split discussion over two ML's sounds as overkill.
>
> While idea is good and clear, I don't believe that we can attract
> enough people to have this ML alive. Suddenly, our active part of
> community is quite small and here question lays in dimension to make
> their life easy and to not loose even them.
>
> There is a reason to create a new ML to isolate some specific
> discussions from the others (like erlang talks from frontend). But you
> want to fragmentate fronend topics while existed ML is not much
> active. I'm fine with new ML, but I don't think it's reasonable to
> have it now.
>
> --
> ,,,^..^,,,
>

Re: [PROPOSAL] Improving the quality of CouchDB

[Robert Kowalski]

Hi Jan,

how would testing of a PR/change work in practice?

Example: I am opening 3 Pull-Requests that depend on each other, one in
chttpd, one in fabric and one in rexi.

Or is the idea that the testsuite turns red when the deps are updated in
the top level module?

On Thu, Sep 10, 2015 at 2:09 PM, Jan Lehnardt  wrote:

>
> > On 10 Sep 2015, at 12:18, Alexander Shorin  wrote:
> >
> > On Thu, Sep 10, 2015 at 12:40 PM, Dale Harvey 
> wrote:
> >> I dont think CI is a dream, It should take an afternoon at most to get
> >> CouchDB setup on travis on a single platform to ensure no major
> regressions
> >> come though. If anyone wants help doing that feel free to ping me on
> >> #pouchdb / #couchdb, we already test couchdb master in travis.
> >
> > It is a dream for now.
> >
> > We have travis enabled, but it has practical flaw: it cannot handle
> > changes that affected multiple repositories at the same time. Also,
> > for each repository we have to build full CouchDB to test what is a
> > bit overkill.
> >
> >> I do think multirepos is an issue and that solution is not so simple, we
> >> went through the same issues with pouchdb as we attempted to split out
> our
> >> repository.
> >
> > Well, there was a good theory that each of our repository will contain
> > an app which could be reused outside of CouchDB or being easily
> > replaced by alternative implementation. Suddenly, for now most of our
> > apps are heavy coupled
>
> There are two distinct functions that git does for us here:
> 1. Separate code into different modules.
> 2. Make a module available to downstream users.
>
> In a Node/npm, Python/pip, Ruby/Gems world, 1. is solved by git, 2. is
> solved by npm/pip/Gems. Is there a way to publish an Erlang module for
> downstream users
> independently of git? If yes, we could move back to a single-git-tree
> model for
> CouchDB, but we can still release parts as independent modules. I know
> there have
> been a few attempts at Erlang package managers, but has anything taken off?
>
> * * *
>
> For Hoodie, we came up with this, based on our experience with using the
> full top level test suite on each module (it is indeed overkill):
>
> - separate modules
> - one module that is the top level module (like our couchdb.git) that only
> includes module dependencies and a top-level integration test suite.
> - two release trains: stable and next.
> - a service that attempts to create a new version of the top level module
> with every commit to a dependent module. E.g. we automatically bump the
> dependency in a checkout of the top level module, run the integration
> tests, if they fail, nothing happens and we report that back on the commit
> to the dependent module. If it succeeds, we automatically determine the
> next version number on the next release train (SemVer makes that easy) and
> release the new top level module with the updated dependency.
> - once we are comfortable that the next release train is stable enough for
> a release, we change switch out the release trains: next becomes stable,
> and we have a new empty next train (npm uses release tags for this, but the
> mechanics are irrelevant, although something like that needs to be
> supported in the package manager).
>
> This requires:
> - Strict SemVer on all modules (we use
> https://github.com/semantic-release/semantic-release) to make sure humans
> can’t screw this up.
> - Breaking change detection, so we don’t accidentally release a BC break
> in a non-major version (available as semantic-release plugins).
> - the service that does the auto-update dance described above.
>
> This is a lot of infrastructure (and some of it we are still developing),
> but once in place, it is really simple to not screw this up and it takes a
> huge cognitive load off of everyday development.
>
> Semantic-Release is language agnostic in theory, but afaik there are only
> Node and Python versions, so we’d have to find someone to make an Erlang
> variant. Also, the process uses npm heavily, so some sort of package
> management system would be nice.
>
> Eventually, I’d love to see this for CouchDB.
>
> PS: The person who invented semantic-release works for my company, and I’d
> be more than happy to have them have a crack at this. If anyone wants to
> sponsor an erlang-semantic-release, please get in touch.
>
> * * *
>
> Either way, this is a bit of a long shot. For now:
>
> We should do what Dale proposed in 2.: pin top level dependencies. I
> believe that was the plan all along, but with a fast moving 2.0 we just
> didn’t do it yet. Now is the time to pin versions and manually upgrade them
> after thorough testing (can still be in PRs and tested on Travis and
> everything).
>
> That means all of these modules (and their sub-deps) should get releases
> and release tags and those tags need to be filled into our top-level
> rebar.config.script:
>
> 

Re: [PROPOSAL] Improving the quality of CouchDB

[Robert Kowalski]

Cool! I like the idea! :)


On Thu, Sep 10, 2015 at 6:38 PM, Jan Lehnardt <j...@apache.org> wrote:

>
> > On 10 Sep 2015, at 18:31, Robert Kowalski <r...@kowalski.gd> wrote:
> >
> > Hi Jan,
> >
> > how would testing of a PR/change work in practice?
> >
> > Example: I am opening 3 Pull-Requests that depend on each other, one in
> > chttpd, one in fabric and one in rexi.
> >
> > Or is the idea that the testsuite turns red when the deps are updated in
> > the top level module?
>
> Yeah, if the top module only works with all three PRs in concert, you get
> two broken builds and then a working build.
>
> (some of the details of what I explained earlier might make it sound that
> this isn’t possible, rest assured, we’ve considered this case :)
>
> Best
> Jan
> --
>
> >
> > On Thu, Sep 10, 2015 at 2:09 PM, Jan Lehnardt <j...@apache.org> wrote:
> >
> >>
> >>> On 10 Sep 2015, at 12:18, Alexander Shorin <kxe...@gmail.com> wrote:
> >>>
> >>> On Thu, Sep 10, 2015 at 12:40 PM, Dale Harvey <d...@arandomurl.com>
> >> wrote:
> >>>> I dont think CI is a dream, It should take an afternoon at most to get
> >>>> CouchDB setup on travis on a single platform to ensure no major
> >> regressions
> >>>> come though. If anyone wants help doing that feel free to ping me on
> >>>> #pouchdb / #couchdb, we already test couchdb master in travis.
> >>>
> >>> It is a dream for now.
> >>>
> >>> We have travis enabled, but it has practical flaw: it cannot handle
> >>> changes that affected multiple repositories at the same time. Also,
> >>> for each repository we have to build full CouchDB to test what is a
> >>> bit overkill.
> >>>
> >>>> I do think multirepos is an issue and that solution is not so simple,
> we
> >>>> went through the same issues with pouchdb as we attempted to split out
> >> our
> >>>> repository.
> >>>
> >>> Well, there was a good theory that each of our repository will contain
> >>> an app which could be reused outside of CouchDB or being easily
> >>> replaced by alternative implementation. Suddenly, for now most of our
> >>> apps are heavy coupled
> >>
> >> There are two distinct functions that git does for us here:
> >> 1. Separate code into different modules.
> >> 2. Make a module available to downstream users.
> >>
> >> In a Node/npm, Python/pip, Ruby/Gems world, 1. is solved by git, 2. is
> >> solved by npm/pip/Gems. Is there a way to publish an Erlang module for
> >> downstream users
> >> independently of git? If yes, we could move back to a single-git-tree
> >> model for
> >> CouchDB, but we can still release parts as independent modules. I know
> >> there have
> >> been a few attempts at Erlang package managers, but has anything taken
> off?
> >>
> >> * * *
> >>
> >> For Hoodie, we came up with this, based on our experience with using the
> >> full top level test suite on each module (it is indeed overkill):
> >>
> >> - separate modules
> >> - one module that is the top level module (like our couchdb.git) that
> only
> >> includes module dependencies and a top-level integration test suite.
> >> - two release trains: stable and next.
> >> - a service that attempts to create a new version of the top level
> module
> >> with every commit to a dependent module. E.g. we automatically bump the
> >> dependency in a checkout of the top level module, run the integration
> >> tests, if they fail, nothing happens and we report that back on the
> commit
> >> to the dependent module. If it succeeds, we automatically determine the
> >> next version number on the next release train (SemVer makes that easy)
> and
> >> release the new top level module with the updated dependency.
> >> - once we are comfortable that the next release train is stable enough
> for
> >> a release, we change switch out the release trains: next becomes stable,
> >> and we have a new empty next train (npm uses release tags for this, but
> the
> >> mechanics are irrelevant, although something like that needs to be
> >> supported in the package manager).
> >>
> >> This requires:
> >> - Strict SemVer on all modules (we use
> >> https://github.com/semantic-release/semantic-release) to make sure
> humans
&

Re: [PROPOSAL] Improving the quality of CouchDB

[Robert Kowalski]

Thanks for the many answers!

> It sounds to me like the primary thrust of your argument is about
continuous
> integration--somehow making it more easy and more transparent for
> developers (seasoned and novice) to see the effects of their change. Is
> that right?

Yes, exactly!

> So, what is the immediate next step that you propose to fix or improve?
> What is the most squeaky wheel, or the most modest gain that we can make?

I think one of the biggest problems is that we don't have a working CI and
that PRs are getting merged without running it. The other problem is that
we have a lot of untested changes going into master.

For a step by step plan I suggest:

 - Setup a simple CI that makes it easy to test before a merge, e.g. like
this [1]. The CI can be really simple, just 1 Erlang version and one OS -
but let's get started somewhere. Do you have other ideas how to solve CI,
PRs and the multi-repo-approach?

 - With a working CI system for the multi-repo setup merging should just
happen with a green CI. Flaky tests should get fixed or deleted.

 - We would require that every change needs tests if not covered elsewhere
already. This might include that untestable code has to be refactored
first, a problem many legacy applications face (btw a good book on this is
"Working Effectively with Legacy Code". This would automatically make our
code more testable and increase test coverage over time in a
very efficient way. This would also allow us to add features while slowly
refactoring the code.

- Bonus step: we could make our lifes a bit easier. The video in [2] shows
how we could build a pipeline that just shows a merge button if the
testsuite was green. On a click on the button the Jenkins would merge the
PR. Why: merging over multiple repos right now is a lot of manual work,
let's automate most of our boring, daily tasks.


@Sebastian: do you plan to submit the integration test change? is the work
somewhere available?

[1] https://cloudup.com/cOgxRPbt9aP
[2] https://cloudup.com/c0VJDIoYqmI

On Tue, Sep 8, 2015 at 11:38 AM, Jason Smith <jason.h.sm...@gmail.com>
wrote:

> Hi, Robert. Well, that was very long and I read every word! Thank you for
> your thoughtful assessment and feedback!
>
> You make many points across several different areas of concern. It sounds
> to me like the primary thrust of your argument is about continuous
> integration--somehow making it more easy and more transparent for
> developers (seasoned and novice) to see the effects of their change. Is
> that right?
>
> So, what is the immediate next step that you propose to fix or improve?
> What is the most squeaky wheel, or the most modest gain that we can make?
>
> Thanks again!
>
> On Mon, Sep 7, 2015 at 9:49 PM, Robert Kowalski <r...@kowalski.gd> wrote:
>
> > Hi list,
> >
> > I had my first real programming job in a Web Agency. We were building
> > mobile websites for our external customers. The development process
> > followed a strict waterfall model, after you finished your project it was
> > thrown over the fence to the QA folks, which tested the website manually.
> > At some point, when all found bugs were fixed, the product got released.
> > Sometimes a bugfix took several iterations of going back and forth
> between
> > QA and dev. Sometimes the QA folks forgot to test if the bug was really
> > fixed after the third iteration as humans make errors, especially when it
> > is a boring task.
> >
> > After a lifetime of 2 years, the customer usually wanted a redesign, and
> > the next developer throwed everything of the old website away, as not
> much
> > of it was reusable. When something broke during the life of such an
> > application/website, the company and developers noticed that by the
> > customer calling them.
> >
> > These days I think often about my time in my first job and the customers
> > calling the company regarding bugs. Right now the Erlang core of CouchDB
> > reminds me quite often how our customers called us when something broke.
> > For CouchDB 2 it is not the users that call us right now, but PouchDB and
> > Fauxton when their testsuites gets red or incredible slow.
> >
> > When I was starting to work on Fauxton we were in a somehow similar
> > situation, a merge usually had 2-3 fixes on the same or next day, because
> > something somehow broke. A proper review for a change took incredible
> much
> > time and every pull request needed a lot of iterations. The most evil
> > changes were the ones where you fixed a bug in one area, and a completely
> > different area broke. These bugs were so evil because they were
> surprising
> > and unexpected.
> >
> > After a real big issue we tried out that every cha

Re: CouchDB got 100% slower in the past 3 weeks

[Robert Kowalski]

Hi folks,

the performance issues seem to be fixed for COUCHDB-2796.

Here is how CouchDB internals look like for an document update after the patch:

https://dl.dropboxusercontent.com/u/1809262/flame-couch-epi-update-doc-fixed.svg

The heavy bar for couch_epi_functions_gen:providers/4 in the middle
completely disappeared.

You may wonder why all other bars in the svgs are now wider. Given the
fact that we are always watching one operation to complete in a
flamegraph which splits the calls up in percentage of CPU time this is
the expected behaviour for a performance improve.

When we shrink an perfomance-heavy call in the graph from 30% to lets
say 0.5% the others fall more into account on the next graph. So in
this case the growth of all other bars other than the ones from
couch-epi is a good thing.

Same for the calls in the flamegraph for a simple GET of a document,
which previously added up to 33% CPU time for the given operation
(reading and returning a doc):

https://dl.dropboxusercontent.com/u/1809262/flame-epi-fixed.svg


Here are the original flamegraphs from Sunday, in case you missed them:

Update doc:  
https://dl.dropboxusercontent.com/u/1809262/flame-couch-epi-update-doc.svg
Simple GET: https://dl.dropboxusercontent.com/u/1809262/flame-epi.svg

The PouchDB project also confirmed that the performance decrease is
fixed now, but it seems some attachment related tests are failing now.

Big thanks to everyone involved fixing this! :)

Best,
Robert

PS: in case if you are interested in an intro to flamegraphs and
profiling, this war-story [1] is quite interesting. It is not Erlang
but the concept is language agnostic and therefore easy to apply to
Erlang

[1] http://techblog.netflix.com/2014/11/nodejs-in-flames.html

On Sun, Aug 30, 2015 at 11:15 PM, Robert Kowalski <r...@kowalski.gd> wrote:
> Hi list,
>
> I got pinged as our friends from PouchDB notices that their testsuite
> with CouchDB 2 as a backend suddenly takes 100% longer (20mins instead
> of 10). [1] Because the diff was so significant I got really curious
> and worried about it.
>
> This testsuite just took 10min
>
> https://travis-ci.org/pouchdb/pouchdb/jobs/74585676 (22 days old)
>
> vs
>
> https://travis-ci.org/pouchdb/pouchdb/jobs/77865796 (yesterday)
>
> which took like the other runs these days 20min.
>
> I wasn't really sure, maybe the travis VMs changed. Or Pouch.
>
> Based on the report I created a few flamegraphs to poke around what
> changed in CouchDBs internals. They look quite different to the ones I
> created in the past weeks:
>
> https://dl.dropboxusercontent.com/u/1809262/flame-couch-epi-update-doc.svg
>
> this flamegraphs shows the update of a doc. couch-epi takes 33% of the
> time and blocks.
>
> https://dl.dropboxusercontent.com/u/1809262/flame-epi.svg
>
> in this flamegraph I receive a document. I have 3 blocking calls to
> couch_epi, adding up to 21% time of the request.
>
> The report from Nolan (perf decrease of 100% in a timeframe from 3
> weeks) fits into the timeframe where we added couch_epi. As almost
> every module uses couch_epi the performance decrease of almost all
> APIs also fits into the scheme. And I think the flamegraphs show that
> the additional time is spent in couch_epi.
>
>
> - I see that couch_epi uses the codeserver internally, would it be
> possible to use faster ETS tables?
> - Anything else we could do?
>
> Best,
> Robert
>
> [1] https://github.com/pouchdb/pouchdb/issues/4209#issuecomment-135964232

[PROPOSAL] Improving the quality of CouchDB

[Robert Kowalski]

Hi list,

I had my first real programming job in a Web Agency. We were building 
mobile websites for our external customers. The development process 
followed a strict waterfall model, after you finished your project it was 
thrown over the fence to the QA folks, which tested the website manually. 
At some point, when all found bugs were fixed, the product got released. 
Sometimes a bugfix took several iterations of going back and forth between 
QA and dev. Sometimes the QA folks forgot to test if the bug was really 
fixed after the third iteration as humans make errors, especially when it 
is a boring task.

After a lifetime of 2 years, the customer usually wanted a redesign, and 
the next developer throwed everything of the old website away, as not much 
of it was reusable. When something broke during the life of such an 
application/website, the company and developers noticed that by the 
customer calling them.

These days I think often about my time in my first job and the customers 
calling the company regarding bugs. Right now the Erlang core of CouchDB 
reminds me quite often how our customers called us when something broke. 
For CouchDB 2 it is not the users that call us right now, but PouchDB and 
Fauxton when their testsuites gets red or incredible slow.

When I was starting to work on Fauxton we were in a somehow similar 
situation, a merge usually had 2-3 fixes on the same or next day, because 
something somehow broke. A proper review for a change took incredible much 
time and every pull request needed a lot of iterations. The most evil 
changes were the ones where you fixed a bug in one area, and a completely 
different area broke. These bugs were so evil because they were surprising 
and unexpected.

After a real big issue we tried out that every change would need unit 
and/or integration tests for several weeks.

Writing unit tests was very hard these days, most of the code was not 
designed to get tested afterwards. So most of the tests written in that 
time were Selenium based integration tests. This was better than nothing 
but they were slow. Nevertheless, they caught a lot of bugs, even before 
code was sent to the review. When we made a switch to React and a different 
architecture for our components and their communication, better and easier 
unit/functional testing was one of the many design goals.

Writing good Selenium tests is incredible hard, as you basically face the 
same problems you have in the distributed systems world in the world of 
modern UIs. State and data changes asynchronously and you never know when 
the result of your request, which changes the UI is returned. It even gets 
harder by putting this on top of an eventually consistent system :)

Sometimes we also pair-programmed in a video call in front of a test where 
coming up with a good test was the problem, as we also had to share and 
gain knowledge in the team how to write tests. One mistake we made was of 
not fixing flaky tests immediately and adding more and more flaky tests and 
just restarting the CI for a few weeks. At some point our CI system just 
collapsed and it took the team a long time to fix those, partly also 
because tests were a new topic and it is hard to understand why Selenium 
tests fail in an async JS application with a cluster beneath it which is 
eventually consistent. Additionally it decreased the confidence in a red 
tests signaling a bug.

After fixing the testsuite in this early crisis we've got pretty stable 
tests. Additionally reviews take much less time. Reviews got even faster 
when we added a pre-check for our coding guidelines to the testsuite. If 
you take a look at a day in the time when we began writing tests, we 
sometimes lost an hour to write those tests, because it was hard. Looking 
just at this short timeframe it felt like we were losing time. But if we 
take a look at a longer timeframe we did not decrease in our speed to 
deliver features for several reasons: less bugfixes needed after code got 
on master, less tickets and communication because of less bugs, faster 
reviews because many bugs are caught before the reviewer takes a look and 
so on. Some people in the team still hate writing tests but also everyone 
on the team realized and also mentions that we have no other options.

Right now I am seeing the same pattern we observed some time ago in Fauxton 
for CouchDB's Erlang core :

 - not noticing something broke (if you break it, will you even notice?)
 - eventually a user in the broader sense notices something broke
 - a lot of patching to fix patches where stuff broke in another place
 - regressions
 - it takes time to review code properly because of a large api surface and 
a lot of functionality

I would like to propose that every PR needs unit, functional AND/OR 
integration tests for CouchDB's Erlang core, too - given it is not covered 
by an existing test that run. Maybe we could try the new approach for 3 
months and then decide if we keep it.

Most 

Re: Let's cut a Nano release

[Robert Kowalski]

Hi Nuno,

thanks for offering your help!

I don't think we wait for something from you, we are just trying to
somehow get the repo transferred to the ASF so we can retain the
issues. One thing we have to get working on the ASF side for it is to
enable GitHub issues for the repo which are disabled by default. I
know Infra at least plans to support GitHub issues once GitHub
released their new permissions API.

Once we figured out the nitty gritty details with infra we'll ping
you, but until then don't worry! :)


On Fri, Sep 4, 2015 at 3:47 PM, Nuno Job <nunojobpi...@gmail.com> wrote:
> Guys, to make sure are you waiting on any action on my behalf?
>
>
>
>
> Happy to do whatever apache seems fit, a single official email from apache 
> and I’ll get it done,
>
>
>
>
> Take care,
>
> Nuno
>
>
> —
> Sent from Mailbox
>
> On Fri, Sep 4, 2015 at 1:26 AM, Robert Kowalski <r...@kowalski.gd> wrote:
>
>> Somehow I got no answer on the ML - I opened a Jira ticket:
>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-10252
>> On Mon, Aug 17, 2015 at 4:26 PM, Johannes Jörg Schmidt
>> <schm...@netzmerk.com> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Hello,
>>>
>>> I am in favor of a repo transfer because
>>>
>>> - - the redirect
>>> - - issues and issue history
>>> - - pull requests (there are two currently open where I do not have any
>>> opinion, sorry!)
>>> - - startgazers
>>> - - wiki
>>>
>>> If that would be possible in any way it would be awesome.
>>>
>>> :) Johannes
>>>
>>> On 12.08.2015 03:38, Robert Kowalski wrote:
>>>> i think infra could just accept the repo once there is a
>>>> possibility in having github issues for asf projects
>>>>
>>>> i have transferred a lot of repos (but not with the asf). the cool
>>>> thing is that you get a redirect for free, keep all your previous
>>>> issues, wikis, PRs etc...
>>>>
>>>> On Wed, Aug 12, 2015 at 3:34 AM, Jason Smith
>>>> <jason.h.sm...@gmail.com> wrote:
>>>>
>>>>> Right, good point, Alexander.
>>>>>
>>>>> In that case, I would say, let's not do an actual GitHub
>>>>> "transfer." There are only a few tickets. I think we could move
>>>>> the key ones over by hand ourselves; and in the fullness of time,
>>>>> it won't much matter.
>>>>>
>>>>>
>>>>> On Wed, Aug 12, 2015 at 2:39 AM, Robert Kowalski
>>>>> <r...@kowalski.gd> wrote:
>>>>>
>>>>>> Yes
>>>>>>
>>>>>> On Tue, Aug 11, 2015 at 12:25 PM, Alexander Shorin
>>>>>> <kxe...@gmail.com> wrote:
>>>>>>
>>>>>>> On Tue, Aug 11, 2015 at 1:21 PM, Robert Kowalski
>>>>>>> <r...@kowalski.gd>
>>>>>> wrote:
>>>>>>>> 3. Can you chime in at [1] ? Can you open the link? I
>>>>>>>> basically asked
>>>>>>> infra
>>>>>>>> if we can have Github issues enabled in all our subprojects
>>>>>>>> and if
>>>>> they
>>>>>>> can
>>>>>>>> migrate nano for us together with issues, wiki,
>>>>>>>> closed/open/prs etc.
>>>>> If
>>>>>>> you
>>>>>>>> can not open the link, please ping me!
>>>>>>>
>>>>>>> That's only possible if you'll transfer original GH nano
>>>>>>> repository to Apache GH account. This also means that current
>>>>>>> couchdb-nano have to be removed.
>>>>>>>
>>>>>>> -- ,,,^..^,,,
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJV0e78AAoJED+W7gN+c0gcHLsH/2kii63zT8IWA/a90OS1WGKI
>>> 1mCic03mVeU6grm5C3lGpgx22Y+RyyPjB9VH6sCvqGwjeb5DeooLAp0iLsR2V8OZ
>>> bML/Ptr3bUsf5LzmnEAnDKOTOlmQRCwQj3FOhWwmMjLPXK3zcZPqE0Xs1px3w/Mr
>>> lyjy7nfQb53SuOq4u70C1BpllvDnwFrQntbxkVam9d4OD66Dh+J1cMNPWhidIZWr
>>> pKWkv8np9cpf52DaFORSLyQd5i/mXpfIAL/CRA5DzYoKcCm/lEGkuZDr2a6cSbGy
>>> T3KRLU4m3EMDCb7kuquLz1+gTe1+zpVXtpThobfCUdaTTtnidyd/zIclLBSZx1g=
>>> =WWJd
>>> -END PGP SIGNATURE-

Re: Let's cut a Nano release

[Robert Kowalski]

Somehow I got no answer on the ML - I opened a Jira ticket:

https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-10252

On Mon, Aug 17, 2015 at 4:26 PM, Johannes Jörg Schmidt
<schm...@netzmerk.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello,
>
> I am in favor of a repo transfer because
>
> - - the redirect
> - - issues and issue history
> - - pull requests (there are two currently open where I do not have any
> opinion, sorry!)
> - - startgazers
> - - wiki
>
> If that would be possible in any way it would be awesome.
>
> :) Johannes
>
> On 12.08.2015 03:38, Robert Kowalski wrote:
>> i think infra could just accept the repo once there is a
>> possibility in having github issues for asf projects
>>
>> i have transferred a lot of repos (but not with the asf). the cool
>> thing is that you get a redirect for free, keep all your previous
>> issues, wikis, PRs etc...
>>
>> On Wed, Aug 12, 2015 at 3:34 AM, Jason Smith
>> <jason.h.sm...@gmail.com> wrote:
>>
>>> Right, good point, Alexander.
>>>
>>> In that case, I would say, let's not do an actual GitHub
>>> "transfer." There are only a few tickets. I think we could move
>>> the key ones over by hand ourselves; and in the fullness of time,
>>> it won't much matter.
>>>
>>>
>>> On Wed, Aug 12, 2015 at 2:39 AM, Robert Kowalski
>>> <r...@kowalski.gd> wrote:
>>>
>>>> Yes
>>>>
>>>> On Tue, Aug 11, 2015 at 12:25 PM, Alexander Shorin
>>>> <kxe...@gmail.com> wrote:
>>>>
>>>>> On Tue, Aug 11, 2015 at 1:21 PM, Robert Kowalski
>>>>> <r...@kowalski.gd>
>>>> wrote:
>>>>>> 3. Can you chime in at [1] ? Can you open the link? I
>>>>>> basically asked
>>>>> infra
>>>>>> if we can have Github issues enabled in all our subprojects
>>>>>> and if
>>> they
>>>>> can
>>>>>> migrate nano for us together with issues, wiki,
>>>>>> closed/open/prs etc.
>>> If
>>>>> you
>>>>>> can not open the link, please ping me!
>>>>>
>>>>> That's only possible if you'll transfer original GH nano
>>>>> repository to Apache GH account. This also means that current
>>>>> couchdb-nano have to be removed.
>>>>>
>>>>> -- ,,,^..^,,,
>>>>>
>>>>
>>>
>>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJV0e78AAoJED+W7gN+c0gcHLsH/2kii63zT8IWA/a90OS1WGKI
> 1mCic03mVeU6grm5C3lGpgx22Y+RyyPjB9VH6sCvqGwjeb5DeooLAp0iLsR2V8OZ
> bML/Ptr3bUsf5LzmnEAnDKOTOlmQRCwQj3FOhWwmMjLPXK3zcZPqE0Xs1px3w/Mr
> lyjy7nfQb53SuOq4u70C1BpllvDnwFrQntbxkVam9d4OD66Dh+J1cMNPWhidIZWr
> pKWkv8np9cpf52DaFORSLyQd5i/mXpfIAL/CRA5DzYoKcCm/lEGkuZDr2a6cSbGy
> T3KRLU4m3EMDCb7kuquLz1+gTe1+zpVXtpThobfCUdaTTtnidyd/zIclLBSZx1g=
> =WWJd
> -END PGP SIGNATURE-

CouchDB got 100% slower in the past 3 weeks

[Robert Kowalski]

Hi list,

I got pinged as our friends from PouchDB notices that their testsuite
with CouchDB 2 as a backend suddenly takes 100% longer (20mins instead
of 10). [1] Because the diff was so significant I got really curious
and worried about it.

This testsuite just took 10min

https://travis-ci.org/pouchdb/pouchdb/jobs/74585676 (22 days old)

vs

https://travis-ci.org/pouchdb/pouchdb/jobs/77865796 (yesterday)

which took like the other runs these days 20min.

I wasn't really sure, maybe the travis VMs changed. Or Pouch.

Based on the report I created a few flamegraphs to poke around what
changed in CouchDBs internals. They look quite different to the ones I
created in the past weeks:

https://dl.dropboxusercontent.com/u/1809262/flame-couch-epi-update-doc.svg

this flamegraphs shows the update of a doc. couch-epi takes 33% of the
time and blocks.

https://dl.dropboxusercontent.com/u/1809262/flame-epi.svg

in this flamegraph I receive a document. I have 3 blocking calls to
couch_epi, adding up to 21% time of the request.

The report from Nolan (perf decrease of 100% in a timeframe from 3
weeks) fits into the timeframe where we added couch_epi. As almost
every module uses couch_epi the performance decrease of almost all
APIs also fits into the scheme. And I think the flamegraphs show that
the additional time is spent in couch_epi.


- I see that couch_epi uses the codeserver internally, would it be
possible to use faster ETS tables?
- Anything else we could do?

Best,
Robert

[1] https://github.com/pouchdb/pouchdb/issues/4209#issuecomment-135964232

[ANNOUNCE] Clemens Stolle elected as CouchDB committer

[Robert Kowalski]

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: Project Fauxton Feedback

[Robert Kowalski]

Thank you for your feedback!

Based on the feedback we will try to enable `include_docs` per default:

https://github.com/apache/couchdb-fauxton/pull/499

What do you think?

On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall
james.dingw...@zynstra.com wrote:
 Eli Stevens (Gmail) wrote:

 On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall
 james.dingw...@zynstra.com wrote:

 I get the impression that more whizzy effects (fade in/out, sliding divs
 etc) have been added which don't play nicely with remote sessions with
 low bandwidth so a preference to use more basic transitions would be
 useful.

 +1

 Note that it looks like the mailing list strips screenshots, so you
 might need to host-and-link them.

 Thanks Eli, I didn't notice that when I received a copy of my post. I
 have placed my unchanged comments and screen shots in a github gist
 available from:

 https://gist.github.com/JKDingwall/6b2a6377d94a83ea5d63


 James
 Zynstra is a private limited company registered in England and Wales
 (registered number 07864369). Our registered office and Headquarters are at
 The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its contents
 and any attachments are confidential. If you have received this message in
 error please delete it from your system and advise the sender immediately.

Re: Let's cut a Nano release

[Robert Kowalski]

Hey Jason,

thanks for bringing this up again! Really appreciated!

1. cool!

2. For Fauxton we just use the Component field in Jira. Do you mean
setting up a whole new Jira (e.g. CouchDB, Cassandra) or setting up a
subcomponent. The latter is easy, just type in the new component name when
creating a ticket.

3. Can you chime in at [1] ? Can you open the link? I basically asked infra
if we can have Github issues enabled in all our subprojects and if they can
migrate nano for us together with issues, wiki, closed/open/prs etc. If you
can not open the link, please ping me!

5. Yes I think we still need votes for an official apache release. Yes, I
agree.

[1]
https://mail-search.apache.org/pmc/private-arch/infrastructure/201507.mbox/%3CCAJ1bcfG9isogmctdqOOHAr8EPv3DONGK+z=xbborsjm6mv0...@mail.gmail.com%3E

On Tue, Aug 11, 2015 at 8:13 AM, Jason Smith jason.h.sm...@gmail.com
wrote:

 Hi, dev@. And hi, Johannes (hope you see this).

 Last month, you asked what to do about releasing Apache Nano (or Apache
 CouchDB Nano, or whatever its name is).

 I would like to get involved in that effort, and to help push it forward.

 Nuno and the team graciously donated the project to the ASF. I know that
 much. Here are some open questions I feel remain.

 1. There are still commits going into github.com/dscape/nano although only
 Johannes so-far. I will submit a pull request to dscape to update the
 README to point to the ASF project.

 2. We have no JIRA project for it. May I get involved in creating that? Any
 tips?

 3. We have no issue tracker in GitHub either. For me, I would personally do
 what I once learned from Jan (collect feedback from customers where they
 are). So I would like to have github issues if possible? Any way I can
 help?

 4. What about publishing to npm? IMO, le mieux, c'est l'ennemi du bien, I
 am happy asking Johannes to prepare a Git tag, then ask Johannes to `git
 pull; git checkout; npm publish`. And then we can sort out the real fix
 later, yeah?

 5. What about publishing outside of npm? Must we still cut the release
 artifacts, and have the VOTEs? My feeling is, the vote is proper and
 useful, but the release artifacts are largely useless, given the ubiquity
 of npm in the Node.js community.

 Thanks, all!

Re: Let's cut a Nano release

[Robert Kowalski]

Yes

On Tue, Aug 11, 2015 at 12:25 PM, Alexander Shorin kxe...@gmail.com wrote:

 On Tue, Aug 11, 2015 at 1:21 PM, Robert Kowalski r...@kowalski.gd wrote:
  3. Can you chime in at [1] ? Can you open the link? I basically asked
 infra
  if we can have Github issues enabled in all our subprojects and if they
 can
  migrate nano for us together with issues, wiki, closed/open/prs etc. If
 you
  can not open the link, please ping me!

 That's only possible if you'll transfer original GH nano repository to
 Apache GH account. This also means that current couchdb-nano have to
 be removed.

 --
 ,,,^..^,,,

Re: Let's cut a Nano release

[Robert Kowalski]

i think infra could just accept the repo once there is a possibility in
having github issues for asf projects

i have transferred a lot of repos (but not with the asf). the cool thing is
that you get a redirect for free, keep all your previous issues, wikis, PRs
etc...

On Wed, Aug 12, 2015 at 3:34 AM, Jason Smith jason.h.sm...@gmail.com
wrote:

 Right, good point, Alexander.

 In that case, I would say, let's not do an actual GitHub transfer. There
 are only a few tickets. I think we could move the key ones over by hand
 ourselves; and in the fullness of time, it won't much matter.


 On Wed, Aug 12, 2015 at 2:39 AM, Robert Kowalski r...@kowalski.gd wrote:

  Yes
 
  On Tue, Aug 11, 2015 at 12:25 PM, Alexander Shorin kxe...@gmail.com
  wrote:
 
   On Tue, Aug 11, 2015 at 1:21 PM, Robert Kowalski r...@kowalski.gd
  wrote:
3. Can you chime in at [1] ? Can you open the link? I basically asked
   infra
if we can have Github issues enabled in all our subprojects and if
 they
   can
migrate nano for us together with issues, wiki, closed/open/prs etc.
 If
   you
can not open the link, please ping me!
  
   That's only possible if you'll transfer original GH nano repository to
   Apache GH account. This also means that current couchdb-nano have to
   be removed.
  
   --
   ,,,^..^,,,
  
 

[ANNOUNCE] Bastian Krol elected as CouchDB committer

[Robert Kowalski]

Dear community,

I am pleased to announce that the CouchDB Project Management Committee
has elected Bastian Krol as a CouchDB committer.

Apache ID: bastiankrol

IRC nick: basti1302

Twitter: bastiankrol

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 Bastian'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 Bastian!

On behalf of the CouchDB PMC,
Robert :)

Cloudant Search is Open Source now!

[Robert Kowalski]

Hi list,

I am happy to announce that Cloudant open sourced the Search Stack
that is powering the Cloudant Search features. [1]

It consists of two repositories, Dreyfus, written in Erlang and
Clouseau as a Scalang project that uses Lucene.

Dreyfus is compatible with the new clustering features of CouchDB and
makes use of them. It establishes links between the VMs / nodes to get
the results from the shards before merging them as the final result
which is returned to the user. For details how it works under the hood
see this document [4]

Are the two projects something the CouchDB community would be
interested in as part of the ASF, maybe as optional addon?

Best,
Robert :)

[1] https://cloudant.com/blog/open-sourcing-cloudant-search/
[2] https://github.com/cloudant-labs/dreyfus
[3] https://github.com/cloudant-labs/clouseau
[4] https://github.com/cloudant-labs/dreyfus/blob/master/README.md

npm releases and ASF releases

[Robert Kowalski]

Hi there,

I am picking up some questions Johannes asked regarding npm releases
and the ASF/ASF releases and reposting them, it seems they got lost in [1].


 And how do we handle npm releases? Currently Nuno Job, Pedro Teixeira
 and me have write access on npmjs.com. This needs to be changed so we
 maybe can have a CouchDB account? Also, how does the Apache release
 procedure work for npm packages?

That is a really good question and also applies to nmo. Btw: How often
do you release new nano versions?

If I remember right an official ASF release must be a tarball on ASF
servers. npm creates tarballs before it publishes it and I think it
can also create just a tarball at an output location [1]

While an official release must be located on an ASF server as an
tarball and there must be a vote on them, you can additionally host
the release additionally somewhere else (e.g. npm)

Jan told me Hoodie will use the special npm tag next for their latest
releases. The latest official ASF release from nano could then be
nano@latest/nano@major.minor.patch and the latest of the git master
could be nano@next. Every few weeks we then vote and release a new
official ASF release.

Apache Cordova is also releasing their npm packages on a weekly basis,
most of the process is automated through a cli client [2].
They probably use an npm account registered for private@ to publish
new packages (same concept we use for our twitter account)

I would be interested in helping to automate our releases, probably
together with Bastian who is doing great work for the new CI.


Do you have other suggestions how to handle it?


Best,
Robert


[1] 
http://mail-archives.apache.org/mod_mbox/couchdb-dev/201507.mbox/%3C55A6868D.9050809%40netzmerk.com%3E

[2] 
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md

Re: Welcome nano to the ASF! :)

[Robert Kowalski]

Hi Johannes,


 What happens with the old repository? Can we just move the GitHub
 Repository? I would love to keep the stargazers, wiki and issues. And
 having a redirect to the new repo also would be great.

I guess that is possible, we have to request that at the Infra team.
Currently there is no way for ASF repos to get GitHub issues and the
wiki but the Infrateam is currently working on that. I will ping them.

 And how do we handle npm releases? Currently Nuno Job, Pedro Teixeira
 and me have write access on npmjs.com. This needs to be changed so we
 maybe can have a CouchDB account? Also, how does the Apache release
 procedure work for npm packages?

That is a really good question and also applies to nmo. Btw: How often
do you release new nano versions?

If I remember right an official ASF release must be a tarball on ASF
servers. npm creates tarballs before it publishes it and I think it
can also create just a tarball at an output location [1]

While an official release must be located on an ASF server as an
tarball and there must be a vote on them, you can additionally host
the release additionally somewhere else (e.g. npm)

Jan told me Hoodie will use the special npm tag next for their latest
releases. The latest official ASF release from nano could then be
nano@latest/nano@major.minor.patch and the latest of the git master
could be nano@next. Every few weeks we then vote and release a new
official ASF release.

Apache Cordova is also releasing their npm packages on a weekly basis,
most of the process is automated through a cli client [2]

I would be interested in helping to automate our releases, probably
together with Bastian who is doing great work for the new CI.


Best,
Robert

[1] https://docs.npmjs.com/cli/pack
[2] 
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md

On Wed, Jul 15, 2015 at 6:13 PM, Johannes Jörg Schmidt
schm...@netzmerk.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 This is awesome!

 What happens with the old repository? Can we just move the GitHub
 Repository? I would love to keep the stargazers, wiki and issues. And
 having a redirect to the new repo also would be great.

 And how do we handle npm releases? Currently Nuno Job, Pedro Teixeira
 and me have write access on npmjs.com. This needs to be changed so we
 maybe can have a CouchDB account? Also, how does the Apache release
 procedure work for npm packages?

 Your happy newcomer,
 Johannes


 On 15.07.2015 01:56, Robert Kowalski wrote:
 Hi!

 I am happy to welcome nano as a new subproject of the CouchDB
 project!

 Nano is a minimalistic Node.js client for CouchDB.

 The code is located at
 https://git-wip-us.apache.org/repos/asf?p=couchdb-nano.git;a=summary

  The GitHub mirror is available now:
 https://github.com/apache/couchdb-nano

 Simple Quickstart:

 # clone the project from GitHub if you intent to send a PR for a
 review git clone https://github.com/apache/couchdb-nano.git

 # add the asf repos as upstream if you are a committer, if not,
 becoming a # committer is easy, get involved! git remote add
 upstream https://git-wip-us.apache.org/repos/asf/couchdb-nano.git

 # create pull requests as usual

 # hint: use this gist for easy reviewing of github PRs
 https://gist.github.com/piscisaureus/3342247

 # after a merge, push to upstream git push upstream master

 important to know: force pushes on master are disabled.


 Happy hacking everyone!

 Robert :)


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVpoaMAAoJED+W7gN+c0gcMOgH+wQ6krZIkbRG2Cq6Xu76OnZg
 rd7SCQ11LCJUW3KwbdPzieOyvgGvNWaBktCOu/gAWi7kXYZQQXfqBc780CSb74RL
 yZfU+JiqPFreXRIfP05XsvSsdkAcVDgolNP0mJQdIwPyWNmUKMccr+zZQl6eH8l4
 YAR26HlFRR8MbDfbNCbX2rozFsNQSLbAK3K8bWUVhTVcCeEm5kjMkM/iG1Hcsu2r
 ep83CQoP/7vdGGgWYwdBDIGfyYSOCUlnTu+UawbL78zI7oZKzKnCy/rICjvW02wa
 Kpe/nZA7tuOJAx9J2lU7ZDjWMAEj8Pzd6Yb1/o2Urw9SBFe7T9iZ3XPc9WMx6Kw=
 =3pw4
 -END PGP SIGNATURE-

nmo - Welcome to the ASF :)

[Robert Kowalski]

Hi!

More JavaScript Goodness, this time written in ES6/ES 2015!

nmo is now a subproject of CouchDB, like nano. nmo is a cli client for
managing couchdb 2.0 clusters.

The code is located at
https://git-wip-us.apache.org/repos/asf?p=couchdb-nmo.git;a=summary

The GitHub mirror is available now:
https://github.com/apache/couchdb-nmo

Simple Quickstart:

# clone the project from GitHub if you intent to send a PR for a review
git clone https://github.com/apache/couchdb-nmo.git

# add the asf repos as upstream if you are a committer, if not, becoming a
# committer is easy, get involved!
git remote add upstream https://git-wip-us.apache.org/repos/asf/couchdb-nmo.git

# create pull requests as usual

# hint: use this gist for easy reviewing of github PRs
https://gist.github.com/piscisaureus/3342247

# after a merge, push to upstream
git push upstream master

important to know: force pushes on master are disabled.


Happy hacking! :)

Robert

Welcome nano to the ASF! :)

[Robert Kowalski]

Hi!

I am happy to welcome nano as a new subproject of the CouchDB project!

Nano is a minimalistic Node.js client for CouchDB.

The code is located at
https://git-wip-us.apache.org/repos/asf?p=couchdb-nano.git;a=summary

The GitHub mirror is available now:
https://github.com/apache/couchdb-nano

Simple Quickstart:

# clone the project from GitHub if you intent to send a PR for a review
git clone https://github.com/apache/couchdb-nano.git

# add the asf repos as upstream if you are a committer, if not, becoming a
# committer is easy, get involved!
git remote add upstream https://git-wip-us.apache.org/repos/asf/couchdb-nano.git

# create pull requests as usual

# hint: use this gist for easy reviewing of github PRs
https://gist.github.com/piscisaureus/3342247

# after a merge, push to upstream
git push upstream master

important to know: force pushes on master are disabled.


Happy hacking everyone!

Robert :)

[PROPOSAL] Fauxton config and the new config API

[Robert Kowalski]

Hi folks,

in the last week we got a new API endpoint:

```
_node/fqdn/_config
```

Using this endpoint you can reach every node in a cluster by
specifying the name of the node.

This sound cool to me for using it in Fauxton as the Fauxton team
wants to keep the ability to configure CouchDB using Fauxton like in
1.x where you can change your config on a CouchDB that is running in
production.

In the last days I worked with the API in Fauxton and had to explain
the new config section in Fauxton to several people and while doing
that I got more and more aware that it is not really working well for
multi-node-setups.

Here are the things I found out or I had to explain:

- the feature is not intended for more than 5, maybe 10 nodes as it is
not feasible for the user and also gets more and more error prone the
more nodes we have in the cluster (e.g. network partitions)

- for all other settings the cluster is in a state where the configs
on the nodes are different, maybe up to 10 minutes for a 10 nodes
cluster that gets a new configuration manually using the UI by
clicking through the nodes. For a change of the Basic-Auth settings
that means that the user (developer using CouchDB) has to throw a lot
of code onto the client that uses CouchDB to handle the situation of
the inconsistent cluster

- when we try to just update all nodes at once using multiple AJAX
requests the cluster is maybe inconsistent for a few seconds. While
this is also a problem it really gets a problem when we try to change
sections like the admin-config where Fauxton gets a 401 at some point.
The 401 happens as the node we are talking to with our JS already got
the new password and applied the change. This problem looks different
when talking directly to a node or talking to it behind a load
balancer (as the load balancer shuffles our requests to /_session)

- given we solved the previous problem for Basic Auth, Admin-Sections
and the login and we try to update all nodes at once and one request
fails, the cluster is also inconsistent. I think this is the same
reason why we are not using erlang rpc calls behind the scenes to send
configuration updates to all nodes. For the user (dev) it would also
mean that they have to add a lot of logic to their clients to handle
the case that the config change of the admin fails temporally for one
node, e.g because a HTTP request timed out.


Here is the proposal for the config section in Fauxton:

Detect if we are running in Single Node Mode. This can be a N=0
setting which was set by the setup wizard that is coming to Fauxton if
the user chooses that they don't want to setup a cluster - or can also
be a node count of 1 in /_memberships.

Just if that is the case, we are displaying the config as we can
guarantee that the config and login is working for the user. If we
detect that we have multiple nodes we are displaying an info with our
suggested way to change the config for clusters.

For the case a node is not joined into a 50 nodes cluster yet there is
no use-case in using Fauxton for configuration as they will be managed
automatically, but even then an admin could use the UI to copy over
the config bits to the new node until it is joined. Until then and
also after the join (given the admin copied all config sections
properly) the UI stays usable (no random 401s)

The new endpoint would be still useful for ad-hoc HTTP queries to find
out the config of a given node. If it turns out to be unuseful we
could remove it later and learned more how our users (admins, devs
etc.) use CouchDB.

This way we can keep the config section for small setups which will
also be a fair amount of Couch 2 installations, provide a reliable UI
with the same high quality of the past and have a way to find out
configs for nodes using HTTP on the cluster interface.

Best,
Robert

Re: [DISCUSSION] nmo to the ASF

[Robert Kowalski]

Hi after some vacations!

Just to clarify and to give answers to the questions asked in the
thread and the discussion:

It was never my direct intention to ship nmo with CouchDB in a release
(see initial post). While I am +1 to make it an official tool for
managing clusters (at least for now as we don't have a better
alternative), I really don't have hard feelings to _not_ include it in
an official release - feel free to discuss this, my donation/repo move
is not tied to any decision or opinion regarding that and I am also
happy to _not_ take part in that discussion, as these discussions tend
to be very time consuming and demanding, at least for me. Whatever the
final decision is, I am happy to help in any way once it is decided.

I also think the right way is to add it to the ASF - I am a single
person and CouchDB has some awesome JavaScripters that can help
maintaining it. I built it because I saw that CouchDB was missing such
a tool while I was working on the install-wizard-ticket. I built it
for the CouchDB project with a limited personal use-case for me.

I can just double Jan's answer to io and node. I also want to add that
I think we, the CouchDB project, can learn a lot from the two projects
and the now forming foundation, as they have a lot more contributors
(339 folks currently - that is a lot for a singe project). They also
have more momentum and companies participating in core development: it
seems they have done at least some things right. In general, not tied
to node/io I can just recommend to everyone to also take a look beyond
CouchDB and to try to identify what other big projects do right or
where they fail, we can learn a lot!

I just wanted to answer the questions/statements from my perspective
as I started the thread and as I see the thread moves to a +1 for
moving robertkowalski/nmo to apache/couchdb-nmo I think I am starting
the process this week.

Best,
Robert


On Wed, Jun 3, 2015 at 8:13 PM, Joan Touzet woh...@apache.org wrote:
 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 j...@apache.org
 To: dev@couchdb.apache.org, Joan Touzet woh...@apache.org
 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 woh...@apache.org 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 j...@apache.org
  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 kxe...@gmail.com
  wrote:
 
  On Wed, Jun 3, 2015 at 4:12 PM, Jan Lehnardt j...@apache.org
  wrote:
  On 03 Jun 2015, at 15:09, Alexander Shorin kxe...@gmail.com
  wrote:
 
  On Wed, Jun 3, 2015 at 4:01 PM, Jan Lehnardt j...@apache.org
  wrote:
  On 03 Jun 2015, at 14:43, Alexander Shorin kxe...@gmail.com
  wrote:
 
  On Wed, Jun 3, 2015 at 1:40 PM, Jan Lehnardt j...@apache.org
  wrote:
  On 03 Jun 2015, at 04:38, Alexander Shorin
  kxe...@gmail.com
  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 

Re: [PROPOSAL] GitHub issues

[Robert Kowalski]

Hi Jan,

can you give me an status update?

On Wed, Jun 3, 2015 at 10:05 PM, Jan Lehnardt j...@apache.org wrote:

 On 03 Jun 2015, at 22:01, Joan Touzet woh...@apache.org wrote:

 On 03 Jun 2015, at 21:46, Joan Touzet woh...@apache.org 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? ;)

 Will do, if Robert doesn’t beat me to it :)

 Thanks Joan, sorry for the crossed wires!

 Best
 Jan
 --

[PROPOSAL] GitHub issues

[Robert Kowalski]

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:


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

Fauxton 1.0.3 released

[Robert Kowalski]

Hi! We released Fauxton 1.0.3, containing a lot of smaller bugfixes
and improvements:


 - IndexResults: don't throw on deleting a second doc

Fix an issue where all result lists were throwing in case we
deleted one document and then tried to select another document
and delete it.

 - Mango: reset Header Controller

Reset the Header-Controller (select-buttons) after creating a new
index and clicking on the link in the notification.

 - Loading lines now animate on FF

 - view creation: fix back button

when you hit the back button after creating a view, the view
broke

 - cors: don't throw on undefined origins

   e.g. when _config was loading very slow

 - mango: display error message

   show error message if index creation failed

 - mango: add edit button

   add small button over the index list to jump to the edit
   index screen

[REMINDER] IRC meeting - 2015-06-03 18:00 UTC

[Robert Kowalski]

Hi all,

We'll be having the usual meeting in #couchdb-meeting on
irc.freenode.org at 18:00 UTC, Wednesday as usual.

The meeting room:

irc://irc.freenode.net/couchdb-meeting

Or you can access the meeting via the web:

http://webchat.freenode.net/?channels=#couchdb-meeting

For your local timezone:

http://arewemeetingyet.com/UTC/2015-06-03/18:00/CouchDB%20IRC%20Meeting

If you have a specific topic we should talk about, reply here or bring
it up on IRC.


Best,
Robert

[DISCUSSION] nmo to the ASF

[Robert Kowalski]

Hi folks,

I wrote nmo (speaks: nemo) as part of COUCHDB-2598 and I would like to
donate nemo - a tool to manage CouchDB clusters officially to the ASF.

Website with a short video demoing the main functionality at [1] and
code at [2] - as I said I wrote it as part of COUCHDB-2598 [3] and
would love to donate it as a next step now that I have something that
can get a review and demoes the basic concept of the cli client.

Features:

 - define cluster inventories and manage the clusters by their name
 - if one or more node(s) is/are down, you have to use --force to join
nodes into a cluster
 - parseable json output with --json as commandline argument
 - next to the cli an api to write own custom scripts, websites, services
 - website with docs for every command (both docs for api, cli
versions of the commands - see right navigation on website [1])
 - manpages
 - 100% test coverage.

Upcoming features:

 - streaming imports from MongoDB and Postgres (the version with JSON
support) into CouchDB

Best,
Robert

[1] http://robertkowalski.github.io/nmo/
[2] https://github.com/robertkowalski/nmo
[3] https://issues.apache.org/jira/browse/COUCHDB-2598

[REMINDER] IRC meeting - 2015-05-27 18:00 UTC

[Robert Kowalski]

Hi all,

We'll be having the usual meeting in #couchdb-meeting on
irc.freenode.org at 18:00 UTC, Wednesday as usual.

The meeting room:

irc://irc.freenode.net/couchdb-meeting

Or you can access the meeting via the web:

http://webchat.freenode.net/?channels=#couchdb-meeting

For your local timezone:

http://arewemeetingyet.com/UTC/2015-05-27/18:00/CouchDB%20IRC%20Meeting

If you have a specific topic we should talk about, reply here or bring
it up on IRC.


Best,
Robert

GSoC Begins!

[Robert Kowalski]

Hi Dulanga, Hi Nadeeshaan,

we are quite excited as this GSoC begins!

Please join us in #couchdb-dev for ad-hoc questions, feel also free to
use the mailing list for asking questions or ask questions in your
GitHub PRs.

Best,
Robert

Re: [GitHub] couchdb-fauxton pull request: tests: run setup in parallel

[Robert Kowalski]

i will prepare an email to dev tomorrow when i am back at work

On Tue, May 26, 2015 at 12:24 AM, benkeen g...@git.apache.org wrote:
 Github user benkeen commented on the pull request:

 https://github.com/apache/couchdb-fauxton/pull/423#issuecomment-105326264

 Cool! I'm +1 for merging.


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

Re: [jira] [Closed] (COUCHDB-2700) multipart/related parsing broken when attachment contents change

[Robert Kowalski]

Nolan,

my Couch says:

```
[error] [0.561.0] Could not open file
/usr/local/var/lib/couchdb/test_attach_remote.couch: no such file or
directory
[info] [0.274.0] ::1 - - GET /test_attach_remote/?_nonce=1432515398129 404
[info] [0.503.0] ::1 - - PUT /test_attach_remote/ 201
[info] [0.507.0] ::1 - - GET
/test_attach_remote/_local/_pouch_dependentDbs?_nonce=1432515398208
404
[info] [0.517.0] ::1 - - DELETE /test_attach_remote/ 200
[error] [0.578.0] Could not open file
/usr/local/var/lib/couchdb/test_attach_remote.couch: no such file or
directory
[info] [0.518.0] ::1 - - GET /test_attach_remote/?_nonce=1432515398230 404
[info] [0.519.0] ::1 - - PUT /test_attach_remote/ 201
[info] [0.520.0] ::1 - - GET /?_nonce=1432515398309 200
[info] [0.523.0] ::1 - - GET
/test_attach_remote/_local/wM7iDnSu8mKpbzwHGB4uZg%3D%3D?_nonce=1432515398318
404
[info] [0.524.0] ::1 - - POST /test_attach_remote/_revs_diff 200
[info] [0.525.0] ::1 - - POST /test_attach_remote/_bulk_docs 201
[info] [0.527.0] ::1 - - GET
/test_attach_remote/_local/wM7iDnSu8mKpbzwHGB4uZg%3D%3D?_nonce=1432515398352
404
[info] [0.526.0] ::1 - - PUT
/test_attach_remote/_local/wM7iDnSu8mKpbzwHGB4uZg%3D%3D 201
[info] [0.528.0] ::1 - - GET
/test_attach_remote/bin_doc?_nonce=1432515398374 200
[info] [0.531.0] ::1 - - GET
/test_attach_remote/bin_doc/foo.txt?rev=2-8f82a9a5e7017a1e873227e8d9c093d9_nonce=1432515398380
200
[info] [0.532.0] ::1 - - GET
/test_attach_remote/bin_doc/bar.txt?rev=2-8f82a9a5e7017a1e873227e8d9c093d9_nonce=1432515398381
200
[info] [0.533.0] ::1 - - PUT /test_attach_remote/bin_doc 400
[info] [0.560.0] ::1 - - GET /test_attach_remote/?_nonce=1432515398406 200
[info] [0.564.0] ::1 - - GET
/test_attach_remote/_local/_pouch_dependentDbs?_nonce=1432515398414
404
[info] [0.574.0] ::1 - - DELETE /test_attach_remote/ 200
```

can you confirm this behaviour or did I do something wrong by running the tests?

On Mon, May 25, 2015 at 1:19 AM, Alexander Shorin (JIRA)
j...@apache.org wrote:

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

 Alexander Shorin closed COUCHDB-2700.
 -
 Resolution: Not A Problem

 The only place where this error may be raised in 
 [/db/_bulk_docs|https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_httpd_db.erl#L294-L295]
  endpoint which doesn't supports multipart requests.

 multipart/related parsing broken when attachment contents change
 

 Key: COUCHDB-2700
 URL: https://issues.apache.org/jira/browse/COUCHDB-2700
 Project: CouchDB
  Issue Type: Bug
  Security Level: public(Regular issues)
  Components: Database Core
Reporter: Nolan Lawson

 I can reliably reproduce a bug whereby CouchDB 1.6.1 throws this error:
 {code:javascript}
 {status:400,name:content_md5_mismatch,message:Missing JSON list of 
 'docs'}
 {code}
 Unfortunately this is a really complicated test case, so it's prohibitively 
 time-consuming for me to turn it into a set of CURL requests. Instead I've 
 made a branch in the PouchDB codebase to reproduce this.
 Steps:
 {code}
 git clone https://github.com/pouchdb/pouchdb.git --depth 1 --branch 
 3871-repro-for-couchdb
 cd pouchdb
 npm install
 npm run dev
 {code}
 Once the dev server is running (takes a few seconds to start), open the 
 following URL in Chrome:
 {code}
 http://localhost:8000/tests/integration/?grep=test.attachments.js-%20local%3Ahttp%20replication%20with%20changing%20attachments
 {code}
 The tests assume that you have a CouchDB running in admin party mode at 
 {{localhost:5984}}. If that's not the case, you can set the CouchDB host 
 like {{COUCH_HOST=http://path/to/couch:5984 npm run dev}}.
 You can see the PouchDB unit test itself [here | 
 https://github.com/pouchdb/pouchdb/blob/3871-repro-for-couchdb/tests/integration/test.attachments.js#L2215-L2267].
  It basically replicates a document between two databases several times, 
 while changing the contents of the attachment (but keeping the attachment 
 filename). Note that this test passes against PouchDB Server, where we are 
 using [node-multiparty | https://www.npmjs.com/package/multiparty] for 
 multipart parsing.
 In case it helps, I suspect the multipart parsing issue may also be related 
 to a point [~isaacs] raised [in the npm fullfat repo | 
 https://github.com/npm/npm-fullfat-registry/blob/2305c019740a7fd2f60fa1622842d6522a721b77/fullfat.js#L388-L390].
 Please also give me any insights into how to write a workaround for CouchDB 
 1.6, because I would still like to implement multipart support for older 
 versions of CouchDB.



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

Re: [jira] [Created] (COUCHDB-2698) Review BIS information

[Robert Kowalski]

Answered in LEGAL-181 that the question comes from us.

On Wed, May 20, 2015 at 5:04 AM, Henri Yandell (JIRA) j...@apache.org wrote:
 Henri Yandell created COUCHDB-2698:
 --

  Summary: Review BIS information
  Key: COUCHDB-2698
  URL: https://issues.apache.org/jira/browse/COUCHDB-2698
  Project: CouchDB
   Issue Type: Task
   Security Level: public (Regular issues)
 Reporter: Henri Yandell


 LEGAL-181 raised questions regarding BIS compliance for the CouchDB binary 
 build.

 Please review whether Erlang/OTP needs to be listed. I note that LEGAL-181 
 listed ibrowse, and that that is on the exports page.



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

Re: Few online documentation issues

[Robert Kowalski]

Hi Arun,

happy news! We migrated to git, please send your PR to
https://github.com/apache/couchdb-www

:)

On Sun, Mar 15, 2015 at 11:40 AM, Arun Agarwal
arun_...@yahoo.com.invalid wrote:
 Thanks much Robert.
 This should help. I will get into www@c.a.o.  as well.

 regards.Arun.



  On Sunday, March 15, 2015 3:57 AM, Robert Kowalski r...@kowalski.gd 
 wrote:


  Hi Arun,

 thanks so much for your efforts!

 I would really like to point you in the right direction to fix it
 right now, but we are currently migrating our website from svn to git
 (it is the reason why you have not found a way to fix it) :(

 Give us 2-3 weeks and I will ping you again on this mailing-list, with
 hopefully awesome news how you can contribute these fixes to CouchDB
 :)

 P.S.: feel free to join our website group at w...@couchdb.apache.org
 which got just created :)

 Best,
 Robert



 On Fri, Mar 13, 2015 at 7:46 PM, Arun Agarwal
 arun_...@yahoo.com.invalid wrote:
 Hi Dev team.
 I wanted to start contributing to CouchDB with few of the small, easy to 
 address issues.  While searching for pointers, I came across few 
 documentation typos which I thought worth sharing with you so that they can 
 be fixed when we get time.
 A. on http://couchdb.apache.org/developer-preview/2.0/
we have two   detailed instrucitons on how to get the prerequisits 
 set up. B. on http://couchdb.apache.org/   1.  we should remove the join the 
 erlang mailing list hyperlink to the same page: 
 http://couchdb.apache.org/#erlang-mailing-list
  the list is discontinued in favor of dev list and so the reference 
 won't make sense.2.  on my machine send a tweet link  is shown as : 
 http://couchdb.apache.org/twitter.com/CouchDB
  which won't work for end-users, I think this is happening because 
 of missing http:// in the hyperlink, which causes it to think its relative 
 to the same serving domain.
 I didn't find the above stuff checked-in to 
 https://github.com/apache/couchdb-documentation repo, else I would have sent 
 a review request. Let me know how can I help fixing these small problems in 
 documentation and will be happy to help.
 Let me know if there is another way of notifying such issues and will take 
 that path.
 Thanks much.
 regards.Arun Agarwal.

Re: How to get back to the screen some debug info from the compiled program ?

[Robert Kowalski]

Hi Martin,

 Whaw, I knew that dev/run was running 3 clusters at :

In fact they are three nodes that are joined into a cluster

Every node has still the old unclustered http interface from Couch
1.x, for dev/run we have

15984 - 16986
25984 - 26986
35984 - 36986

The code for the old CouchDB http api (nodes) is located at [1] - I
know that it is a bit confusing. The reason for it: historically
CouchDB 2.x originates from BigCouch. BigCouch was a forked version of
CouchDB with the Amazon Dynamo Paper applied _on top_ of the old plain
CouchDB.

In 2.x - on the clustered ports (15984, 25984, 35984) chttpd, rexi,
fabric  co are taking care that requests on the clustered interface
arrive at the node that is responsible for the requested part of the
db.

Changing the url is a good idea, but we will need to disable some
tests (some features are not available on the clustered interface -
e.g. compaction which just works on a per-node-level).

We would also need to change the suite (explicitly pass a write quorum
param of 3 to the requests (in case of the testsuite running against a
three nodes cluster). We would need to do that in order to get stable
tests as the cluster is just eventually consistent, meaning that per
default it will return an OK after a document was written to two of
our three nodes. That can lead to failing tests: Request A arrives at
Node1, the Document is written to 2 nodes, we receive an OK with 202
Accepted instead of 201 Created.

While the third Node(Node3) is still writing the document, our
testclient got the OK and fires the next request to test if our doc
was successfully written. We hit Node3 and get a document not found,
resulting in the testsuite to fail. We need to return every node in
the cluster under test to return our expected result to get a stable,
reliable testsuite, so we need to change the w-param (write quorum) to
n (number of nodes). An excellent presentation reagrding this topic is
[2]


[1] https://github.com/apache/couchdb-couch
[2] 
http://conf.couchdb.org/couchdb-conf-berlin-january-2013/slides/Introduction-to-BigCouch-CouchDB-Conf-Berlin-2013.pdf

On Mon, May 11, 2015 at 12:02 AM, Martin Lagrange
lagrangemar...@gmail.com wrote:
 Hey, Robert, thanks for your reply !

 Whaw, I knew that dev/run was running 3 clusters at :


- http://127.0.0.1:25984/
- http://127.0.0.1:35984/
- http://127.0.0.1:15984/

 but I didn't know that it was running another cluster at :

- http://localhost:15986/

 but I should have seen :
 https://github.com/apache/couchdb/blob/master/dev/run#L419

 Do you mean that the cluster 15986 is not served by the compiled app ? By
 what ? What do you mean exactly by
 are served by apache/couchdb-couch. ?

 There are some integration tests for chttpd in Erlang [3]


 Yes, indeed but there are not so many and not as convenient as the
 javascript tests :D


 - one idea

 for the future is to run the JS tests also against the cluster but it

 will need some further modifications of the  JS test suite.

 As a trivial approach, wouldn't it be enough to just say to couchJS command
 to run itself against the dev cluster ?
 There is this -u option to specify a uri file to run the test against.

 https://github.com/apache/couchdb/blob/master/test/javascript/run#L74


 Sorry in case I have misunderstood you.


 2015-05-10 21:13 GMT+02:00 Robert Kowalski r...@kowalski.gd:

 Hi Martin,

 see my responses inline

 On Sun, May 10, 2015 at 1:50 PM, Martin Lagrange
 lagrangemar...@gmail.com wrote:
  Hi everyone,
 
  I am currently working on solving an issue in the rewriting module that
  affect the rewrite process :
 
 https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_rewrite.erl
  and I have written some end-to-end regression tests :
 
 https://github.com/apache/couchdb/blob/master/test/javascript/tests/rewrite.js

 Wow cool!

  I modify the locally cloned couchdb-chttpd repository and compile the
  program again, then run the server and the tests again.
 
  make  dev/run --with-admin-party-please
  test/javascript/run test/javascript/tests/rewrite.js
 
 
  The thing is that I would like in someway to see what happen in the
 program
  during the execution, especially when this tests are running.
 
  I have written :
 
  io:format('blabla'),
 
 
  or
 
  couch_log:debug(blabla),
 
 
   in the erlang file but nothing seems to appear whether in the server
  console or in any logs.
 


 couchjs [1] runs against the old so-called backdoorports [2], which
 are served by apache/couchdb-couch. The cluster interface with the new
 public ports for the cluster are served by couchdb-chttpd - the
 part where you want t log.

 This means the JavaScript testsuite does not use code located in chttpd.

 There are some integration tests for chttpd in Erlang [3] - one idea
 for the future is to run the JS tests also against the cluster but it
 will need some further modifications of the  JS testsuite.


 [1] https://github.com/apache/couchdb/blob/master

Re: How to get back to the screen some debug info from the compiled program ?

[Robert Kowalski]

Hi Martin,

see my responses inline

On Sun, May 10, 2015 at 1:50 PM, Martin Lagrange
lagrangemar...@gmail.com wrote:
 Hi everyone,

 I am currently working on solving an issue in the rewriting module that
 affect the rewrite process :
 https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_rewrite.erl
 and I have written some end-to-end regression tests :
 https://github.com/apache/couchdb/blob/master/test/javascript/tests/rewrite.js

Wow cool!

 I modify the locally cloned couchdb-chttpd repository and compile the
 program again, then run the server and the tests again.

 make  dev/run --with-admin-party-please
 test/javascript/run test/javascript/tests/rewrite.js


 The thing is that I would like in someway to see what happen in the program
 during the execution, especially when this tests are running.

 I have written :

 io:format('blabla'),


 or

 couch_log:debug(blabla),


  in the erlang file but nothing seems to appear whether in the server
 console or in any logs.



couchjs [1] runs against the old so-called backdoorports [2], which
are served by apache/couchdb-couch. The cluster interface with the new
public ports for the cluster are served by couchdb-chttpd - the
part where you want t log.

This means the JavaScript testsuite does not use code located in chttpd.

There are some integration tests for chttpd in Erlang [3] - one idea
for the future is to run the JS tests also against the cluster but it
will need some further modifications of the  JS testsuite.


[1] https://github.com/apache/couchdb/blob/master/test/javascript/run#L27
[2] 
https://github.com/apache/couchdb-couch/blob/master/priv/couch_js/http.c#L363
[3] https://github.com/apache/couchdb-chttpd/blob/master/test/chttpd_db_test.erl

Re: Configuration in CouchDB 2.0

[Robert Kowalski]

Related: _config not being available on the front-cluster http
interface is also confusing - I did not expect that when making the PR
:(

See https://issues.apache.org/jira/browse/COUCHDB-2683

We will remove the config tab from Fauxton but everyone will try curl
if the tab is not in Fauxton anymore.

On Thu, Apr 23, 2015 at 7:48 PM, Alexander Shorin kxe...@gmail.com wrote:
 On Thu, Apr 23, 2015 at 8:42 PM, Robert Kowalski r...@kowalski.gd wrote:
 In fact I am reporting this issue right now in this thread. I also
 reported it yesterday in the meeting and was asked to write to the ML.

 It is not really a bug, like a runtime exception that I am reporting.
 The errors I describe are originating from the misuse of _config and
 the resulting issues look like bugs to users and cause a lot of
 confusion.


 I was hope to get some stacktraces and logs from you about these errors (;

 The intention of my mail is to get feedback on atomic config changes
 (e.g. a token ring). At least for me this issue is a blocker for Couch
 2.0 after my recent experiences where I had help a colleague.

 I'm not familiar with token-ring idea, but let's roll an
 implementation proposal, gather feedback, brainstorm it and make it
 real (:

 --
 ,,,^..^,,,

Re: Erlang course available at University of Kent

[Robert Kowalski]

Thank you Andy,

signed up! :)

On Wed, Apr 29, 2015 at 10:55 AM, Andy Wenk andyw...@apache.org wrote:
 Hi all,

 the University of Kent offers a free Erlang course:

 mini-MOOC on Functional Programming in Erlang from the University of Kent

 https://moodle.kent.ac.uk/external/course/view.php?id=237

 Maybe some of you are interested to join. It will start May 11th.

 Cheers

 Andy

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

[RESULT] accept Nano contribution (was: [VOTE] accept Nano contribution)

[Robert Kowalski]

Hi list,

the vote for nano passed:

+5 votes, no 0, no -1

Preparing the paperwork now.

Best,
Robert

Re: CouchDB web site awaits your pull requests!

[Robert Kowalski]

Finally! Awesome news!

On Thu, Apr 30, 2015 at 1:48 PM, Alexander Shorin kxe...@gmail.com wrote:
 Hi everyone!

 Yesterday, Daniel brought us the greatest news: gitwcsub was enabled
 on all ASF servers, what means that CouchDB website is now managed by
 git repository[1], not subversion one.

 If you had always wanted to contribute to CouchDB web site, but was
 always stopped by dealing with svn, now you have a more easiest way to
 contribute your ideas and submit bug/typo fixes. We are waiting for
 yours pull requests[2]!

 Also, if you want to discuss site-related stuff, please subscribe to
 w...@couchdb-apache.org mailing list. Everyone welcome!

 P.S. Don't forget to switch default branch to asf-site, since from
 there the web site is being served.

 [1]: https://git-wip-us.apache.org/repos/asf?p=couchdb-www.git
 [2]: https://github.com/apache/couchdb-www/pulls

 --
 ,,,^..^,,,

Re: [COUCHDB-2214] Dashboard as main page

[Robert Kowalski]

Hi Dulanga, Hi Nadeeshaan,

welcome! :)

Michelle, Ben and me will mentor this summer. And the community
bonding period just started!

We will help you regarding the design of your widgets and revision
browser and we will try to provide feedback on your code on a daily
basis - that means that we either will comment on your branch on
GitHub or an open PR on a daily basis.

You might already know that writing unit and integration tests is an
absolute must for getting code merged into master.

The goal is to make small steps in an iterative way and get the MVP
merged as soon as possible. After that we will iterate and can add
more features. This ensures we have first results our users can make
use of very early in the process and don't have to throw all code away
if we run out of time.


Please use the time to learn more about Apache CouchDB, read:

- http://couchdb.apache.org/bylaws.html
- http://couchdb.apache.org/conduct.html

We will invite you to our Fauxton standup next week or the following
one, I will contact you a few days before. It is 16:00 (Berlin
Timezone) on Google Hangouts.

Best,
Robert

On Tue, Apr 28, 2015 at 6:03 AM, Dulanga Sashika wadsash...@gmail.com wrote:
 Dear all,

 Thank you very much for supporting me to achieve this success in GSoC 2015.
 I will not get accepted for GSoC 2015 without all your great help. Special
 thanks should go to Robert and Alexander who guide me really well and help
 me to understand the project and create a good proposal for the project.

 Looking forward to start the project and working with you all. Thank you
 very much again.


 Thank you

 On Sun, Apr 5, 2015 at 11:08 AM, Dulanga Sashika wadsash...@gmail.com
 wrote:

 Problem solved :) thank you very much for the help Robert.

 On Sat, Apr 4, 2015 at 11:54 PM, Robert Kowalski r...@kowalski.gd wrote:

 Hi Dulanga,

 Given you named your module `documents` you must have your main less
 file for the module in `assets/less` and name it `documents.less`.

 Example:
 https://github.com/apache/couchdb-fauxton/blob/master/app/addons/documents/assets/less/documents.less

 On Sat, Apr 4, 2015 at 7:54 PM, Dulanga Sashika wadsash...@gmail.com
 wrote:
  Hi Robert,
 
  By following given links and playing around with the code, I could
  successfully implement a react component and display a text in the
  dashboard. I added a new dashboard.less file to apply styles for that.
 But
  it didn't work. Is there any configurations to do before using those
 less
  files for the styles? As a next step, I am hoping to implement some
 complex
  components. Specially, some movable items with add and remove features
 as
  Alex suggested.
 
  Best Regards
 
  On Sat, Mar 28, 2015 at 12:49 AM, Dulanga Sashika wadsash...@gmail.com
 
  wrote:
 
  Thank you very much for your valuable ideas Alex. As we discussed in
  IRC, I will move into implementing basic structure of the dashboard
  rather than bothering about widget design. After doing that, we can go
  into widgets.
 
  Cheers
 
  On 3/27/15, Alexander Shorin kxe...@gmail.com wrote:
   On Sat, Mar 21, 2015 at 11:00 PM, Dulanga Sashika 
 wadsash...@gmail.com
   wrote:
   https://www.dropbox.com/s/n1q4whsd460neil/Dashboard_mockup.png?dl=0
  
   http://i.imgur.com/FFiIpbv.png
  
   1. Widgets customization button shouldn't consume so much valuable
 space.
   2. These buttons are duplicates sidebar menu items without giving any
   benefits.
   3. 10 active replication are cool, but which are there? I to get this
   I need to click more which isn't much different from click on Active
   Tasks sidebar menu item and select filter by replication tasks.
   Dashboard should just works and not require any actions from use
 side.
   If user click on widget and leaves it - dashboard main goal is
 failed.
   4. Active tasks are already running (: There couldn't be active
   stopped ones. Also, here you can show active replications and add
 some
   filter. Yes, it will duplicate an active tasks page at some points,
   but the difference is in short summary of the recent activity shaped
   into compact form.
   5. Recently visited databases cool, but are they be only 4? May be 10
   or 20? How about search field to filter this list as well?
   6. Again button that leads to some other page. Why not just a simple
   list users and a form to search and register new ones?
   7. Same problem. Why not a form to instantly run a replication? If it
   will be a replication widget, it could also steal a part of features
   from active tasks widget to show only replications.
  
   --
   ,,,^..^,,,
  
 
 
  --
  W. A. Dulanga Sashika,
  Undergraduate Student,
  Department of Computer Science and Engineering,
  University of Moratuwa.
 
 
 
 
  --
  W. A. Dulanga Sashika,
  Undergraduate Student,
  Department of Computer Science and Engineering,
  University of Moratuwa.




 --
 W. A. Dulanga Sashika,
 Undergraduate Student,
 Department of Computer Science and Engineering,
 University of Moratuwa.




 --
 W

[VOTE] accept Nano contribution

[Robert Kowalski]

Hi list,

Nuno Job wants to contribute Nano, a popular Node.js Client library
for CouchDB to the ASF. The project has one main contributor which
would like to work further on Nano as part of the ASF (main discussion
at 
http://mail-archives.apache.org/mod_mbox/couchdb-dev/201501.mbox/%3ccakuqv0mtixmfcj-zv+khdjogaex7zhs0n7-gtbjabqc6eax...@mail.gmail.com%3E
)

The main repository is located at https://github.com/dscape/nano and
we are voting on
https://github.com/dscape/nano/tree/d692654771031c24eb995d760159eee41b4ebafd

We don't have a match for votings on code contributions in our bylaws,
so I am chosing Majority Approval by the PMC (that is, 3 +1’s and no
-1’s) and a 72 hour voting period beginning now (like the BigCouch
vote in August)


Best,
Robert

Re: [VOTE] accept Nano contribution

[Robert Kowalski]

+1

On Wed, Apr 29, 2015 at 2:12 PM, Alexander Shorin kxe...@gmail.com wrote:
 +1
 --
 ,,,^..^,,,


 On Wed, Apr 29, 2015 at 3:07 PM, Robert Kowalski r...@kowalski.gd wrote:
 Hi list,

 Nuno Job wants to contribute Nano, a popular Node.js Client library
 for CouchDB to the ASF. The project has one main contributor which
 would like to work further on Nano as part of the ASF (main discussion
 at 
 http://mail-archives.apache.org/mod_mbox/couchdb-dev/201501.mbox/%3ccakuqv0mtixmfcj-zv+khdjogaex7zhs0n7-gtbjabqc6eax...@mail.gmail.com%3E
 )

 The main repository is located at https://github.com/dscape/nano and
 we are voting on
 https://github.com/dscape/nano/tree/d692654771031c24eb995d760159eee41b4ebafd

 We don't have a match for votings on code contributions in our bylaws,
 so I am chosing Majority Approval by the PMC (that is, 3 +1’s and no
 -1’s) and a 72 hour voting period beginning now (like the BigCouch
 vote in August)


 Best,
 Robert

[ANNOUNCE] Maria Andersson elected as CouchDB committer

[Robert Kowalski]

Dear community,

I am pleased to announce that the CouchDB Project Management Committee
has elected Maria Andersson as a CouchDB committer.

Apache ID: mia

IRC nick: mar-ia

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 Maria'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 Maria!

On behalf of the CouchDB PMC,

Robert

[jira] [Commented] (COUCHDB-1787) Automate release process documentation

[Robert Kowalski (JIRA)]

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

Robert Kowalski commented on COUCHDB-1787:
--

Hi Amarnath,

I'm sorry that you feel disappointed. Sadly every project (e.g.
CouchDB) just has limited resources regarding possible mentors.
Additionally there is just a limited amount of seats for students in
the whole Apache Foundation.

CouchDB got a lot really good proposals this year, far more than we
have mentors.

I also want to point out that submitting a proposal is not a guarantee
that the proposal gets accepted.

Maybe we can work together next year on a project

All the best,
Robert

On Mon, Apr 27, 2015 at 9:21 PM, Amarnath Beedimane Hanumantharaya


 Automate release process documentation
 --

 Key: COUCHDB-1787
 URL: https://issues.apache.org/jira/browse/COUCHDB-1787
 Project: CouchDB
  Issue Type: Improvement
  Components: Build System, Documentation
Reporter: Dave Cottlehuber
  Labels: gsoc, gsoc2015, mentor

 The release process today contains a large number of manual transformation 
 steps.
 Fixing this will make the release process significantly easier for release 
 managers, as well as less error-prone.
 Ideally the output formats (NEWS, CHANGES in source tree, and HTML snippets 
 for http://couchdb.org/ website and http://blogs.apache.org/couchdb ) can be 
 auto-generated from either the .rst files in share/doc/src using sphinx's 
 .versionaddded/changed tags, or potentially from commit messages if this is 
 appropriate.
 CouchDB documentation is generated today from restructured text using python 
 code, and rolled into the release documentation during `make distcheck`.



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

Configuration in CouchDB 2.0

[Robert Kowalski]

Hi there,

I mentioned the topic yesterday night during the CouchDB meeting:

I started working on a PR [1] which hides the config tab in Faxuton if
Fauxton runs on the front-ports of the cluster as a result of the
discussion in COUCHDB-2390 [2].  It works, no config on the front
ports (also not with curl, as we removed the route from chttpd)

:)

The Fauxton team is using CouchDB 2.0. Some team-members started to
test features on the backdoor ports which still serve the `_config`
route.

This lead to bad errors a few workdays later which were hard to
diagnose - it was not obvious to our team why Couch is broken at all
and how to solve that issue.

My team works on a daily basis with and for CouchDB - this is why I am
quite worried about our users who just want to use CouchDB.

Yesterday I thought which possibilities we have to avoid such scenarios:

A solution could be to also deactivate _config on the backdoor-ports.
But users can still make changes to the config-ini-files which are on
each node. And if we take away the config files, CouchDB is not
configurable any more.

At the last CouchDB Meetup Hamburg we discussed a token ring [1] for
configurations. This is neat but needs some work in the Erlang core.

I think there are a ton of other possible solutions.

For me the config is still a major issue after that experience. What
do you think?


[1] https://github.com/apache/couchdb-fauxton/pull/360
[2] https://issues.apache.org/jira/browse/COUCHDB-2390
[3] https://www.sics.se/~ali/teaching/ds/ds-token.pdf

Re: Configuration in CouchDB 2.0

[Robert Kowalski]

Hi Alex,

not sure if I was telling the story the right way. See my responses inline.

On Thu, Apr 23, 2015 at 6:10 PM, Alexander Shorin kxe...@gmail.com wrote:
 Hi Robert,

 On Thu, Apr 23, 2015 at 6:53 PM, Robert Kowalski r...@kowalski.gd wrote:

 This lead to bad errors a few workdays later which were hard to
 diagnose - it was not obvious to our team why Couch is broken at all
 and how to solve that issue.

 My team works on a daily basis with and for CouchDB - this is why I am
 quite worried about our users who just want to use CouchDB.


 I'm curious how did you figure on which (cluster/local) interface
 Fauxton is get served and why do you expect any errors? Just because
 for me, here logic is pretty trivial:
 HEAD /_config - 200 OK - render a button
   - 40x - don't render a button


I solved it exactly like that but that is not the point of my post. I
don't want to discuss implementation details of Fauxton, it is just
the introduction to my mail (as I thought the config problem was
solved with that solution until yesterday).

I am trying to tell the story of my team which is even working on
CouchDB on a daily basis. That means they know more about CouchDB than
new users and also even more than advanced users.

They used the backdoor config and got errors they never expected and
knew of. I am not sure if that is an user-experience we want to ship,
especially to folks which are new to CouchDB and want to try it out.

 This request need to make once when Fauxton loads first time and once
 again when user get login/logout - there is no point to show buttons
 for users which they cannot click.

 Yesterday I thought which possibilities we have to avoid such scenarios:

 A solution could be to also deactivate _config on the backdoor-ports.
 But users can still make changes to the config-ini-files which are on
 each node. And if we take away the config files, CouchDB is not
 configurable any more.

 At the last CouchDB Meetup Hamburg we discussed a token ring [1] for
 configurations. This is neat but needs some work in the Erlang core.

 I think there are a ton of other possible solutions.

 For me the config is still a major issue after that experience. What
 do you think?

 Deactivation /_config may be harmful, since you completely loose to
 configure node without restart. That's not cool at all.

 Remove Config button from Fauxton at all may be quick and dirty fix
 (if you suffers from weird random errors there), but this reduces UX.
 However, without _config on cluster/public interface it's already hurt
 a lot.


My story is meant as a real life example from folks that used the
_config endpoint on the backdoor ports on a three node cluster. This
could be done using curl, changing the ini file or Fauxton. The story
I try to tell is that folks will use those ports without knowing what
will happen, get horrible errors that look like random errors (because
of the loadbalancer) and the get disappointed from Couch. At least I
would as a user.

 Long-term and good solution is, obliviously, make /_config works on
 cluster interface, there is no doubt. I even would like to take this
 task and would be glad if some core developer will mentor me on
 implementation idea and on the very first steps.

 --
 ,,,^..^,,,

Cool!

Re: Configuration in CouchDB 2.0

[Robert Kowalski]

In fact I am reporting this issue right now in this thread. I also
reported it yesterday in the meeting and was asked to write to the ML.

It is not really a bug, like a runtime exception that I am reporting.
The errors I describe are originating from the misuse of _config and
the resulting issues look like bugs to users and cause a lot of
confusion.

The intention of my mail is to get feedback on atomic config changes
(e.g. a token ring). At least for me this issue is a blocker for Couch
2.0 after my recent experiences where I had help a colleague.

On Thu, Apr 23, 2015 at 7:11 PM, Alexander Shorin kxe...@gmail.com wrote:
 Well, summarizing your story, if you got such random and horrible
 errors, why not to report them? Sure, everything could and should be
 fixed (: But things cannot be fixed if nobody known that they are
 broken.
 Here you a poster about: http://i.imgur.com/UqIzZZH.jpg
 --
 ,,,^..^,,,


 On Thu, Apr 23, 2015 at 8:04 PM, Robert Kowalski r...@kowalski.gd wrote:
 Hi Alex,

 not sure if I was telling the story the right way. See my responses inline.

 On Thu, Apr 23, 2015 at 6:10 PM, Alexander Shorin kxe...@gmail.com wrote:
 Hi Robert,

 On Thu, Apr 23, 2015 at 6:53 PM, Robert Kowalski r...@kowalski.gd wrote:

 This lead to bad errors a few workdays later which were hard to
 diagnose - it was not obvious to our team why Couch is broken at all
 and how to solve that issue.

 My team works on a daily basis with and for CouchDB - this is why I am
 quite worried about our users who just want to use CouchDB.


 I'm curious how did you figure on which (cluster/local) interface
 Fauxton is get served and why do you expect any errors? Just because
 for me, here logic is pretty trivial:
 HEAD /_config - 200 OK - render a button
   - 40x - don't render a button


 I solved it exactly like that but that is not the point of my post. I
 don't want to discuss implementation details of Fauxton, it is just
 the introduction to my mail (as I thought the config problem was
 solved with that solution until yesterday).

 I am trying to tell the story of my team which is even working on
 CouchDB on a daily basis. That means they know more about CouchDB than
 new users and also even more than advanced users.

 They used the backdoor config and got errors they never expected and
 knew of. I am not sure if that is an user-experience we want to ship,
 especially to folks which are new to CouchDB and want to try it out.

 This request need to make once when Fauxton loads first time and once
 again when user get login/logout - there is no point to show buttons
 for users which they cannot click.

 Yesterday I thought which possibilities we have to avoid such scenarios:

 A solution could be to also deactivate _config on the backdoor-ports.
 But users can still make changes to the config-ini-files which are on
 each node. And if we take away the config files, CouchDB is not
 configurable any more.

 At the last CouchDB Meetup Hamburg we discussed a token ring [1] for
 configurations. This is neat but needs some work in the Erlang core.

 I think there are a ton of other possible solutions.

 For me the config is still a major issue after that experience. What
 do you think?

 Deactivation /_config may be harmful, since you completely loose to
 configure node without restart. That's not cool at all.

 Remove Config button from Fauxton at all may be quick and dirty fix
 (if you suffers from weird random errors there), but this reduces UX.
 However, without _config on cluster/public interface it's already hurt
 a lot.


 My story is meant as a real life example from folks that used the
 _config endpoint on the backdoor ports on a three node cluster. This
 could be done using curl, changing the ini file or Fauxton. The story
 I try to tell is that folks will use those ports without knowing what
 will happen, get horrible errors that look like random errors (because
 of the loadbalancer) and the get disappointed from Couch. At least I
 would as a user.

 Long-term and good solution is, obliviously, make /_config works on
 cluster interface, there is no doubt. I even would like to take this
 task and would be glad if some core developer will mentor me on
 implementation idea and on the very first steps.

 --
 ,,,^..^,,,

 Cool!

[RESULT] Logo vote (was: Re: [VOTE] CouchDB Logo - Round #3)

[Robert Kowalski]

Hi folks,

thanks for every who participated in the vote. A short update
regarding our logo vote, the three logos with the most points are:

Constantin Angheloiu:15.5
Paul Davis:   9.5
Old CouchDb Logo:  2

We will discuss the new logo now in the PMC and will keep you posted.

The whole vote results as CSV: https://paste.apache.org/gRTT

Thank you,
Robert

Re: [GitHub] couchdb-fauxton pull request: Databases view in react

[Robert Kowalski]

i would like to take garren a second look as the pr is fairly large

On Mon, Apr 20, 2015 at 11:12 PM, sebastianrothbucher
g...@git.apache.org wrote:
 Github user sebastianrothbucher commented on the pull request:

 https://github.com/apache/couchdb-fauxton/pull/370#issuecomment-94569550

 OK, did the last comment also - you think this is OK now?


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

[REMINDER] Weekly IRC meeting, Wednesday 2015-04-22 at 20:00 GMT

[Robert Kowalski]

Dear community,

Please join our weekly IRC meeting, Wednesday 2015-04-22 at 20:00 GMT.

Everyone is welcome to attend this meeting.

If you have anything to put on the agenda, please reply to this email
or mention it at the start of the meeting.

The meeting will take place in:
irc://irc.freenode.net/couchdb-meeting

You can access the meeting via the web:
http://webchat.freenode.net/?channels=#couchdb-meeting

For your local time, see:
http://everytimezone.com/

Thanks,
Robert

[jira] [Created] (COUCHDB-2663) w:2 property in index docs

[Robert Kowalski (JIRA)]

Robert Kowalski created COUCHDB-2663:


 Summary: w:2 property in index docs
 Key: COUCHDB-2663
 URL: https://issues.apache.org/jira/browse/COUCHDB-2663
 Project: CouchDB
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Mango
Reporter: Robert Kowalski


Noticed that the write quorum is saved into the indexes by mango:

{code}
{
  _id: _design/e4d338e5d6f047749f5399ab998b4fa04ba0c816,
  _rev: 1-1f37105891681e717ae37dae973bc6a4,
  language: query,
  views: {
e4d338e5d6f047749f5399ab998b4fa04ba0c816: {
  map: {
fields: {
  _id: asc
}
  },
  reduce: _count,
  options: {
def: {
  fields: [
_id
  ]
},
w: 2
  }
}
  }
}
{code}

Can we remove it?



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

[jira] [Commented] (COUCHDB-2237) Add a 'live' sugar for 'continuous'

[Robert Kowalski (JIRA)]

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

Robert Kowalski commented on COUCHDB-2237:
--

hey, let's mark it as unstable (level 0) and let's see how 2.x goes.

if hell explodes i am happy to remove it in 3.0 or 4.0 or even 5.0 if it was 
not raised to a stable (non-experimental-level) so far. i will even write the 
docs mentioning it is unstable.

everyone ok testing that?

 Add a 'live' sugar for 'continuous'
 ---

 Key: COUCHDB-2237
 URL: https://issues.apache.org/jira/browse/COUCHDB-2237
 Project: CouchDB
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: HTTP Interface
Reporter: Dale Harvey

 With PouchDB we generally try to stick to the same param names as Couch, we 
 are even changing some we implemented first to be compatible 
 (https://github.com/pouchdb/pouchdb/issues/2193)
 However 'continuous' sucks to type, its confusing to type and spell and 
 everyone gets it wrong, we still support it but switched to documenting it as 
 'live' and life is awesome again



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