[GitHub] couchdb-fauxton pull request: Fix Views toggle with dot symbol in ...

[michellephung]

GitHub user michellephung opened a pull request:

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

Fix Views toggle with dot symbol in ddoc name



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

$ git pull https://github.com/michellephung/couchdb-fauxton 
Fix-views-toggle-with-dot-symbol-in-designdocname

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

https://github.com/apache/couchdb-fauxton/pull/319.patch

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

This closes #319


commit ad7215c6565a15507ab49153838f3e1cacd1e9ab
Author: michelleph...@gmail.com 
Date:   2015-03-17T02:11:41Z

Fix Views toggle with dot symbol in ddoc name




---
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: GSoc 2015 | COUCHDB-1743 Make the view server & protocol faster

[Buddhika Jayawardhana]

Dear Jan,
Thank you for the detailed reply. I will go through the links you have sent
me. Of course I will have much more questions. Though I'm not familiar with
JIRA I think taking this to JIRA would help to manage the project easily(I
have only used JIRA once for ask about CloudStack project before I notice
CouchDB project). Please take this to JIRA let me know.

Thanks again.

On 17 March 2015 at 02:58, Jan Lehnardt  wrote:

> Dear Buddhika,
>
> thank you for your interest in CouchDB and the CouchDB View Server!
>
> This is an area where you can make significant contributions to CouchDB.
>
> It is also a little bit involved, but you seem to have all the skills
> required to pull this off :)
>
> I’m happy to mentor you.
> > On 16 Mar 2015, at 10:03, Buddhika Jayawardhana <
> buddhika.anus...@gmail.com> wrote:
> >
> > Hi,
> > I am an Undergraduate of Department of Computer Science and Engineering
> > University of Moratuwa. I have been subscribed to couchdb mailing list
> > since months and I have been trying to learn some Erlang to work with
> > couchdb. I noticed project  "COUCHDB-1743 Make the view server & protocol
> > faster" is related to GSoC. I am willing to submit a project proposal for
> > this project.
> >
> > I have theoretical knowledge in software process, design patterns, and
> > other Engineering concepts. I've been using 'java', 'C++' for high-level
> > programming and 'C', a little bit of assembly for low-level programming
> and
> > PHP and JavaScript  for web development. Also I have sound knowledge  on
> > Erlang. I would be much thankful if you can guide to get familiar with
> the
> > project as soon as possible.
> >
> > Here are the problems in my mind
> >
> >   - Are the other programming languages that I should get familiar with?
>
> Erlang and JavaScript will do, some knowledge of C to understand the
> current system will help.
>
>
> >   - What are the technologies I should get familiar with?
>
> General knowledge of Unix/POSIX fundamentals (processes, fds, stdio etc.)
> will be required. Windows equivalent APIs too (but not strictly a
> requirement just yet).
>
>
> >   - I can work 40 hours per week for the project. Would that be enough to
> >   successfully complete the project?
>
> I can’t estimate whether you’d be able to complete this 100%, but I’m sure
> that this enough time to make a significant contribution, that the
> community then can take and finish up, should you not get to the end. E.g.
> don’t worry too much about this :)
>
>
> >   - What are the other resources that I should read before submitting the
> >   proposal?
>
> Familiarity with the CouchDB source can’t hurt. More in-depth knowledge of
> Erlang as well, http://learnyousomeerlang.com is a great free resource and
> the main Erlang docs are worth a read, as well. As are the various print
> books that are available from various publishers.
>
> It will definitely also help to read through the CouchDB Guide:
> http://guide.couchdb.org
>
> Although some parts have already been integrated into
> http://docs.couchdb.org,
> which you should also read, especially the bits about Design Documents,
> Views
> and List, Show, Validation, Filter and Update functions.
>
> In addition, check out the query_server_spec, it codifies the current query
> server protocol:
>
>
> https://github.com/apache/couchdb/blob/master/test/view_server/query_server_spec.rb
>
>
> > Hope you will guide me through the project.
>
> Again, thanks for taking an interest in this! :)
>
> To get things rolling, here’s my rough idea for how this could play out:
>
> Generally, there are three components, the Erlang and the JavaScript part
> and the JavaScript runtime or couchjs.
>
> We call all these things Query Server or View Server.
>
> The Erlang part lives in https://github.com/apache/couchdb-couch-mrview
>
> The JavaScript part lives in
> https://github.com/apache/couchdb/tree/master/share/server
>
> The current JavaScript runtime is Spidermonkey. We have our own C-wrapper
> around Spidermonkey, to make it a CLI tool that talks stdio:
>
>   https://github.com/apache/couchdb-couch/tree/master/priv/couch_js
>
>
> We’d generally like to move away from the custom C-wrapped Spidermonkey and
> have V8 be the execution engine. We also like to get away from having to
> maintain C/C++. It’d probably be simplest to use Node.js as a wrapper,
> because then many more people can contribute to this. Also, Node.js is good
> at streaming protocols, so it is a natural fit.
>
>
> Here is how I would start:
>
> 1. Create a new Query Server that *only* handles Show, List, Filter,
> Validation
>and Update functions as that is a lot simpler on both the Erlang and
>JavaScript side.
>
> 2. As part of 1: Design a new Query Server protocol that works in a
> streaming
>fashion. The current one is request/response based and both sides are
> waiting
>for one another while one of them is doing actual work. It’d be nice if
> both
>could just keep working on 

[GitHub] couchdb-mem3 pull request: change readme for the couchdb project

[robertkowalski]

Github user robertkowalski commented on the pull request:

https://github.com/apache/couchdb-mem3/pull/8#issuecomment-81991755
  
merged as fb5f56c21a9d855c1eff2e1fdadadd940213bffe and 
f62d43836972b2317784c397e69082a0850d74f4


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

[GitHub] couchdb-mem3 pull request: change readme for the couchdb project

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/couchdb-mem3/pull/8


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

[GitHub] couchdb-mem3 pull request: change readme for the couchdb project

[kxepal]

Github user kxepal commented on the pull request:

https://github.com/apache/couchdb-mem3/pull/8#issuecomment-81990105
  
LGFM


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

[GitHub] couchdb-admin pull request: remove board report

[robertkowalski]

GitHub user robertkowalski opened a pull request:

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

remove board report

got superfluous by the new website tool

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

$ git pull https://github.com/robertkowalski/couchdb-admin superfluous

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

https://github.com/apache/couchdb-admin/pull/3.patch

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

This closes #3


commit c13c4271d85e83d9d9ffcd990cdc80332d790cae
Author: Robert Kowalski 
Date:   2015-03-16T22:33:47Z

remove board report

got superfluous by the new website tool




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

[GitHub] couchdb-mem3 pull request: change readme for the couchdb project

[robertkowalski]

Github user robertkowalski commented on the pull request:

https://github.com/apache/couchdb-mem3/pull/8#issuecomment-81966516
  
ok second try :)


---
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: [PROPOSAL] Move transactional email out of dev@

[Sebastian Rothbucher]

+1 with Joan and Alexander also, i.e. do a monthly thing instead of
blasting out dozens a day to dev@ => this is great, thanks for bringing it
up!   Sebastian

On Mon, Mar 16, 2015 at 6:42 PM, Alexander Shorin  wrote:

> On Mon, Mar 16, 2015 at 7:46 PM, Joan Touzet  wrote:
> > I'd be in support of an automated email monthly to dev@ that reminds
> > people where to go to look for GH PRs, JIRA ticket updates, etc.
>
> Good idea btw. +1
>
> --
> ,,,^..^,,,
>

[GitHub] couchdb-fauxton pull request: Call JSX build in a way that works o...

[sebastianrothbucher]

Github user sebastianrothbucher commented on the pull request:

https://github.com/apache/couchdb-fauxton/pull/318#issuecomment-81960968
  
OK, I removed the rm and re-tested (delete a .react.js and redo grunt dev) 
on both mingw32 and the good old cmd.exe => both work. 
I'll wait for travis' verdict and then merge. At the latest 2morrow during 
Hamburg Couch meetup ;-)
Thanks!   Sebastian


---
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: GSoc 2015 | COUCHDB-1743 Make the view server & protocol faster

[Jan Lehnardt]

Dear Buddhika,

thank you for your interest in CouchDB and the CouchDB View Server!

This is an area where you can make significant contributions to CouchDB.

It is also a little bit involved, but you seem to have all the skills
required to pull this off :)

I’m happy to mentor you.
> On 16 Mar 2015, at 10:03, Buddhika Jayawardhana  
> wrote:
> 
> Hi,
> I am an Undergraduate of Department of Computer Science and Engineering
> University of Moratuwa. I have been subscribed to couchdb mailing list
> since months and I have been trying to learn some Erlang to work with
> couchdb. I noticed project  "COUCHDB-1743 Make the view server & protocol
> faster" is related to GSoC. I am willing to submit a project proposal for
> this project.
> 
> I have theoretical knowledge in software process, design patterns, and
> other Engineering concepts. I've been using 'java', 'C++' for high-level
> programming and 'C', a little bit of assembly for low-level programming and
> PHP and JavaScript  for web development. Also I have sound knowledge  on
> Erlang. I would be much thankful if you can guide to get familiar with the
> project as soon as possible.
> 
> Here are the problems in my mind
> 
>   - Are the other programming languages that I should get familiar with?

Erlang and JavaScript will do, some knowledge of C to understand the
current system will help.


>   - What are the technologies I should get familiar with?

General knowledge of Unix/POSIX fundamentals (processes, fds, stdio etc.)
will be required. Windows equivalent APIs too (but not strictly a
requirement just yet).


>   - I can work 40 hours per week for the project. Would that be enough to
>   successfully complete the project?

I can’t estimate whether you’d be able to complete this 100%, but I’m sure
that this enough time to make a significant contribution, that the 
community then can take and finish up, should you not get to the end. E.g.
don’t worry too much about this :)


>   - What are the other resources that I should read before submitting the
>   proposal?

