I wish we could do something about the spam.
I don't like playing whackamole.
Randall, I disagree with this change.
While it's ok for local databases, it causes noise for remote
databases, as the httpc pool is linked to the main replication
gen_server and it starts receiving EXIT messages from the later when
it finishes normally (without errors).
Look at the following
On Mon, Jun 13, 2011 at 5:23 AM, Noah Slater nsla...@apache.org wrote:
I wish we could do something about the spam.
I don't like playing whackamole.
We could delete the wiki and create real docs.
On Mon, Jun 13, 2011 at 5:34 AM, Paul Davis paul.joseph.da...@gmail.com wrote:
On Mon, Jun 13, 2011 at 5:23 AM, Noah Slater nsla...@apache.org wrote:
I wish we could do something about the spam.
I don't like playing whackamole.
We could delete the wiki and create real docs.
+1 .
What percentage of useful wiki edits were made by committers vs non-committers?
On 13 Jun 2011, at 13:41, Benoit Chesneau wrote:
On Mon, Jun 13, 2011 at 5:34 AM, Paul Davis paul.joseph.da...@gmail.com
wrote:
On Mon, Jun 13, 2011 at 5:23 AM, Noah Slater nsla...@apache.org wrote:
I wish we
+1 to deleting the wiki and +1 to real docs.
B.
On 13 June 2011 13:49, Noah Slater nsla...@apache.org wrote:
What percentage of useful wiki edits were made by committers vs
non-committers?
On 13 Jun 2011, at 13:41, Benoit Chesneau wrote:
On Mon, Jun 13, 2011 at 5:34 AM, Paul Davis
On Mon, Jun 13, 2011 at 5:49 AM, Noah Slater nsla...@apache.org wrote:
What percentage of useful wiki edits were made by committers vs
non-committers?
We could have edit from users too or just mails on non wiki systems.
For example on gunicorn, The users open a ticket with a correction. Or
On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote:
What percentage of useful wiki edits were made by committers vs
non-committers?
http://en.wikipedia.org/wiki/Toilet_paper_orientation
On 13 Jun 2011, at 13:41, Benoit Chesneau wrote:
On Mon, Jun 13, 2011 at 5:34 AM,
On 13 Jun 2011, at 13:55, Paul Davis wrote:
On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote:
What percentage of useful wiki edits were made by committers vs
non-committers?
http://en.wikipedia.org/wiki/Toilet_paper_orientation
Not sure how this is relevant.
If we
On Jun 13, 2011, at 9:13 AM, Noah Slater wrote:
On 13 Jun 2011, at 13:55, Paul Davis wrote:
On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote:
What percentage of useful wiki edits were made by committers vs
non-committers?
On Mon, Jun 13, 2011 at 6:18 AM, Robert Dionne
dio...@dionne-associates.com wrote:
On Jun 13, 2011, at 9:13 AM, Noah Slater wrote:
On 13 Jun 2011, at 13:55, Paul Davis wrote:
On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote:
What percentage of useful wiki edits were
On Mon, Jun 13, 2011 at 9:13 AM, Noah Slater nsla...@apache.org wrote:
On 13 Jun 2011, at 13:55, Paul Davis wrote:
On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote:
What percentage of useful wiki edits were made by committers vs
non-committers?
On Mon, Jun 13, 2011 at 15:31, Paul Davis paul.joseph.da...@gmail.com wrote:
The mode of contribution changes. There is nothing that will suddenly
prevent people from contributing. Its just that making a contribution
becomes a JIRA issue instead of a wiki update. Under that light your
question
How many people didn't edit the wiki because it's a scary prospect to
edit the only form of documentation that there seems to be?
+1 to pinky fingers and monocles
Thanks
Clare
On 13/06/11 15:15, Dirkjan Ochtman wrote:
On Mon, Jun 13, 2011 at 15:31, Paul Davispaul.joseph.da...@gmail.com
Any documentation is good.
What is this 'spam'? Haven't personally encountered anything on the wiki
that would be 'considered' spam (perhaps not stumbled upon that portion?)
But it's inevitable that the wiki will be attacked by unscrupulous people
and as such, the wiki should prepare for this.
It's not the wiki per se that bothers me, it's that it's the primary,
often only, source of documentation.
I propose that future releases of CouchDB include at least a full
description of all public API's. Improvements above that base level
would be a manual and/or simple tutorials.
This
On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson robert.new...@gmail.com wrote:
It's not the wiki per se that bothers me, it's that it's the primary,
often only, source of documentation.
I propose that future releases of CouchDB include at least a full
description of all public API's.
On 13 Jun 2011, at 18:16, Peter Nolan wrote:
What is this 'spam'? Haven't personally encountered anything on the wiki
that would be 'considered' spam (perhaps not stumbled upon that portion?)
Because we nuke it as it arrives.
That's what prompted my original email.
But it's inevitable
On 13 Jun 2011, at 19:08, Paul Davis wrote:
You had me until you said release requirement. I would upgrade that
to commit requirement if we're seriously about having such
documentation. If we don't force people to make sure docs reflect
changes at commit time then its probably going to be a
++1
On Jun 13, 2011, at 2:05 PM, Robert Newson wrote:
It's not the wiki per se that bothers me, it's that it's the primary,
often only, source of documentation.
I propose that future releases of CouchDB include at least a full
description of all public API's. Improvements above that
++1++
On Jun 13, 2011, at 2:08 PM, Paul Davis wrote:
On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson robert.new...@gmail.com
wrote:
It's not the wiki per se that bothers me, it's that it's the primary,
often only, source of documentation.
I propose that future releases of CouchDB include
+1 for commit requirement in addition to being a release requirement.
At the very least, we get the docs fixed during the release process,
but it ought to be done with the commit itself. In practice, we'll
forget sometimes, and then be reminded by others on the team.
B.
On 13 June 2011 19:17,
Didn't couch/couchone/couchbase/whateveritscalledthisweek hire a writer?
If you need a writer for documentation I'm more than willing to contribute.
Eye dun rite gud.
On Mon, Jun 13, 2011 at 2:27 PM, Robert Newson robert.new...@gmail.com wrote:
+1 for commit requirement in addition to being a release requirement.
At the very least, we get the docs fixed during the release process,
but it ought to be done with the commit itself. In practice, we'll
forget
Also we should jab them with forks.
On 13 June 2011 19:28, Paul Davis paul.joseph.da...@gmail.com wrote:
On Mon, Jun 13, 2011 at 2:27 PM, Robert Newson robert.new...@gmail.com
wrote:
+1 for commit requirement in addition to being a release requirement.
At the very least, we get the docs
Yes, Peter, there is better documentation available for couchdb
outside of our the projects official site. That's part of the problem
we're addressing. The best place for couchdb documentation should be
couchdb.apache.org, like it is for most other Apache projects.
B.
On 13 June 2011 19:30,
It doesn't matter where the 'centralized' information is located, it just
needs to be centralized.
There are a bunch of great little bits of information scattered throughout
the internet, from blogs, to stackoverflow etc.
Out of curiosity, how hard is it to create plugins for firefox? If one
I'd argue that it matters a great deal. Our project should include
good documentation.
B.
On 13 June 2011 19:46, Peter Nolan peterwno...@gmail.com wrote:
It doesn't matter where the 'centralized' information is located, it just
needs to be centralized.
There are a bunch of great little bits
The point that was trying to be made was that a database system that allows
such an extreme degree of decentralization (with replication and whatnot) is
that information is incredibly decentralized.
Having a location that contains all necessary documentation is incredibly
important.
[
https://issues.apache.org/jira/browse/COUCHDB-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Kögl updated COUCHDB-994:
Attachment: 2011-06-13-couchdb.log
I've applied the patch from
On Mon, Jun 13, 2011 at 06:27, Filipe David Manana fdman...@apache.org wrote:
On Sun, Jun 12, 2011 at 9:46 PM, Randall Leeds randall.le...@gmail.com
wrote:
Looks like /usr/local/include and /usr/include are absent from the new
stuff. Can you confirm that those headers are in one of those
On Sun, Jun 12, 2011 at 4:46 PM, Randall Leeds randall.le...@gmail.com wrote:
Looks like /usr/local/include and /usr/include are absent from the new
stuff. Can you confirm that those headers are in one of those places?
I bet it's a difference in default search paths, else I can't explain why
I was just going through what we back ported to 1.1.x to make sure
that all the relevant commits are also on 1.0.x before rolling a
release. There are a few that are mostly trivial but I've come across
two that I'm a bit stumped on.
The first is this one:
*
On 13 Jun 2011, at 22:57, Paul Davis wrote:
Next time I make big autotools changes ill solicit more feedback on the
branch before I put it on trunk.
I would actually argue that you shouldn't bother. The build system is
always a little peculiar because no one has access to the large number
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13048969#comment-13048969
]
Jason Smith commented on COUCHDB-431:
-
I agree, Jacques. CORS will be the microwave
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13048972#comment-13048972
]
Benjamin Eidelman commented on COUCHDB-431:
---
I'm writing a small js lib that
36 matches
Mail list logo
