Re: Website redesign
On Mon, Jul 12, 2010 at 7:50 AM, Mikeal Rogers wrote: > That sounds like additional work someone isn't going to do. > > Featuring the planet more prominently leverages stuff we're already doing. > > -Mikeal > I wouldn't suppose about what people could do before asking. Why can't we do what some some people do on openbsd project, a completely independent and free project ? People already update wiki some times about event, post mails, some devs are speaking about new features on their commercial or personnal blog. Why not on the project website ? - benoit
Re: Website redesign
That sounds like additional work someone isn't going to do. Featuring the planet more prominently leverages stuff we're already doing. -Mikeal On Sun, Jul 11, 2010 at 10:34 PM, Benoit Chesneau wrote: > On Mon, Jul 12, 2010 at 7:06 AM, Mikeal Rogers > wrote: > >> > >> - We should have a blog on the website. The posts on couch.io are > >> nice, but for a neutral and community point of view, I would want to > >> seem some news features announcement done on the opensource couchdb > >> project too or on the mailing list. > >> > > > > The blog on the website should just pull from CouchDB Planet. > > > > http://planet.couchdb.org/ > > > > -Mikeal > > > > Aggregator != news . A planet is another tool. > > > I was thinking to a blog about > > - new events : where so is speaking about couch . A wiki page doesn't heko > - status showing new feature added + usecase, > > an ex could be: http://undeadly.org/ > > - benoit >
Re: Website redesign
On Mon, Jul 12, 2010 at 7:06 AM, Mikeal Rogers wrote: >> >> - We should have a blog on the website. The posts on couch.io are >> nice, but for a neutral and community point of view, I would want to >> seem some news features announcement done on the opensource couchdb >> project too or on the mailing list. >> > > The blog on the website should just pull from CouchDB Planet. > > http://planet.couchdb.org/ > > -Mikeal > Aggregator != news . A planet is another tool. I was thinking to a blog about - new events : where so is speaking about couch . A wiki page doesn't heko - status showing new feature added + usecase, an ex could be: http://undeadly.org/ - benoit
Re: Website redesign
On Mon, Jul 12, 2010 at 6:55 AM, Benoit Chesneau wrote: > - We should have a blog on the website. The posts on couch.io are > nice, but for a neutral and community point of view, I would want to > seem some news features announcement done on the opensource couchdb > project too or on the mailing list. > s/seem/find
Re: Website redesign
> > - We should have a blog on the website. The posts on couch.io are > nice, but for a neutral and community point of view, I would want to > seem some news features announcement done on the opensource couchdb > project too or on the mailing list. > The blog on the website should just pull from CouchDB Planet. http://planet.couchdb.org/ -Mikeal
Re: Website redesign
Hi, Looking at this new design today, and I'm really not a fan. Here are some points I want to highlight: - The first thing I could say is that I don't know i'm on a site speaking about a database before reading the text. And the font chosen (or the background color ?) doesn't help to read it. We shoud enhance the message we want to giv. - The layout doesn't give me the idea to go further in website exploration. I've a long overview without main points, Getting Started is at the bottom, no use case in the frontpage, ... - Main menu doesn't reflect what a user or a developer is looking. compare to the cassandra website for example. What I want as a user is to know how to get started, as a developer , how to contribute... Screenshots are not a sale point for a database. The website of an opensource projects should give in my opinion fast entries to each point of interest. I would like to have : - Download - Getting Started - Wiki/Documentation - Deploy - Contribute - News - We should have a blog on the website. The posts on couch.io are nice, but for a neutral and community point of view, I would want to seem some news features announcement done on the opensource couchdb project too or on the mailing list. - irc access: where is it ? Subjective point: the current graphic design looks so old. I really would like something more modern, insisting on typography and such. Maybe we could use some tools like http://960.gs/ to build a good site layout. etc. Maybe we could relaunch a second graphic contest with votes from the community ? (I don't really like the blue version too, for reason I exposed and were ignored). Hope this post could help to improve the new design. - benoit
Re: [VOTE] Apache CouchDB 0.11.1 release, second round
On Fri, Jul 9, 2010 at 6:55 PM, Noah Slater wrote: > Hello, > > I would like call a vote for the Apache CouchDB 0.11.1 release, second round. > > Changes in this round: > > * Fixed various leftovers from internal refactoring > > We encourage the whole community to download and test these release artifacts > so > that any critical issues can be resolved before the release is made. Everyone > is > free to vote on this release, so get stuck in! > > We are voting on the following release artifacts: > > http://people.apache.org/~nslater/dist/0.11.1/ > > These artifacts have been built from the 0.11.1 tag in Subversion: > > http://svn.apache.org/repos/asf/couchdb/tags/0.11.1/ > > Happy voting, > > N +1 js tests pass make check pass tested with some applications tested on OpenBSD 4.7-current (erlang R13B04), OSX 10.6.4 (erlang R14a)
Re: [VOTE] Apache CouchDB 1.0.0 release, second round
On Fri, Jul 9, 2010 at 6:55 PM, Noah Slater wrote: > Hello, > > I would like call a vote for the Apache CouchDB 1.0.0 release, second round. > > Changes in this round: > > * Fixed various leftovers from internal refactoring > > We encourage the whole community to download and test these release artifacts > so > that any critical issues can be resolved before the release is made. Everyone > is > free to vote on this release, so get stuck in! > > We are voting on the following release artifacts: > > http://people.apache.org/~nslater/dist/1.0.0/ > > These artifacts have been built from the 1.0.0 tag in Subversion: > > http://svn.apache.org/repos/asf/couchdb/tags/1.0.0/ > > Happy voting, > > N + 1 js tests pass make check pass tested with some applications tested on OpenBSD 4.7-current (erlang R13B04), OSX 10.6.4 (erlang R14a)
[jira] Created: (COUCHDB-824) _active_tasks should hide password in source and target url
_active_tasks should hide password in source and target url
---
Key: COUCHDB-824
URL: https://issues.apache.org/jira/browse/COUCHDB-824
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 0.11
Reporter: can xiang
Priority: Minor
can we hide password in the _active_tasks API.
[{"type":"Replication","task":"c13e38:
https://replication:passw...@8.8.8.8:5984/somedb/ ->
some_db","status":"Starting","pid":"<0.1658.317>"}
I'd like to have this:
[{"type":"Replication","task":"c13e38:
https://replication:*...@8.8.8.8:5984/somedb/ ->
some_db","status":"Starting","pid":"<0.1658.317>"}
I think the fix would be trivial.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-823) _active_tasks dies often and doesn't accurately report replication status.
[
https://issues.apache.org/jira/browse/COUCHDB-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887262#action_12887262
]
can xiang commented on COUCHDB-823:
---
Hi, Randall
Thanks for your comment, it's helpful. Replications always in sync right now.
Although I have a watchdog monitoring the _active_tasks and tries to
"start"(not restart) the replication, I don't think there is any dead
replication hangs on there.
It's very interesting that you mentioned when the task is up to date, the
replication task would simply don't show up, which I thought is dead. If it's
true, I'd think it's a bug.
Is there any built-in restart/retry process for the continuous replication (in
case of broken connection)? Can I just remove the watchdog and let couchdb do
it by itself?
> _active_tasks dies often and doesn't accurately report replication status.
> --
>
> Key: COUCHDB-823
> URL: https://issues.apache.org/jira/browse/COUCHDB-823
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.11
> Environment: 1. pull replication
> 2. password protected nginx SSL reverse-proxied source database
> 3. A replication restart watchdog have been put in use in case of replication
> die
> 4. we use centos-5.4 and couchdb-0.11-dist built from source
> 5. inter-datacenter connection is slow and have great latency like 80ms~150ms
> in rush hour.
> PS: the nginx configuration:
> server {
> listen 5984;
> server_name xxx.xxx.xxx.xxx;
> client_max_body_size 10M;
> ssl on;
> ssl_certificate /usr/local/nginx/conf/cert/
> cert.pem;
> ssl_certificate_key /usr/local/nginx/conf/cert/cert.key;
> ssl_protocols SSLv3;
> ssl_session_cache shared:SSL:1m;
> location / {
> auth_basic "Restricted";
> auth_basic_user_file /usr/local/nginx/conf/htpasswd;
> proxy_pass http://couchdb;
> proxy_redirect off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Authorization "";
> proxy_set_header X-Forwarded-Ssl on;
> }
> location ~ ^/(.*)/_changes {
> auth_basic "Restricted";
> auth_basic_user_file /usr/local/nginx/conf/htpasswd;
> proxy_pass http://couchdb;
> proxy_redirect off;
> proxy_buffering off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Authorization "";
> proxy_set_header X-Forwarded-Ssl on;
> }
> }
>Reporter: can xiang
>
> 1. continuous replication died often as _active_tasks shows
> 2. _active_tasks often shows "starting..." instead of "W ..." or "MR...". I
> have 8 databases to replicate and I often see only two replication marked as
> "W.." or "MR...", others marked as "starting..."
> when the task marked as "starting...", I monitored actual replication
> happened to the relevant database.
> I don't know if it's a bug or I have any problem with my configurations. I
> tried to send a email to the user list several times, but they all got
> rejected as a spam(I tried with other email too).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Apache CouchDB 1.0.0 release, second round
On 11/07/2010 2:06 AM, Eric Carlson wrote: Haven't yet managed to get Erlang R14A/Couch to build successfully on Windows. Has anyone else? I successfully built R14A and the couch trunk a week or so ago and reported the results here (which I believe were subsequently addressed). Unfortunately I'm probably not going to get a chance to try again until I return from my current trip - about a week away... Mark
[jira] Commented: (COUCHDB-823) _active_tasks dies often and doesn't accurately report replication status.
[
https://issues.apache.org/jira/browse/COUCHDB-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887249#action_12887249
]
Randall Leeds commented on COUCHDB-823:
---
A continuous replication task will show "starting..." indefinitely until a
document is transferred. If your databases are already in sync then it will
stay there until the first new write. With your replications dying often and
restarting automatically it could be that you're often up to date when the task
is started.
Are your replications behind? Are there documents on the source that haven't
made it to the target even while it still says "starting..."? If so, there are
two bugs: replications dying and replications hanging. It would be useful to
know which of these is happening.
Also, if you can provide any log output at the time when a replication died
that might be helpful in diagnosing the issue as well. Thanks!
> _active_tasks dies often and doesn't accurately report replication status.
> --
>
> Key: COUCHDB-823
> URL: https://issues.apache.org/jira/browse/COUCHDB-823
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.11
> Environment: 1. pull replication
> 2. password protected nginx SSL reverse-proxied source database
> 3. A replication restart watchdog have been put in use in case of replication
> die
> 4. we use centos-5.4 and couchdb-0.11-dist built from source
> 5. inter-datacenter connection is slow and have great latency like 80ms~150ms
> in rush hour.
> PS: the nginx configuration:
> server {
> listen 5984;
> server_name xxx.xxx.xxx.xxx;
> client_max_body_size 10M;
> ssl on;
> ssl_certificate /usr/local/nginx/conf/cert/
> cert.pem;
> ssl_certificate_key /usr/local/nginx/conf/cert/cert.key;
> ssl_protocols SSLv3;
> ssl_session_cache shared:SSL:1m;
> location / {
> auth_basic "Restricted";
> auth_basic_user_file /usr/local/nginx/conf/htpasswd;
> proxy_pass http://couchdb;
> proxy_redirect off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Authorization "";
> proxy_set_header X-Forwarded-Ssl on;
> }
> location ~ ^/(.*)/_changes {
> auth_basic "Restricted";
> auth_basic_user_file /usr/local/nginx/conf/htpasswd;
> proxy_pass http://couchdb;
> proxy_redirect off;
> proxy_buffering off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Authorization "";
> proxy_set_header X-Forwarded-Ssl on;
> }
> }
>Reporter: can xiang
>
> 1. continuous replication died often as _active_tasks shows
> 2. _active_tasks often shows "starting..." instead of "W ..." or "MR...". I
> have 8 databases to replicate and I often see only two replication marked as
> "W.." or "MR...", others marked as "starting..."
> when the task marked as "starting...", I monitored actual replication
> happened to the relevant database.
> I don't know if it's a bug or I have any problem with my configurations. I
> tried to send a email to the user list several times, but they all got
> rejected as a spam(I tried with other email too).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-823) _active_tasks dies often and doesn't accurately report replication status.
[
https://issues.apache.org/jira/browse/COUCHDB-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887243#action_12887243
]
can xiang commented on COUCHDB-823:
---
Hi, Jan
Thanks for your attention on the email issue. I don't know the content-type, I
use gmail web mail. I kept getting this: The error that the other server
returned was: 552 552 spam score (5.8) exceeded threshold (state 18).
I tried at least two other gmail account in three different times with and
without a proxy in US. You know the pain.
> _active_tasks dies often and doesn't accurately report replication status.
> --
>
> Key: COUCHDB-823
> URL: https://issues.apache.org/jira/browse/COUCHDB-823
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.11
> Environment: 1. pull replication
> 2. password protected nginx SSL reverse-proxied source database
> 3. A replication restart watchdog have been put in use in case of replication
> die
> 4. we use centos-5.4 and couchdb-0.11-dist built from source
> 5. inter-datacenter connection is slow and have great latency like 80ms~150ms
> in rush hour.
> PS: the nginx configuration:
> server {
> listen 5984;
> server_name xxx.xxx.xxx.xxx;
> client_max_body_size 10M;
> ssl on;
> ssl_certificate /usr/local/nginx/conf/cert/
> cert.pem;
> ssl_certificate_key /usr/local/nginx/conf/cert/cert.key;
> ssl_protocols SSLv3;
> ssl_session_cache shared:SSL:1m;
> location / {
> auth_basic "Restricted";
> auth_basic_user_file /usr/local/nginx/conf/htpasswd;
> proxy_pass http://couchdb;
> proxy_redirect off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Authorization "";
> proxy_set_header X-Forwarded-Ssl on;
> }
> location ~ ^/(.*)/_changes {
> auth_basic "Restricted";
> auth_basic_user_file /usr/local/nginx/conf/htpasswd;
> proxy_pass http://couchdb;
> proxy_redirect off;
> proxy_buffering off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Authorization "";
> proxy_set_header X-Forwarded-Ssl on;
> }
> }
>Reporter: can xiang
>
> 1. continuous replication died often as _active_tasks shows
> 2. _active_tasks often shows "starting..." instead of "W ..." or "MR...". I
> have 8 databases to replicate and I often see only two replication marked as
> "W.." or "MR...", others marked as "starting..."
> when the task marked as "starting...", I monitored actual replication
> happened to the relevant database.
> I don't know if it's a bug or I have any problem with my configurations. I
> tried to send a email to the user list several times, but they all got
> rejected as a spam(I tried with other email too).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-823) _active_tasks dies often and doesn't accurately report replication status.
[
https://issues.apache.org/jira/browse/COUCHDB-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887193#action_12887193
]
Jan Lehnardt commented on COUCHDB-823:
--
Sorry about your problems sending mails to the user list. Can you double check
if you are sending HTML emails?
> _active_tasks dies often and doesn't accurately report replication status.
> --
>
> Key: COUCHDB-823
> URL: https://issues.apache.org/jira/browse/COUCHDB-823
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.11
> Environment: 1. pull replication
> 2. password protected nginx SSL reverse-proxied source database
> 3. A replication restart watchdog have been put in use in case of replication
> die
> 4. we use centos-5.4 and couchdb-0.11-dist built from source
> 5. inter-datacenter connection is slow and have great latency like 80ms~150ms
> in rush hour.
> PS: the nginx configuration:
> server {
> listen 5984;
> server_name xxx.xxx.xxx.xxx;
> client_max_body_size 10M;
> ssl on;
> ssl_certificate /usr/local/nginx/conf/cert/
> cert.pem;
> ssl_certificate_key /usr/local/nginx/conf/cert/cert.key;
> ssl_protocols SSLv3;
> ssl_session_cache shared:SSL:1m;
> location / {
> auth_basic "Restricted";
> auth_basic_user_file /usr/local/nginx/conf/htpasswd;
> proxy_pass http://couchdb;
> proxy_redirect off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Authorization "";
> proxy_set_header X-Forwarded-Ssl on;
> }
> location ~ ^/(.*)/_changes {
> auth_basic "Restricted";
> auth_basic_user_file /usr/local/nginx/conf/htpasswd;
> proxy_pass http://couchdb;
> proxy_redirect off;
> proxy_buffering off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Authorization "";
> proxy_set_header X-Forwarded-Ssl on;
> }
> }
>Reporter: can xiang
>
> 1. continuous replication died often as _active_tasks shows
> 2. _active_tasks often shows "starting..." instead of "W ..." or "MR...". I
> have 8 databases to replicate and I often see only two replication marked as
> "W.." or "MR...", others marked as "starting..."
> when the task marked as "starting...", I monitored actual replication
> happened to the relevant database.
> I don't know if it's a bug or I have any problem with my configurations. I
> tried to send a email to the user list several times, but they all got
> rejected as a spam(I tried with other email too).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-823) _active_tasks dies often and doesn't accurately report replication status.
_active_tasks dies often and doesn't accurately report replication status.
--
Key: COUCHDB-823
URL: https://issues.apache.org/jira/browse/COUCHDB-823
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 0.11
Environment: 1. pull replication
2. password protected nginx SSL reverse-proxied source database
3. A replication restart watchdog have been put in use in case of replication
die
4. we use centos-5.4 and couchdb-0.11-dist built from source
5. inter-datacenter connection is slow and have great latency like 80ms~150ms
in rush hour.
PS: the nginx configuration:
server {
listen 5984;
server_name xxx.xxx.xxx.xxx;
client_max_body_size 10M;
ssl on;
ssl_certificate /usr/local/nginx/conf/cert/
cert.pem;
ssl_certificate_key /usr/local/nginx/conf/cert/cert.key;
ssl_protocols SSLv3;
ssl_session_cache shared:SSL:1m;
location / {
auth_basic "Restricted";
auth_basic_user_file /usr/local/nginx/conf/htpasswd;
proxy_pass http://couchdb;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Authorization "";
proxy_set_header X-Forwarded-Ssl on;
}
location ~ ^/(.*)/_changes {
auth_basic "Restricted";
auth_basic_user_file /usr/local/nginx/conf/htpasswd;
proxy_pass http://couchdb;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Authorization "";
proxy_set_header X-Forwarded-Ssl on;
}
}
Reporter: can xiang
1. continuous replication died often as _active_tasks shows
2. _active_tasks often shows "starting..." instead of "W ..." or "MR...". I
have 8 databases to replicate and I often see only two replication marked as
"W.." or "MR...", others marked as "starting..."
when the task marked as "starting...", I monitored actual replication happened
to the relevant database.
I don't know if it's a bug or I have any problem with my configurations. I
tried to send a email to the user list several times, but they all got rejected
as a spam(I tried with other email too).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Test
is this thing on? On 11 Jul 2010, at 08:57, Randall Leeds wrote: > testing your patience > > On Sat, Jul 10, 2010 at 22:59, J Chris Anderson wrote: >> >> On Jul 10, 2010, at 9:57 PM, Paul Davis wrote: >> >>> On Sat, Jul 10, 2010 at 5:31 PM, Noah Slater wrote: Testing ASF email setup. >>> >>> Testing ASF email reply setup. >> >> ohai, >> >> testing reply reply setup. #asf >>