Familiarity with the CouchDB source can’t hurt. More in-depth knowledge of
Erlang as well, http://learnyousomeerlang.com is a great free resource and
the main Erlang docs are worth a read, as well. As are the various print
books that are available from various publishers.

It will definitely also help to read through the CouchDB Guide: 
http://guide.couchdb.org

Although some parts have already been integrated into http://docs.couchdb.org,
which you should also read, especially the bits about Design Documents, Views
and List, Show, Validation, Filter and Update functions.

In addition, check out the query_server_spec, it codifies the current query
server protocol:

https://github.com/apache/couchdb/blob/master/test/view_server/query_server_spec.rb


> Hope you will guide me through the project.

Again, thanks for taking an interest in this! :)

To get things rolling, here’s my rough idea for how this could play out:

Generally, there are three components, the Erlang and the JavaScript part
and the JavaScript runtime or couchjs.

We call all these things Query Server or View Server.

The Erlang part lives in https://github.com/apache/couchdb-couch-mrview

The JavaScript part lives in 
https://github.com/apache/couchdb/tree/master/share/server

The current JavaScript runtime is Spidermonkey. We have our own C-wrapper
around Spidermonkey, to make it a CLI tool that talks stdio:

  https://github.com/apache/couchdb-couch/tree/master/priv/couch_js


We’d generally like to move away from the custom C-wrapped Spidermonkey and
have V8 be the execution engine. We also like to get away from having to
maintain C/C++. It’d probably be simplest to use Node.js as a wrapper,
because then many more people can contribute to this. Also, Node.js is good
at streaming protocols, so it is a natural fit.


Here is how I would start:

1. Create a new Query Server that *only* handles Show, List, Filter, Validation
   and Update functions as that is a lot simpler on both the Erlang and
   JavaScript side.

2. As part of 1: Design a new Query Server protocol that works in a streaming
   fashion. The current one is request/response based and both sides are waiting
   for one another while one of them is doing actual work. It’d be nice if both
   could just keep working on whatever they need to do.

3. Once 1. and 2. are in place and working correctly, expand the new Query 
Server
   to also handle Views. At this point, adding view support should not be too
   complicated anymore.


Things to watch out for:

- map/reduce functions for CouchDB views need to be “pure”, e.g. we need to 
guarantee
  they stay the same unless CouchDB can see any changes (and then invalidate 
the view
  index). This means we need some extra isolation of the JS execution. And some
  limitation or observation of the require() system.

  There is a project that demonstrated we can do this. Jason Smith has run this,
  but I can’t seem to find it 

[GitHub] couchdb-fauxton pull request: Fix couchapp_deploy

[garrensmith]

Github user garrensmith commented on the pull request:

https://github.com/apache/couchdb-fauxton/pull/316#issuecomment-81904801
  
I will quickly test it tomorrow and let you know. 

All misspelling thanks to my iPhone

> On 16 Mar 2015, at 8:11 PM, Alexander Shorin  
wrote:
> 
> @garrensmith @robertkowalski 
> no problem if I merge this?
> 
> —
> Reply to this email directly or view it on GitHub.
> 



---
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: GSOC 2015 [Visualize document revision tree and navigate between these revisions]

[Nadeeshaan Gunasinghe]

Hi all,
I went through the currently available revision tree at
https://github.com/neojski/visualizeRevTree. If we can take in to account
this idea, we can write a module for fauxton allowing future extending
abilities as well as customization abilities. If we can initiate the
component at this stage and get this to the community I am sure more people
will contribute and we can have more ideas. So as the first step we can
make a working revision tree visualizing component and during the
implementation procedure we can keep track of the new ideas about the
additional features.

TO DO status:
-  read the primers on revisions, conflicts and versioning --- *Done*
 - do the react.js tutorial and read the flux article - *Flux in
Progress*
 - try to answer the questions regarding pros/cons of using the existing
revision tree visualizer vs creating one on our own  *Done*
 - try out the old feature in futon  *Done*
 - if time left: take a look at the Fauxton code, this commit shows
how we refactored an old backbone component to a React one using the
Flux pattern (Stores, Actions, Components) - *Pending*

On Mon, Mar 16, 2015 at 2:31 AM, Sebastian Rothbucher <
sebastianrothbuc...@googlemail.com> wrote:

> Hi guys,
> you might check out
> http://atypical.net/archive/2014/02/04/my-couchdb-conf-talk - esp. slide
> 18...
> Good luck
> Sebastian
>
> On Sun, Mar 15, 2015 at 9:25 PM, Robert Kowalski  wrote:
>
> > Hi Nadeeshaan,
> >
> > congrats! I hope you like our interface :) If you have any feedback on
> > the installation process, including the website and/or have any ideas
> > to make it better, just let us know.
> >
> > I have talked to you via chat already, so some of the things I write
> > may be redundant, but I already started writing that mail when we
> > started chatting and it probably makes sense to let the ML follow in
> > the public.
> >
> > Under the hood Fauxton uses the CouchDB HTTP API, that means if you
> > would have named your database `baseball` you would have typed:
> >
> > ```
> > $ curl -X PUT http://127.0.0.1:5984/baseball
> > $ curl -X POST http://127.0.0.1:5984/baseball -d '{"involved_person":
> > "player"}' -H "Content-Type: application/json"
> > ```
> >
> > After the POST CouchDB returns an id and rev to you:
> >
> > ```
> >
> >
> {"ok":true,"id":"9ab658d4978b6440b739c2d479000b5f","rev":"1-30447915fbb1fe23e994d0c7a4563abe"}
> > ```
> >
> > You will also see those if you open the new document in Fauxton. You
> > can then open a doc using a GET request and the id:
> >
> > ```
> > $ curl -X GET
> > http://127.0.0.1:5984/baseball/9ab658d4978b6440b739c2d479000b5f
> > ```
> >
> > But why do we need revisions?
> >
> > The first primer is http://guide.couchdb.org/draft/consistency.html to
> > get some background knowledge how CouchDB is updating data, it will
> > make it easier for you why we need revisions in CouchDB compared to a
> > classical SQL database. It does not lock, but to make sure that no
> > other client overwrites accidentally other data, you will need to
> > provide a revision to update a document:
> >
> > ```
> > curl -X PUT
> >
> http://127.0.0.1:5984/baseball2/9e0a5c077bed1acf61ca1bae2e000578?rev=1-30447915fbb1fe23e994d0c7a4563abe
> > -d '{"involved_person": "referee"}' -H "Content-Type:
> > application/json"
> > ```
> >
> > ```
> >
> >
> {"ok":true,"id":"9e0a5c077bed1acf61ca1bae2e000578","rev":"2-61193c79a05bd0fa4fc823ec5a131645"}
> > ```
> >
> > After the update the document gets a new revision. If the revision
> > does not match on an update (e.g. another client updated already) you
> > will get an error:
> >
> > ```
> > curl -X PUT
> > http://127.0.0.1:5984/baseball2/9e0a5c077bed1acf61ca1bae2e000578
> > -d '{"involved_person": "referee"}' -H "Content-Type:
> > application/json"
> > ```
> >
> > results in:
> >
> > ```
> > {"error":"conflict","reason":"Document update conflict."}
> > ```
> >
> > The docs provide very good in-depth background information regarding
> > revisions and conflicts:
> >
> >
> >
> http://docs.couchdb.org/en/1.6.1/replication/conflicts.html#conflict-avoidance
> >
> http://docs.couchdb.org/en/1.6.1/replication/conflicts.html#revision-tree
> >
> > The revision tree will be the one that will get visualized by the gsoc
> > project :)
> >
> > The project mentioned in the ticket
> > (https://github.com/neojski/visualizeRevTree) has an MIT license and
> > is compatible to the Apache 2 license. It might make sense to use that
> > one and just style it to our needs. Things I would like you to find
> > out:
> >
> >  - is the project maintained?
> >  - how we could style it to our needs
> >  - what are the pros/cons to write something like that on our own
> >
> > It is OK if you don't find answers for all these questions, but it
> > would be nice if you would spend max 2hrs until Wednesday to try to
> > find that out.
> >
> > The old interface mentioned in the Jira ticket is available at
> > http://localhost:5984/_utils/ and you were able to navi

[jira] [Closed] (COUCHDB-2639) fresh clone of couchdb does not boot any more?

[Robert Kowalski (JIRA)]

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

Robert Kowalski closed COUCHDB-2639.

Resolution: Fixed

> fresh clone of couchdb does not boot any more?
> --
>
> Key: COUCHDB-2639
> URL: https://issues.apache.org/jira/browse/COUCHDB-2639
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>Reporter: Robert Kowalski
>
> From COUCHDB-2605 - could reproduce on my machine.
> Is this related to the rename process?



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

Re: Plugin infrastructure

[Alexander Shorin]

Hi Ilya,

That's good news, but how this all will be related to existed
https://github.com/apache/couchdb-couch-plugins ?
--
,,,^..^,,,


On Mon, Mar 16, 2015 at 9:12 PM, Ilya Khlopotov  wrote:
>
> Hi,
>
> I would welcome any feedback on using proposed plugerl applications to
> implement vendor specific hooks
>
> https://issues.apache.org/jira/browse/COUCHDB-2585
> https://github.com/apache/couchdb-global-changes/pull/4
> https://github.com/iilyak/plugerl
>
> What are the next steps I need to take besides fixing issues discovered by
> reviewers?
>
> BR,
> ILYA

Plugin infrastructure

[Ilya Khlopotov]

Hi,

I would welcome any feedback on using proposed plugerl applications to
implement vendor specific hooks

https://issues.apache.org/jira/browse/COUCHDB-2585
https://github.com/apache/couchdb-global-changes/pull/4
https://github.com/iilyak/plugerl

What are the next steps I need to take besides fixing issues discovered by
reviewers?

BR,
ILYA

[jira] [Created] (COUCHDB-2639) fresh clone of couchdb does not boot any more?

[Robert Kowalski (JIRA)]

Robert Kowalski created COUCHDB-2639:


 Summary: fresh clone of couchdb does not boot any more?
 Key: COUCHDB-2639
 URL: https://issues.apache.org/jira/browse/COUCHDB-2639
 Project: CouchDB
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Database Core
Reporter: Robert Kowalski


>From COUCHDB-2605 - could reproduce on my machine.

Is this related to the rename process?



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

[GitHub] couchdb-fauxton pull request: Fix couchapp_deploy

[kxepal]

Github user kxepal commented on the pull request:

https://github.com/apache/couchdb-fauxton/pull/316#issuecomment-81848952
  
@garrensmith @robertkowalski 
no problem if I merge this?


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

[jira] [Commented] (COUCHDB-2605) Visualize the CouchDB Cluster

[Robert Kowalski (JIRA)]

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

Robert Kowalski commented on COUCHDB-2605:
--

PS: I think you found a bug :)

> Visualize the CouchDB Cluster
> -
>
> Key: COUCHDB-2605
> URL: https://issues.apache.org/jira/browse/COUCHDB-2605
> Project: CouchDB
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: Fauxton
>Affects Versions: 2.1
>Reporter: Robert Kowalski
>  Labels: CouchDB, gsoc2015, javascript
>
> Show for each database on which nodes in the cluster the data is stored - and 
> warn if the disk space runs out on these nodes.
> The project is using React.js for the Admin-Interface. You will use 
> JavaScript, CSS, HTML and the HTTP API of CouchDB to visualize the cluster. 



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

[jira] [Commented] (COUCHDB-2605) Visualize the CouchDB Cluster

[Robert Kowalski (JIRA)]

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

Robert Kowalski commented on COUCHDB-2605:
--

I am glad you got it working - sorry for the initial hassle. With a running 
three node cluster you can now start taking a look:

The backdoor port for 15984 would be 15986 - just open 
http://localhost:15986/_all_dbs and take a look. You will see some 
system-databases like `_nodes` and have just used CouchDBs HTTP API 

In another terminal run (after installing haproxy):
haproxy -f rel/haproxy.conf

After that just take a look at Fauxton, the Admin Interface (let the cluster 
running):
go to src/fauxton  run `npm install` and then `grunt dev` - now open 
http://localhost:8000 and you should see a red interface.

Try to create a database and and then create a first document to get a first 
impression of Fauxton. After that take another look at 
http://localhost:15986/_all_dbs - do you see any differences and if so, which?

May I ask you to move the further discussion to our dev mailing list so 
everybody can follow our progress apart from this ticket describing the feature?

> Visualize the CouchDB Cluster
> -
>
> Key: COUCHDB-2605
> URL: https://issues.apache.org/jira/browse/COUCHDB-2605
> Project: CouchDB
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: Fauxton
>Affects Versions: 2.1
>Reporter: Robert Kowalski
>  Labels: CouchDB, gsoc2015, javascript
>
> Show for each database on which nodes in the cluster the data is stored - and 
> warn if the disk space runs out on these nodes.
> The project is using React.js for the Admin-Interface. You will use 
> JavaScript, CSS, HTML and the HTTP API of CouchDB to visualize the cluster. 



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

Re: Stepping down (mostly)

[Robert Kowalski]

Sad to hear Dirkjan,

all the best for the future!

Best,
Robert

On Mon, Mar 16, 2015 at 8:31 AM, Garren Smith  wrote:
> Hi Dirkjan,
>
> Thanks for all your help. Hope to see you around when the opportunity 
> presents itself.
>
> Cheers
> Garren
>
>> On 16 Mar 2015, at 1:19 AM, Klaus Trainer  wrote:
>>
>> Hi Dirkjan,
>>
>> thanks for everything you've contributed during the last years :)
>>
>> All the best,
>> Klaus
>>
>>
>> On 03/15/2015 11:12 AM, Dirkjan Ochtman wrote:
>>> Hi all,
>>>
>>> Although I'd previously dropped hints about this in other email
>>> threads, I wanted to make it explicit that I have stopped spending as
>>> much time on CouchDB as I did in previous years. This means that I
>>> won't spend time on the documentation or on release management
>>> anymore. However, I'll still hang around on dev@ as a Gentoo packager
>>> and as the CouchDB-Python maintainer.
>>>
>>> With the recent growth of the committer group, I'm sure y'all can
>>> handle things without me.
>>>
>>> As a point of constructive criticism, the way dev@ gets ALL THE THINGS
>>> currently (as in, Jira & GitHub notifications) isn't great for my kind
>>> of usage. I think I've said this before, but personally I'd really
>>> appreciate all the machine-generated email going on a separate list
>>> from the human stuff.
>>>
>>> Cheers,
>>>
>>> Dirkjan
>>>
>

Re: [PROPOSAL] Move transactional email out of dev@

[Alexander Shorin]

On Mon, Mar 16, 2015 at 7:46 PM, Joan Touzet  wrote:
> I'd be in support of an automated email monthly to dev@ that reminds
> people where to go to look for GH PRs, JIRA ticket updates, etc.

Good idea btw. +1

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

[jira] [Closed] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini

[Jan Lehnardt (JIRA)]

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

Jan Lehnardt closed COUCHDB-2638.
-

> CouchDB should not be writing /etc/couchdb/local.ini
> 
>
> Key: COUCHDB-2638
> URL: https://issues.apache.org/jira/browse/COUCHDB-2638
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Yuri
> Fix For: 2.0.0
>
>
> I am getting such messages in log on FreeBSD:
> > Could not write config file /usr/local/etc/couchdb/local.ini: permission 
> > denied
> The problem is that CoachDB supplies the original copy of local.ini, and it 
> is treated as a template for this configuration file. It is placed into 
> /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into 
> /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin 
> configures. Ideally admin can compare local.ini and local.ini.sample and see 
> if anything in default configuration was modified compared to the suggested 
> sample.
> When the executable itself modifies local.ini too, this makes it very 
> confusing. Admin will be confused if he should or shouldn't touch this file.
> My suggestion is that CouchDB should copy local.ini under /var/db/, or 
> somewhere else, and write it there. /etc isn't supposed to be writable by the 
> process.



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

[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini

[Jan Lehnardt (JIRA)]

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

Jan Lehnardt commented on COUCHDB-2638:
---

Rest assured, CouchDB is getting plenty of use. I don’t consider this a bug :)

> CouchDB should not be writing /etc/couchdb/local.ini
> 
>
> Key: COUCHDB-2638
> URL: https://issues.apache.org/jira/browse/COUCHDB-2638
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Yuri
> Fix For: 2.0.0
>
>
> I am getting such messages in log on FreeBSD:
> > Could not write config file /usr/local/etc/couchdb/local.ini: permission 
> > denied
> The problem is that CoachDB supplies the original copy of local.ini, and it 
> is treated as a template for this configuration file. It is placed into 
> /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into 
> /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin 
> configures. Ideally admin can compare local.ini and local.ini.sample and see 
> if anything in default configuration was modified compared to the suggested 
> sample.
> When the executable itself modifies local.ini too, this makes it very 
> confusing. Admin will be confused if he should or shouldn't touch this file.
> My suggestion is that CouchDB should copy local.ini under /var/db/, or 
> somewhere else, and write it there. /etc isn't supposed to be writable by the 
> process.



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

[jira] [Issue Comment Deleted] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini

[Jan Lehnardt (JIRA)]

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

Jan Lehnardt updated COUCHDB-2638:
--
Comment: was deleted

(was: Rest assured, CouchDB is getting plenty of use. I don’t consider this a 
bug :))

> CouchDB should not be writing /etc/couchdb/local.ini
> 
>
> Key: COUCHDB-2638
> URL: https://issues.apache.org/jira/browse/COUCHDB-2638
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Yuri
> Fix For: 2.0.0
>
>
> I am getting such messages in log on FreeBSD:
> > Could not write config file /usr/local/etc/couchdb/local.ini: permission 
> > denied
> The problem is that CoachDB supplies the original copy of local.ini, and it 
> is treated as a template for this configuration file. It is placed into 
> /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into 
> /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin 
> configures. Ideally admin can compare local.ini and local.ini.sample and see 
> if anything in default configuration was modified compared to the suggested 
> sample.
> When the executable itself modifies local.ini too, this makes it very 
> confusing. Admin will be confused if he should or shouldn't touch this file.
> My suggestion is that CouchDB should copy local.ini under /var/db/, or 
> somewhere else, and write it there. /etc isn't supposed to be writable by the 
> process.



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

[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini

[Jan Lehnardt (JIRA)]

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

Jan Lehnardt commented on COUCHDB-2638:
---

Rest assured, CouchDB is getting plenty of use. I don’t consider this a bug :)

> CouchDB should not be writing /etc/couchdb/local.ini
> 
>
> Key: COUCHDB-2638
> URL: https://issues.apache.org/jira/browse/COUCHDB-2638
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Yuri
> Fix For: 2.0.0
>
>
> I am getting such messages in log on FreeBSD:
> > Could not write config file /usr/local/etc/couchdb/local.ini: permission 
> > denied
> The problem is that CoachDB supplies the original copy of local.ini, and it 
> is treated as a template for this configuration file. It is placed into 
> /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into 
> /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin 
> configures. Ideally admin can compare local.ini and local.ini.sample and see 
> if anything in default configuration was modified compared to the suggested 
> sample.
> When the executable itself modifies local.ini too, this makes it very 
> confusing. Admin will be confused if he should or shouldn't touch this file.
> My suggestion is that CouchDB should copy local.ini under /var/db/, or 
> somewhere else, and write it there. /etc isn't supposed to be writable by the 
> process.



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

[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini

[Yuri (JIRA)]

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

Yuri commented on COUCHDB-2638:
---

Ha, it may have existed for 8 years or so, but it apparently hasn't been really 
used much because such critical bug (read-only file that is expected to be 
writeable) went unnoticed. No user account could be created. :-)

> CouchDB should not be writing /etc/couchdb/local.ini
> 
>
> Key: COUCHDB-2638
> URL: https://issues.apache.org/jira/browse/COUCHDB-2638
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Yuri
> Fix For: 2.0.0
>
>
> I am getting such messages in log on FreeBSD:
> > Could not write config file /usr/local/etc/couchdb/local.ini: permission 
> > denied
> The problem is that CoachDB supplies the original copy of local.ini, and it 
> is treated as a template for this configuration file. It is placed into 
> /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into 
> /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin 
> configures. Ideally admin can compare local.ini and local.ini.sample and see 
> if anything in default configuration was modified compared to the suggested 
> sample.
> When the executable itself modifies local.ini too, this makes it very 
> confusing. Admin will be confused if he should or shouldn't touch this file.
> My suggestion is that CouchDB should copy local.ini under /var/db/, or 
> somewhere else, and write it there. /etc isn't supposed to be writable by the 
> process.



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

Re: [PROPOSAL] Move transactional email out of dev@

[Joan Touzet]

I agree with all of this.

I'd be in support of an automated email monthly to dev@ that reminds
people where to go to look for GH PRs, JIRA ticket updates, etc.

-Joan

- Original Message -
From: "Noah Slater" 
To: dev@couchdb.apache.org
Sent: Monday, March 16, 2015 11:58:35 AM
Subject: Re: [PROPOSAL] Move transactional email out of dev@

+1 for JIRA -> issues@

-1 for GitHub PRs -> commits@

> Justification: PR comments are dev discussion, not changesets

I am +0 for GitHub PRs remaining on dev

> Justification: I also get that they're noisy

I am +1 for GitHub PRs moving to something like reviews@

On 16 March 2015 at 15:42, Alexander Shorin  wrote:
> On Mon, Mar 16, 2015 at 5:00 PM, Robert Kowalski  wrote:
>> Alex: I think people who are not interested in reviewing PRs now will
>> not be interested anyway, no matter which channels we try to enforce.
>> We are currently channeling all mails for PRs to dev and since months
>> I am getting reviews from the same group of persons.
>
> Indeed, but those who are shouldn't suffer from the spam which happens
> in commits@ . Please note, the GH notifications aren't just
> automatically generated emails: you can reply on them and those
> replied will be synced with GH. So you're able to lead a discussion
> right from your email client.
>
> The most compromise solution looks for me as a separate ML. We
> collection the stats for every board report. If it won't be much
> popular/useful we'll just shut it down and move these stuff to
> commits@, but with really insurance that nobody cares/use ML for GH
> conversations.
>
> What's the reviews are constantly made by the same group of persons is
> a separate issue.
>
> --
> ,,,^..^,,,



-- 
Noah Slater
https://twitter.com/nslater

Re: [PROPOSAL] Move transactional email out of dev@

[Noah Slater]

+1 for JIRA -> issues@

-1 for GitHub PRs -> commits@

> Justification: PR comments are dev discussion, not changesets

I am +0 for GitHub PRs remaining on dev

> Justification: I also get that they're noisy

I am +1 for GitHub PRs moving to something like reviews@

On 16 March 2015 at 15:42, Alexander Shorin  wrote:
> On Mon, Mar 16, 2015 at 5:00 PM, Robert Kowalski  wrote:
>> Alex: I think people who are not interested in reviewing PRs now will
>> not be interested anyway, no matter which channels we try to enforce.
>> We are currently channeling all mails for PRs to dev and since months
>> I am getting reviews from the same group of persons.
>
> Indeed, but those who are shouldn't suffer from the spam which happens
> in commits@ . Please note, the GH notifications aren't just
> automatically generated emails: you can reply on them and those
> replied will be synced with GH. So you're able to lead a discussion
> right from your email client.
>
> The most compromise solution looks for me as a separate ML. We
> collection the stats for every board report. If it won't be much
> popular/useful we'll just shut it down and move these stuff to
> commits@, but with really insurance that nobody cares/use ML for GH
> conversations.
>
> What's the reviews are constantly made by the same group of persons is
> a separate issue.
>
> --
> ,,,^..^,,,



-- 
Noah Slater
https://twitter.com/nslater

Re: [PROPOSAL] Move transactional email out of dev@

[Noah Slater]

Oh, and -1 on disabling our GitHub email integration

Justification: it would break the "decisions are made on the mailing lists" rule

On 16 March 2015 at 16:58, Noah Slater  wrote:
> +1 for JIRA -> issues@
>
> -1 for GitHub PRs -> commits@
>
>> Justification: PR comments are dev discussion, not changesets
>
> I am +0 for GitHub PRs remaining on dev
>
>> Justification: I also get that they're noisy
>
> I am +1 for GitHub PRs moving to something like reviews@
>
> On 16 March 2015 at 15:42, Alexander Shorin  wrote:
>> On Mon, Mar 16, 2015 at 5:00 PM, Robert Kowalski  wrote:
>>> Alex: I think people who are not interested in reviewing PRs now will
>>> not be interested anyway, no matter which channels we try to enforce.
>>> We are currently channeling all mails for PRs to dev and since months
>>> I am getting reviews from the same group of persons.
>>
>> Indeed, but those who are shouldn't suffer from the spam which happens
>> in commits@ . Please note, the GH notifications aren't just
>> automatically generated emails: you can reply on them and those
>> replied will be synced with GH. So you're able to lead a discussion
>> right from your email client.
>>
>> The most compromise solution looks for me as a separate ML. We
>> collection the stats for every board report. If it won't be much
>> popular/useful we'll just shut it down and move these stuff to
>> commits@, but with really insurance that nobody cares/use ML for GH
>> conversations.
>>
>> What's the reviews are constantly made by the same group of persons is
>> a separate issue.
>>
>> --
>> ,,,^..^,,,
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater



-- 
Noah Slater
https://twitter.com/nslater

[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini

[ILYA (JIRA)]

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

ILYA commented on COUCHDB-2638:
---

You might be able to achieve the desired behavior by adding following into 
vm.args

echo '-couch_ini /usr/local/etc/couchdb/default.ini 
/usr/local/etc/couchdb/local.ini /var/run/couch/local.ini' >> vm.args

Last file in the list will need write access. Make sure the path exists.

> CouchDB should not be writing /etc/couchdb/local.ini
> 
>
> Key: COUCHDB-2638
> URL: https://issues.apache.org/jira/browse/COUCHDB-2638
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Yuri
> Fix For: 2.0.0
>
>
> I am getting such messages in log on FreeBSD:
> > Could not write config file /usr/local/etc/couchdb/local.ini: permission 
> > denied
> The problem is that CoachDB supplies the original copy of local.ini, and it 
> is treated as a template for this configuration file. It is placed into 
> /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into 
> /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin 
> configures. Ideally admin can compare local.ini and local.ini.sample and see 
> if anything in default configuration was modified compared to the suggested 
> sample.
> When the executable itself modifies local.ini too, this makes it very 
> confusing. Admin will be confused if he should or shouldn't touch this file.
> My suggestion is that CouchDB should copy local.ini under /var/db/, or 
> somewhere else, and write it there. /etc isn't supposed to be writable by the 
> process.



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

Re: [PROPOSAL] Move transactional email out of dev@

[Alexander Shorin]

On Mon, Mar 16, 2015 at 5:00 PM, Robert Kowalski  wrote:
> Alex: I think people who are not interested in reviewing PRs now will
> not be interested anyway, no matter which channels we try to enforce.
> We are currently channeling all mails for PRs to dev and since months
> I am getting reviews from the same group of persons.

Indeed, but those who are shouldn't suffer from the spam which happens
in commits@ . Please note, the GH notifications aren't just
automatically generated emails: you can reply on them and those
replied will be synced with GH. So you're able to lead a discussion
right from your email client.

The most compromise solution looks for me as a separate ML. We
collection the stats for every board report. If it won't be much
popular/useful we'll just shut it down and move these stuff to
commits@, but with really insurance that nobody cares/use ML for GH
conversations.

What's the reviews are constantly made by the same group of persons is
a separate issue.

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

Re: [PROPOSAL] Move transactional email out of dev@

[Robert Kowalski]

I am +1 on Jans proposal.

Alex: I think people who are not interested in reviewing PRs now will
not be interested anyway, no matter which channels we try to enforce.
We are currently channeling all mails for PRs to dev and since months
I am getting reviews from the same group of persons.

The current state is that folks are avoiding the dev ML because of this noise.



On Mon, Mar 16, 2015 at 2:20 PM, Alexander Shorin  wrote:
> On Mon, Mar 16, 2015 at 4:08 PM, Jan Lehnardt  wrote:
>>> On 16 Mar 2015, at 14:00, Alexander Shorin  wrote:
>>>
>>> +1 for JIRA
>>> -1 for GitHub
>>> I think we need another ML for PRs and related conversation there OR
>>> somehow automagically add all the committers to watchers list on
>>> GitHub of our projects to let them receive notification by using
>>> GitHub system. People how don't want to follow all the projects may
>>> unwatch those manually. But commits@ isn't the place where you should
>>> go for the PRs without MUA filters while PRs isn't a thing to receive
>>> lack of attention.
>>
>> Can you make a concrete proposal e.g. “emails so and so should go to 
>> foo@c.a.o”?
>
> I'm not sure that they should since I have multiple views on this:
>
> 1. GitHub notification remains on dev@.
> Pros:
> - Everyone reads the dev@;
> - You can participant in GH discussion by replying on related the email;
> - Nothing need to do;
> Cons:
> - It's automatically generated email;
> - Not at all people are interested in all our subprojects (fauxtoners
> may'd like to receive www- related mails, but www- folks unlikely
> would be interested in fabric changes etc.);
>
> 2. Move GitHub notifications to gh@ ML.
> Pros:
> - Less noise on dev@;
> Cons:
> - If you're not subscribed on gh@ and doesn't watch project on GitHub,
> you could easily miss the notification about pull request;
>
> 3. Disable GitHub emails at all on ASF MLs, add all the folks as
> watchers of all our subprojects and let them unscribe from those they
> don't like to follow.
> Pros:
> - Everyone follows things they likes;
> - No Pull Requests lacks of attention (theoretically);
> - No automatically generated emails;
> Cons:
> - All the related conversation happens not on ASF baseground, but GitHub one;
> - Daniel will be sad;
>
> Not sure which one is the best since it's very depends on overall
> people workflow and ASF rules.
>
> --
> ,,,^..^,,,

Re: [PROPOSAL] Move transactional email out of dev@

[Alexander Shorin]

On Mon, Mar 16, 2015 at 4:08 PM, Jan Lehnardt  wrote:
>> On 16 Mar 2015, at 14:00, Alexander Shorin  wrote:
>>
>> +1 for JIRA
>> -1 for GitHub
>> I think we need another ML for PRs and related conversation there OR
>> somehow automagically add all the committers to watchers list on
>> GitHub of our projects to let them receive notification by using
>> GitHub system. People how don't want to follow all the projects may
>> unwatch those manually. But commits@ isn't the place where you should
>> go for the PRs without MUA filters while PRs isn't a thing to receive
>> lack of attention.
>
> Can you make a concrete proposal e.g. “emails so and so should go to 
> foo@c.a.o”?

I'm not sure that they should since I have multiple views on this:

1. GitHub notification remains on dev@.
Pros:
- Everyone reads the dev@;
- You can participant in GH discussion by replying on related the email;
- Nothing need to do;
Cons:
- It's automatically generated email;
- Not at all people are interested in all our subprojects (fauxtoners
may'd like to receive www- related mails, but www- folks unlikely
would be interested in fabric changes etc.);

2. Move GitHub notifications to gh@ ML.
Pros:
- Less noise on dev@;
Cons:
- If you're not subscribed on gh@ and doesn't watch project on GitHub,
you could easily miss the notification about pull request;

3. Disable GitHub emails at all on ASF MLs, add all the folks as
watchers of all our subprojects and let them unscribe from those they
don't like to follow.
Pros:
- Everyone follows things they likes;
- No Pull Requests lacks of attention (theoretically);
- No automatically generated emails;
Cons:
- All the related conversation happens not on ASF baseground, but GitHub one;
- Daniel will be sad;

Not sure which one is the best since it's very depends on overall
people workflow and ASF rules.

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

Re: [PROPOSAL] Move transactional email out of dev@

[Jan Lehnardt]

> On 16 Mar 2015, at 14:00, Alexander Shorin  wrote:
> 
> +1 for JIRA
> -1 for GitHub
> I think we need another ML for PRs and related conversation there OR
> somehow automagically add all the committers to watchers list on
> GitHub of our projects to let them receive notification by using
> GitHub system. People how don't want to follow all the projects may
> unwatch those manually. But commits@ isn't the place where you should
> go for the PRs without MUA filters while PRs isn't a thing to receive
> lack of attention.

Can you make a concrete proposal e.g. “emails so and so should go to foo@c.a.o”?

Best
Jan
--

> 
> --
> ,,,^..^,,,
> 
> 
> On Mon, Mar 16, 2015 at 3:54 PM, Garren Smith  wrote:
>> +1
>> 
>>> On 16 Mar 2015, at 2:47 PM, Jan Lehnardt  wrote:
>>> 
>>> Hey all,
>>> 
>>> we should move transactional email out of dev@ into separate mailing lists. 
>>> I propose this:
>>> 
>>> JIRA email -> issues@c.a.o (new mailing list)
>>> GitHub email -> commits@c.a.o (which already exists)
>>> 
>>> Am I missing anything?
>>> 
>>> Best
>>> Jan
>>> --
>>> 
>>> 
>>> --
>>> Professional Support for Apache CouchDB:
>>> http://www.neighbourhood.ie/couchdb-support/
>>> 
>> 

--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PROPOSAL] Move transactional email out of dev@

[Alexander Shorin]

+1 for JIRA
-1 for GitHub
I think we need another ML for PRs and related conversation there OR
somehow automagically add all the committers to watchers list on
GitHub of our projects to let them receive notification by using
GitHub system. People how don't want to follow all the projects may
unwatch those manually. But commits@ isn't the place where you should
go for the PRs without MUA filters while PRs isn't a thing to receive
lack of attention.

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


On Mon, Mar 16, 2015 at 3:54 PM, Garren Smith  wrote:
> +1
>
>> On 16 Mar 2015, at 2:47 PM, Jan Lehnardt  wrote:
>>
>> Hey all,
>>
>> we should move transactional email out of dev@ into separate mailing lists. 
>> I propose this:
>>
>> JIRA email -> issues@c.a.o (new mailing list)
>> GitHub email -> commits@c.a.o (which already exists)
>>
>> Am I missing anything?
>>
>> Best
>> Jan
>> --
>>
>>
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>

[GitHub] couchdb-fauxton pull request: Call JSX build in a way that works o...

[kxepal]

Github user kxepal commented on the pull request:

https://github.com/apache/couchdb-fauxton/pull/318#issuecomment-81645408
  
@garrensmith that's simplifies everything (:


---
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: [PROPOSAL] Move transactional email out of dev@

[Jan Lehnardt]

Thanks for your support Garren :)

No need for the others +1 this (let’s keep emails down, eh? :). I
think we have consensus on this, I just want to get the details
nailed down, so I can request INFRA to do the changes.

Best
Jan
--


> On 16 Mar 2015, at 13:54, Garren Smith  wrote:
> 
> +1
> 
>> On 16 Mar 2015, at 2:47 PM, Jan Lehnardt  wrote:
>> 
>> Hey all,
>> 
>> we should move transactional email out of dev@ into separate mailing lists. 
>> I propose this:
>> 
>> JIRA email -> issues@c.a.o (new mailing list)
>> GitHub email -> commits@c.a.o (which already exists)
>> 
>> Am I missing anything?
>> 
>> Best
>> Jan
>> --
>> 
>> 
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>> 
> 

--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/



signature.asc
Description: Message signed with OpenPGP using GPGMail

[GitHub] couchdb-fauxton pull request: Call JSX build in a way that works o...

[garrensmith]

Github user garrensmith commented on the pull request:

https://github.com/apache/couchdb-fauxton/pull/318#issuecomment-81642336
  
@kxepal the `rm -rf` command is not needed. If we remove that then Fauxton 
will run on Windows with no special requirements.


---
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: [PROPOSAL] Move transactional email out of dev@

[Garren Smith]

+1

> On 16 Mar 2015, at 2:47 PM, Jan Lehnardt  wrote:
> 
> Hey all,
> 
> we should move transactional email out of dev@ into separate mailing lists. I 
> propose this:
> 
> JIRA email -> issues@c.a.o (new mailing list)
> GitHub email -> commits@c.a.o (which already exists)
> 
> Am I missing anything?
> 
> Best
> Jan
> --
> 
> 
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
> 

[GitHub] couchdb-fauxton pull request: Call JSX build in a way that works o...

[kxepal]

Github user kxepal commented on the pull request:

https://github.com/apache/couchdb-fauxton/pull/318#issuecomment-81639569
  
How about to move such platform depended commands to the platform 
independent script? Since you require to have install nodejs in anyway, but 
require mingw32 to build Fauxton sounds as overkill.


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

[PROPOSAL] Move transactional email out of dev@

[Jan Lehnardt]

Hey all,

we should move transactional email out of dev@ into separate mailing lists. I 
propose this:

JIRA email -> issues@c.a.o (new mailing list)
GitHub email -> commits@c.a.o (which already exists)

Am I missing anything?

Best
Jan
--


--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/



signature.asc
Description: Message signed with OpenPGP using GPGMail

[GitHub] couchdb-fauxton pull request: Call JSX build in a way that works o...

[sebastianrothbucher]

Github user sebastianrothbucher commented on the pull request:

https://github.com/apache/couchdb-fauxton/pull/318#issuecomment-81634660
  
With mingw32 you indeed have *nix commands. Anyhow I'll remove and retest 
2night.
Thx 4 the Feedback!


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

[GitHub] couchdb-snappy pull request: Support big-endian builds

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/couchdb-snappy/pull/2


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

[GitHub] couchdb-snappy pull request: Support big-endian builds

[janl]

Github user janl commented on the pull request:

https://github.com/apache/couchdb-snappy/pull/2#issuecomment-81632205
  
merged!


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

[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini

[Jan Lehnardt (JIRA)]

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

Jan Lehnardt commented on COUCHDB-2638:
---

In addition, CouchDB has behaved like this since it had a config system (0.7.0 
or so, back in 2007 or 08), and has happily been on FreeBSD ever since and this 
is the first time this comes up :)

> CouchDB should not be writing /etc/couchdb/local.ini
> 
>
> Key: COUCHDB-2638
> URL: https://issues.apache.org/jira/browse/COUCHDB-2638
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Yuri
> Fix For: 2.0.0
>
>
> I am getting such messages in log on FreeBSD:
> > Could not write config file /usr/local/etc/couchdb/local.ini: permission 
> > denied
> The problem is that CoachDB supplies the original copy of local.ini, and it 
> is treated as a template for this configuration file. It is placed into 
> /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into 
> /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin 
> configures. Ideally admin can compare local.ini and local.ini.sample and see 
> if anything in default configuration was modified compared to the suggested 
> sample.
> When the executable itself modifies local.ini too, this makes it very 
> confusing. Admin will be confused if he should or shouldn't touch this file.
> My suggestion is that CouchDB should copy local.ini under /var/db/, or 
> somewhere else, and write it there. /etc isn't supposed to be writable by the 
> process.



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

[GitHub] couchdb-fauxton pull request: Active tasks in react

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/317#discussion_r26471989
  
--- Diff: app/addons/activetasks/components.react.jsx ---
@@ -0,0 +1,387 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you may 
not
+// use this file except in compliance with the License. You may obtain a 
copy of
+// the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+// License for the specific language governing permissions and limitations 
under
+// the License.
+
+define([
+  "app/helpers",
+  "api",
+  "react",
+  "addons/activetasks/stores",
+  "addons/activetasks/resources",
+  "addons/activetasks/actions"
+
+], function (Helpers, FauxtonAPI, React, Stores, Resources, Actions) {
+  var activeTasksStore = Stores.activeTasksStore;
+
+  var ActiveTasksController = React.createClass({
+
+getStoreState: function () {
+  return {  
+selectedTab: activeTasksStore.getSelectedTab(),
+collection: activeTasksStore.getCollection(),
+searchTerm: activeTasksStore.getSearchTerm(),
+setPolling: activeTasksStore.setPolling(),
+clearPolling: activeTasksStore.clearPolling
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+componentDidMount: function () {
+  this.state.setPolling;
+  activeTasksStore.on('change', this.onChange, this);  
+},
+
+componentWillUnmount: function() {
+  this.state.clearPolling();
+  activeTasksStore.off('change', this.onChange, this); 
+},
+onChange: function () {
+  this.setState(this.getStoreState());
+},
+render: function () {
+  var collection = this.state.collection; 
+  var searchTerm = this.state.searchTerm;
+  var selectedTab = this.state.selectedTab;
+
+  if (collection.length === 0 ) {
+return (   No tasks. 
 );
+  } else {
+return (
+  
+
+  
+  
+
+  
+);
+  }
+}
+  });
+
+  var ActiveTasksFilterHeader = React.createClass({ //This is for the 
little '+ Filter' Tab 
+getStoreState: function () {
+  return {  
+searchTerm: activeTasksStore.getSearchTerm()
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+toggleFilter: function () {
+  $('#dashboard-content').scrollTop(0);
+  $('#query').toggle('slow');
+},
+setNewSearchTerm: function (e) {
+  this.setState({searchTerm: e.target.value});
+  Actions.setSearchTerm(e.target.value);
+},
+render: function () {
+  var searchTerm = this.state.searchTerm;
+  return (
+
+  
+
+  
+
+  Filter
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  );
+}
+  });
+
+  var ActiveTaskTable = React.createClass({
+getInfo: function (item) {
+  return {
+type : item.get('type'),
+objectField : this.getDatabaseFieldMessage(item) ,
+started_on : this.getTimeInfo(item.get('started_on')), 
+updated_on : this.getTimeInfo(item.get('updated_on')),
+pid : item.get('pid').replace(/[<>]/g, ''),
+progress : this.getProgressMessage(item),
+  };
+},
+getTimeInfo: function (timeStamp) {
+  var timeMessage = [Helpers.formatDate(timeStamp)];
+  timeMessage.push(Helpers.getDateFromNow(timeStamp));
+  return timeMessage;
+},
+getDatabaseFieldMessage: function (model) {
+  var type = model.get('type');
+  var databaseFieldMessage = [];
+
+  if (type === 'replication') {
+databaseFieldMessage.push('From: ' + model.get('source'));
+databaseFieldMessage.push('To: ' + model.get('target'));
+  } else if (type === 'indexer') {
+databaseFieldMessage.push(model.get('database'));
+databaseFieldMessage.push('(View: ' + model.get('design_document') 
+ '

[GitHub] couchdb-fauxton pull request: Active tasks in react

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/317#discussion_r26471908
  
--- Diff: app/addons/activetasks/components.react.jsx ---
@@ -0,0 +1,387 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you may 
not
+// use this file except in compliance with the License. You may obtain a 
copy of
+// the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+// License for the specific language governing permissions and limitations 
under
+// the License.
+
+define([
+  "app/helpers",
+  "api",
+  "react",
+  "addons/activetasks/stores",
+  "addons/activetasks/resources",
+  "addons/activetasks/actions"
+
+], function (Helpers, FauxtonAPI, React, Stores, Resources, Actions) {
+  var activeTasksStore = Stores.activeTasksStore;
+
+  var ActiveTasksController = React.createClass({
+
+getStoreState: function () {
+  return {  
+selectedTab: activeTasksStore.getSelectedTab(),
+collection: activeTasksStore.getCollection(),
+searchTerm: activeTasksStore.getSearchTerm(),
+setPolling: activeTasksStore.setPolling(),
+clearPolling: activeTasksStore.clearPolling
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+componentDidMount: function () {
+  this.state.setPolling;
+  activeTasksStore.on('change', this.onChange, this);  
+},
+
+componentWillUnmount: function() {
+  this.state.clearPolling();
+  activeTasksStore.off('change', this.onChange, this); 
+},
+onChange: function () {
+  this.setState(this.getStoreState());
+},
+render: function () {
+  var collection = this.state.collection; 
+  var searchTerm = this.state.searchTerm;
+  var selectedTab = this.state.selectedTab;
+
+  if (collection.length === 0 ) {
+return (   No tasks. 
 );
+  } else {
+return (
+  
+
+  
+  
+
+  
+);
+  }
+}
+  });
+
+  var ActiveTasksFilterHeader = React.createClass({ //This is for the 
little '+ Filter' Tab 
+getStoreState: function () {
+  return {  
+searchTerm: activeTasksStore.getSearchTerm()
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+toggleFilter: function () {
+  $('#dashboard-content').scrollTop(0);
+  $('#query').toggle('slow');
+},
+setNewSearchTerm: function (e) {
+  this.setState({searchTerm: e.target.value});
+  Actions.setSearchTerm(e.target.value);
+},
+render: function () {
+  var searchTerm = this.state.searchTerm;
+  return (
+
+  
+
+  
+
+  Filter
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  );
+}
+  });
+
+  var ActiveTaskTable = React.createClass({
+getInfo: function (item) {
+  return {
+type : item.get('type'),
+objectField : this.getDatabaseFieldMessage(item) ,
+started_on : this.getTimeInfo(item.get('started_on')), 
+updated_on : this.getTimeInfo(item.get('updated_on')),
+pid : item.get('pid').replace(/[<>]/g, ''),
+progress : this.getProgressMessage(item),
+  };
+},
+getTimeInfo: function (timeStamp) {
+  var timeMessage = [Helpers.formatDate(timeStamp)];
+  timeMessage.push(Helpers.getDateFromNow(timeStamp));
+  return timeMessage;
+},
+getDatabaseFieldMessage: function (model) {
+  var type = model.get('type');
+  var databaseFieldMessage = [];
+
+  if (type === 'replication') {
+databaseFieldMessage.push('From: ' + model.get('source'));
+databaseFieldMessage.push('To: ' + model.get('target'));
+  } else if (type === 'indexer') {
+databaseFieldMessage.push(model.get('database'));
+databaseFieldMessage.push('(View: ' + model.get('design_document') 
+ '

[GitHub] couchdb-fauxton pull request: Active tasks in react

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/317#discussion_r26471806
  
--- Diff: app/addons/activetasks/components.react.jsx ---
@@ -0,0 +1,387 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you may 
not
+// use this file except in compliance with the License. You may obtain a 
copy of
+// the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+// License for the specific language governing permissions and limitations 
under
+// the License.
+
+define([
+  "app/helpers",
+  "api",
+  "react",
+  "addons/activetasks/stores",
+  "addons/activetasks/resources",
+  "addons/activetasks/actions"
+
+], function (Helpers, FauxtonAPI, React, Stores, Resources, Actions) {
+  var activeTasksStore = Stores.activeTasksStore;
+
+  var ActiveTasksController = React.createClass({
+
+getStoreState: function () {
+  return {  
+selectedTab: activeTasksStore.getSelectedTab(),
+collection: activeTasksStore.getCollection(),
+searchTerm: activeTasksStore.getSearchTerm(),
+setPolling: activeTasksStore.setPolling(),
+clearPolling: activeTasksStore.clearPolling
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+componentDidMount: function () {
+  this.state.setPolling;
+  activeTasksStore.on('change', this.onChange, this);  
+},
+
+componentWillUnmount: function() {
+  this.state.clearPolling();
+  activeTasksStore.off('change', this.onChange, this); 
+},
+onChange: function () {
+  this.setState(this.getStoreState());
+},
+render: function () {
+  var collection = this.state.collection; 
+  var searchTerm = this.state.searchTerm;
+  var selectedTab = this.state.selectedTab;
+
+  if (collection.length === 0 ) {
+return (   No tasks. 
 );
+  } else {
+return (
+  
+
+  
+  
+
+  
+);
+  }
+}
+  });
+
+  var ActiveTasksFilterHeader = React.createClass({ //This is for the 
little '+ Filter' Tab 
+getStoreState: function () {
+  return {  
+searchTerm: activeTasksStore.getSearchTerm()
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+toggleFilter: function () {
+  $('#dashboard-content').scrollTop(0);
+  $('#query').toggle('slow');
+},
+setNewSearchTerm: function (e) {
+  this.setState({searchTerm: e.target.value});
+  Actions.setSearchTerm(e.target.value);
+},
+render: function () {
+  var searchTerm = this.state.searchTerm;
+  return (
+
+  
+
+  
+
+  Filter
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  );
+}
+  });
+
+  var ActiveTaskTable = React.createClass({
+getInfo: function (item) {
+  return {
+type : item.get('type'),
+objectField : this.getDatabaseFieldMessage(item) ,
+started_on : this.getTimeInfo(item.get('started_on')), 
+updated_on : this.getTimeInfo(item.get('updated_on')),
+pid : item.get('pid').replace(/[<>]/g, ''),
+progress : this.getProgressMessage(item),
+  };
+},
+getTimeInfo: function (timeStamp) {
+  var timeMessage = [Helpers.formatDate(timeStamp)];
+  timeMessage.push(Helpers.getDateFromNow(timeStamp));
+  return timeMessage;
+},
+getDatabaseFieldMessage: function (model) {
+  var type = model.get('type');
+  var databaseFieldMessage = [];
+
+  if (type === 'replication') {
+databaseFieldMessage.push('From: ' + model.get('source'));
+databaseFieldMessage.push('To: ' + model.get('target'));
+  } else if (type === 'indexer') {
+databaseFieldMessage.push(model.get('database'));
+databaseFieldMessage.push('(View: ' + model.get('design_document') 
+ '

[GitHub] couchdb-fauxton pull request: Active tasks in react

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/317#discussion_r26471614
  
--- Diff: app/addons/activetasks/components.react.jsx ---
@@ -0,0 +1,387 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you may 
not
+// use this file except in compliance with the License. You may obtain a 
copy of
+// the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+// License for the specific language governing permissions and limitations 
under
+// the License.
+
+define([
+  "app/helpers",
+  "api",
+  "react",
+  "addons/activetasks/stores",
+  "addons/activetasks/resources",
+  "addons/activetasks/actions"
+
+], function (Helpers, FauxtonAPI, React, Stores, Resources, Actions) {
+  var activeTasksStore = Stores.activeTasksStore;
+
+  var ActiveTasksController = React.createClass({
+
+getStoreState: function () {
+  return {  
+selectedTab: activeTasksStore.getSelectedTab(),
+collection: activeTasksStore.getCollection(),
+searchTerm: activeTasksStore.getSearchTerm(),
+setPolling: activeTasksStore.setPolling(),
+clearPolling: activeTasksStore.clearPolling
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+componentDidMount: function () {
+  this.state.setPolling;
+  activeTasksStore.on('change', this.onChange, this);  
+},
+
+componentWillUnmount: function() {
+  this.state.clearPolling();
+  activeTasksStore.off('change', this.onChange, this); 
+},
+onChange: function () {
+  this.setState(this.getStoreState());
+},
+render: function () {
+  var collection = this.state.collection; 
+  var searchTerm = this.state.searchTerm;
+  var selectedTab = this.state.selectedTab;
+
+  if (collection.length === 0 ) {
+return (   No tasks. 
 );
+  } else {
+return (
+  
+
+  
+  
+
+  
+);
+  }
+}
+  });
+
+  var ActiveTasksFilterHeader = React.createClass({ //This is for the 
little '+ Filter' Tab 
+getStoreState: function () {
+  return {  
+searchTerm: activeTasksStore.getSearchTerm()
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+toggleFilter: function () {
+  $('#dashboard-content').scrollTop(0);
+  $('#query').toggle('slow');
+},
+setNewSearchTerm: function (e) {
+  this.setState({searchTerm: e.target.value});
+  Actions.setSearchTerm(e.target.value);
+},
+render: function () {
+  var searchTerm = this.state.searchTerm;
+  return (
+
+  
+
+  
+
+  Filter
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  );
+}
+  });
+
+  var ActiveTaskTable = React.createClass({
+getInfo: function (item) {
+  return {
+type : item.get('type'),
+objectField : this.getDatabaseFieldMessage(item) ,
+started_on : this.getTimeInfo(item.get('started_on')), 
+updated_on : this.getTimeInfo(item.get('updated_on')),
+pid : item.get('pid').replace(/[<>]/g, ''),
+progress : this.getProgressMessage(item),
+  };
+},
+getTimeInfo: function (timeStamp) {
+  var timeMessage = [Helpers.formatDate(timeStamp)];
+  timeMessage.push(Helpers.getDateFromNow(timeStamp));
+  return timeMessage;
+},
+getDatabaseFieldMessage: function (model) {
+  var type = model.get('type');
+  var databaseFieldMessage = [];
+
+  if (type === 'replication') {
+databaseFieldMessage.push('From: ' + model.get('source'));
+databaseFieldMessage.push('To: ' + model.get('target'));
+  } else if (type === 'indexer') {
+databaseFieldMessage.push(model.get('database'));
+databaseFieldMessage.push('(View: ' + model.get('design_document') 
+ '

[GitHub] couchdb-fauxton pull request: Active tasks in react

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/317#discussion_r26471457
  
--- Diff: app/addons/activetasks/components.react.jsx ---
@@ -0,0 +1,387 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you may 
not
+// use this file except in compliance with the License. You may obtain a 
copy of
+// the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+// License for the specific language governing permissions and limitations 
under
+// the License.
+
+define([
+  "app/helpers",
+  "api",
+  "react",
+  "addons/activetasks/stores",
+  "addons/activetasks/resources",
+  "addons/activetasks/actions"
+
+], function (Helpers, FauxtonAPI, React, Stores, Resources, Actions) {
+  var activeTasksStore = Stores.activeTasksStore;
+
+  var ActiveTasksController = React.createClass({
+
+getStoreState: function () {
+  return {  
+selectedTab: activeTasksStore.getSelectedTab(),
+collection: activeTasksStore.getCollection(),
+searchTerm: activeTasksStore.getSearchTerm(),
+setPolling: activeTasksStore.setPolling(),
+clearPolling: activeTasksStore.clearPolling
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+componentDidMount: function () {
+  this.state.setPolling;
+  activeTasksStore.on('change', this.onChange, this);  
+},
+
+componentWillUnmount: function() {
+  this.state.clearPolling();
+  activeTasksStore.off('change', this.onChange, this); 
+},
+onChange: function () {
+  this.setState(this.getStoreState());
+},
+render: function () {
+  var collection = this.state.collection; 
+  var searchTerm = this.state.searchTerm;
+  var selectedTab = this.state.selectedTab;
+
+  if (collection.length === 0 ) {
+return (   No tasks. 
 );
+  } else {
+return (
+  
+
+  
+  
+
+  
+);
+  }
+}
+  });
+
+  var ActiveTasksFilterHeader = React.createClass({ //This is for the 
little '+ Filter' Tab 
+getStoreState: function () {
+  return {  
+searchTerm: activeTasksStore.getSearchTerm()
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+toggleFilter: function () {
+  $('#dashboard-content').scrollTop(0);
+  $('#query').toggle('slow');
+},
+setNewSearchTerm: function (e) {
+  this.setState({searchTerm: e.target.value});
+  Actions.setSearchTerm(e.target.value);
+},
+render: function () {
+  var searchTerm = this.state.searchTerm;
+  return (
+
+  
+
+  
+
+  Filter
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  );
+}
+  });
+
+  var ActiveTaskTable = React.createClass({
+getInfo: function (item) {
+  return {
+type : item.get('type'),
+objectField : this.getDatabaseFieldMessage(item) ,
+started_on : this.getTimeInfo(item.get('started_on')), 
+updated_on : this.getTimeInfo(item.get('updated_on')),
+pid : item.get('pid').replace(/[<>]/g, ''),
+progress : this.getProgressMessage(item),
+  };
+},
+getTimeInfo: function (timeStamp) {
+  var timeMessage = [Helpers.formatDate(timeStamp)];
+  timeMessage.push(Helpers.getDateFromNow(timeStamp));
+  return timeMessage;
+},
+getDatabaseFieldMessage: function (model) {
+  var type = model.get('type');
+  var databaseFieldMessage = [];
+
+  if (type === 'replication') {
+databaseFieldMessage.push('From: ' + model.get('source'));
+databaseFieldMessage.push('To: ' + model.get('target'));
+  } else if (type === 'indexer') {
+databaseFieldMessage.push(model.get('database'));
+databaseFieldMessage.push('(View: ' + model.get('design_document') 
+ '

[GitHub] couchdb-fauxton pull request: Active tasks in react

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/317#discussion_r26471294
  
--- Diff: app/addons/activetasks/components.react.jsx ---
@@ -0,0 +1,387 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you may 
not
+// use this file except in compliance with the License. You may obtain a 
copy of
+// the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+// License for the specific language governing permissions and limitations 
under
+// the License.
+
+define([
+  "app/helpers",
+  "api",
+  "react",
+  "addons/activetasks/stores",
+  "addons/activetasks/resources",
+  "addons/activetasks/actions"
+
+], function (Helpers, FauxtonAPI, React, Stores, Resources, Actions) {
+  var activeTasksStore = Stores.activeTasksStore;
+
+  var ActiveTasksController = React.createClass({
+
+getStoreState: function () {
+  return {  
+selectedTab: activeTasksStore.getSelectedTab(),
+collection: activeTasksStore.getCollection(),
+searchTerm: activeTasksStore.getSearchTerm(),
+setPolling: activeTasksStore.setPolling(),
+clearPolling: activeTasksStore.clearPolling
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+componentDidMount: function () {
+  this.state.setPolling;
+  activeTasksStore.on('change', this.onChange, this);  
+},
+
+componentWillUnmount: function() {
+  this.state.clearPolling();
+  activeTasksStore.off('change', this.onChange, this); 
+},
+onChange: function () {
+  this.setState(this.getStoreState());
+},
+render: function () {
+  var collection = this.state.collection; 
+  var searchTerm = this.state.searchTerm;
+  var selectedTab = this.state.selectedTab;
+
+  if (collection.length === 0 ) {
+return (   No tasks. 
 );
+  } else {
+return (
+  
+
+  
+  
+
+  
+);
+  }
+}
+  });
+
+  var ActiveTasksFilterHeader = React.createClass({ //This is for the 
little '+ Filter' Tab 
+getStoreState: function () {
+  return {  
+searchTerm: activeTasksStore.getSearchTerm()
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+toggleFilter: function () {
+  $('#dashboard-content').scrollTop(0);
+  $('#query').toggle('slow');
+},
+setNewSearchTerm: function (e) {
+  this.setState({searchTerm: e.target.value});
--- End diff --

If you are storing the searchTerm in the store then you don't need to store 
it in the state.


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

[GitHub] couchdb-fauxton pull request: Active tasks in react

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/317#discussion_r26471215
  
--- Diff: app/addons/activetasks/components.react.jsx ---
@@ -0,0 +1,387 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you may 
not
+// use this file except in compliance with the License. You may obtain a 
copy of
+// the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+// License for the specific language governing permissions and limitations 
under
+// the License.
+
+define([
+  "app/helpers",
+  "api",
+  "react",
+  "addons/activetasks/stores",
+  "addons/activetasks/resources",
+  "addons/activetasks/actions"
+
+], function (Helpers, FauxtonAPI, React, Stores, Resources, Actions) {
+  var activeTasksStore = Stores.activeTasksStore;
+
+  var ActiveTasksController = React.createClass({
+
+getStoreState: function () {
+  return {  
+selectedTab: activeTasksStore.getSelectedTab(),
+collection: activeTasksStore.getCollection(),
+searchTerm: activeTasksStore.getSearchTerm(),
+setPolling: activeTasksStore.setPolling(),
+clearPolling: activeTasksStore.clearPolling
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+componentDidMount: function () {
+  this.state.setPolling;
+  activeTasksStore.on('change', this.onChange, this);  
+},
+
+componentWillUnmount: function() {
+  this.state.clearPolling();
+  activeTasksStore.off('change', this.onChange, this); 
+},
+onChange: function () {
+  this.setState(this.getStoreState());
+},
+render: function () {
+  var collection = this.state.collection; 
+  var searchTerm = this.state.searchTerm;
+  var selectedTab = this.state.selectedTab;
+
+  if (collection.length === 0 ) {
+return (   No tasks. 
 );
+  } else {
+return (
+  
+
+  
+  
+
+  
+);
+  }
+}
+  });
+
+  var ActiveTasksFilterHeader = React.createClass({ //This is for the 
little '+ Filter' Tab 
+getStoreState: function () {
+  return {  
+searchTerm: activeTasksStore.getSearchTerm()
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+toggleFilter: function () {
--- End diff --

This needs to be changed to use CSS animations instead of jQuery


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

[GitHub] couchdb-fauxton pull request: Active tasks in react

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/317#discussion_r26471136
  
--- Diff: app/addons/activetasks/components.react.jsx ---
@@ -0,0 +1,387 @@
+// Licensed under the Apache License, Version 2.0 (the "License"); you may 
not
+// use this file except in compliance with the License. You may obtain a 
copy of
+// the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT
+// WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+// License for the specific language governing permissions and limitations 
under
+// the License.
+
+define([
+  "app/helpers",
+  "api",
+  "react",
+  "addons/activetasks/stores",
+  "addons/activetasks/resources",
+  "addons/activetasks/actions"
+
+], function (Helpers, FauxtonAPI, React, Stores, Resources, Actions) {
+  var activeTasksStore = Stores.activeTasksStore;
+
+  var ActiveTasksController = React.createClass({
+
+getStoreState: function () {
+  return {  
+selectedTab: activeTasksStore.getSelectedTab(),
+collection: activeTasksStore.getCollection(),
+searchTerm: activeTasksStore.getSearchTerm(),
+setPolling: activeTasksStore.setPolling(),
+clearPolling: activeTasksStore.clearPolling
+  };
+},
+
+getInitialState: function () {
+  return this.getStoreState();
+},
+
+componentDidMount: function () {
+  this.state.setPolling;
--- End diff --

Do you mean `this.state.setPolling()`?


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

[GitHub] couchdb-fauxton pull request: Call JSX build in a way that works o...

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/318#discussion_r26470977
  
--- Diff: Gruntfile.js ---
@@ -407,7 +407,7 @@ module.exports = function(grunt) {
 shell: {
 'build-jsx': {
 command: [
-  './node_modules/react-tools/bin/jsx -x jsx app/addons/ 
app/addons/',
+  'node ./node_modules/react-tools/bin/jsx -x jsx app/addons/ 
app/addons/',
 'rm -rf <%= src_path %>/js/app/views/.module-cache/'
--- End diff --

will `rm -rf` work on a windows machine?


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

[GitHub] couchdb-fauxton pull request: Call JSX build in a way that works o...

[garrensmith]

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

https://github.com/apache/couchdb-fauxton/pull/318#discussion_r26471014
  
--- Diff: Gruntfile.js ---
@@ -407,7 +407,7 @@ module.exports = function(grunt) {
 shell: {
 'build-jsx': {
 command: [
-  './node_modules/react-tools/bin/jsx -x jsx app/addons/ 
app/addons/',
+  'node ./node_modules/react-tools/bin/jsx -x jsx app/addons/ 
app/addons/',
 'rm -rf <%= src_path %>/js/app/views/.module-cache/'
--- End diff --

Actually that whole line can be removed since it actually doesn't work. The 
`.module-cache` isn't saved to that directory.


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

GSoc 2015 | COUCHDB-1743 Make the view server & protocol faster

[Buddhika Jayawardhana]

Hi,
I am an Undergraduate of Department of Computer Science and Engineering
University of Moratuwa. I have been subscribed to couchdb mailing list
since months and I have been trying to learn some Erlang to work with
couchdb. I noticed project  "COUCHDB-1743 Make the view server & protocol
faster" is related to GSoC. I am willing to submit a project proposal for
this project.

I have theoretical knowledge in software process, design patterns, and
other Engineering concepts. I've been using 'java', 'C++' for high-level
programming and 'C', a little bit of assembly for low-level programming and
PHP and JavaScript  for web development. Also I have sound knowledge  on
Erlang. I would be much thankful if you can guide to get familiar with the
project as soon as possible.

Here are the problems in my mind

   - Are the other programming languages that I should get familiar with?
   - What are the technologies I should get familiar with?
   - I can work 40 hours per week for the project. Would that be enough to
   successfully complete the prject?
   - What are the other resources that I should read before submitting the
   proposal?

Hope you will guide me through the project.
Thank You.

-- 
*Buddhika Jayawardhana*
Undergraduate | Department of Computer Science & Engineering
University of Moratuwa
*buddhika...@cse.mrt.ac.lk * | LinkedIn

Re: Stepping down (mostly)

[Garren Smith]

Hi Dirkjan,

Thanks for all your help. Hope to see you around when the opportunity presents 
itself.

Cheers
Garren

> On 16 Mar 2015, at 1:19 AM, Klaus Trainer  wrote:
> 
> Hi Dirkjan,
> 
> thanks for everything you've contributed during the last years :)
> 
> All the best,
> Klaus
> 
> 
> On 03/15/2015 11:12 AM, Dirkjan Ochtman wrote:
>> Hi all,
>> 
>> Although I'd previously dropped hints about this in other email
>> threads, I wanted to make it explicit that I have stopped spending as
>> much time on CouchDB as I did in previous years. This means that I
>> won't spend time on the documentation or on release management
>> anymore. However, I'll still hang around on dev@ as a Gentoo packager
>> and as the CouchDB-Python maintainer.
>> 
>> With the recent growth of the committer group, I'm sure y'all can
>> handle things without me.
>> 
>> As a point of constructive criticism, the way dev@ gets ALL THE THINGS
>> currently (as in, Jira & GitHub notifications) isn't great for my kind
>> of usage. I think I've said this before, but personally I'd really
>> appreciate all the machine-generated email going on a separate list
>> from the human stuff.
>> 
>> Cheers,
>> 
>> Dirkjan
>> 

[jira] [Commented] (COUCHDB-2605) Visualize the CouchDB Cluster

[Alexander Shorin (JIRA)]

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

Alexander Shorin commented on COUCHDB-2605:
---

Hm, you seems to have a quite old clone if this error happened. Good to update 
it, reconfigure and make again to avoid other possible issues. Clean new 
checkout may be as well helpful.

> Visualize the CouchDB Cluster
> -
>
> Key: COUCHDB-2605
> URL: https://issues.apache.org/jira/browse/COUCHDB-2605
> Project: CouchDB
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: Fauxton
>Affects Versions: 2.1
>Reporter: Robert Kowalski
>  Labels: CouchDB, gsoc2015, javascript
>
> Show for each database on which nodes in the cluster the data is stored - and 
> warn if the disk space runs out on these nodes.
> The project is using React.js for the Admin-Interface. You will use 
> JavaScript, CSS, HTML and the HTTP API of CouchDB to visualize the cluster. 



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

[jira] [Commented] (COUCHDB-2605) Visualize the CouchDB Cluster

[Udantha (JIRA)]

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

Udantha commented on COUCHDB-2605:
--

Hi Alexander,

In 'node1.log' I found blow error for missing file node1/data/nodes.couch
2015-03-15 17:01:35.936 [error] node1@127.0.0.1 <0.384.0> Could not open file 
/home/max/test/couchDB/couchdb/dev/lib/node1/data/nodes.couch: no such file or 
directory
2015-03-15 17:01:35.936 [info] node1@127.0.0.1 <0.226.0> open_result error 
{not_found,no_db_file} for nodes
2015-03-15 17:01:35.937 [debug] node1@127.0.0.1 <0.237.0> httpd 404 error 
response:
 {"error":"not_found","reason":"no_db_file"}

So I check the dir for node1/data/nodes.couch. Here is files in that dir.

max@max-VirtualBox ~/test/couchDB/couchdb/dev/lib/node1/data $ ls -l
total 44
-rw-r--r-- 1 max max 4242 Mar 15 16:42 _dbs.couch
-rw-r--r-- 1 max max 8370 Mar 15 16:42 _nodes.couch
-rw-r--r-- 1 max max 8376 Mar 15 16:42 _replicator.couch
-rw-r--r-- 1 max max 8376 Mar 15 16:41 _users.couch

It search for 'nodes.couch' and it have '_nodes.couch'. I fixed it now terminal 
is showing

Join nodes into cluster... ok
Developers cluster is set up at http://127.0.0.1:15984. Time to hack!... 

Thanks



> Visualize the CouchDB Cluster
> -
>
> Key: COUCHDB-2605
> URL: https://issues.apache.org/jira/browse/COUCHDB-2605
> Project: CouchDB
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: Fauxton
>Affects Versions: 2.1
>Reporter: Robert Kowalski
>  Labels: CouchDB, gsoc2015, javascript
>
> Show for each database on which nodes in the cluster the data is stored - and 
> warn if the disk space runs out on these nodes.
> The project is using React.js for the Admin-Interface. You will use 
> JavaScript, CSS, HTML and the HTTP API of CouchDB to visualize the cluster. 



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