On Mon, Oct 3, 2011 at 10:17 AM, Noah Slater nsla...@apache.org wrote:
On 3 Oct 2011, at 16:03, Paul Davis wrote:
I would avoid writing our own IRC bot at almost any cost.
What happened to the Noah I used to know?
There's a difference between pet projects and robust systems for a serious
On Mon, Oct 3, 2011 at 10:39 AM, Noah Slater nsla...@apache.org wrote:
On 3 Oct 2011, at 16:32, Paul Davis wrote:
On Mon, Oct 3, 2011 at 10:17 AM, Noah Slater nsla...@apache.org wrote:
On 3 Oct 2011, at 16:03, Paul Davis wrote:
I would avoid writing our own IRC bot at almost any cost
On Sun, Oct 2, 2011 at 12:18 PM, Noah Slater nsla...@apache.org wrote:
On 2 Oct 2011, at 12:14, rand...@apache.org wrote:
+ -H, --http install %s cURL bindings (only avaiable\n
+ if package was built with cURL available)\n
What does this do?
Enables
On Sun, Oct 2, 2011 at 12:16 PM, Noah Slater nsla...@apache.org wrote:
On 2 Oct 2011, at 12:14, rand...@apache.org wrote:
* Adds long options
+ Options:\n
+ \n
+ -h, --help display a short help message and exit\n
+ -V, --version display version information
Looks like I should add the branch name to these emails and not number
them as part of the same push. I was quite confused why I had three
emails about the same commit till I realize Randall pushed the same
update onto three branches.
On Sun, Oct 2, 2011 at 6:14 AM, rand...@apache.org wrote:
that, or install them.
On 2 Oct 2011, at 19:14, Paul Davis wrote:
s/install/enable/ ?
On Sun, Oct 2, 2011 at 1:02 PM, Noah Slater nsla...@apache.org wrote:
On 2 Oct 2011, at 18:55, Paul Davis wrote:
On Sun, Oct 2, 2011 at 12:18 PM, Noah Slater nsla...@apache.org wrote:
On 2 Oct 2011, at 12:14, rand
.
This shouldn't screw up any checkouts but people relying on tracking
should update their local configurations so they keep getting commits.
And of course, committers should push commits to master and not trunk.
Apologies for the delay between my promised completion and now.
Paul Davis
On Thu, Sep 29
.
Also, thanks everyone for putting up with me as I try and get all of
the various pieces together. Hopefully the roughest roads are behind
us and we'll be getting our rainbows and unicorns here shortly.
Thanks,
Paul Davis
That sounds like a good plan to me. A better API for HTTP requests in
ETAP would be a welcome addition.
As to etap, its been refactored to be a single module so that you can
just drop it into the test directory and compile along with any
necessary test code. I've been meaning to make this update
opposition. Seeing as that's the case if I get a majority of
+1's from the committers I'll start disabling SVN access as soon as I see
the majority vote.
Paul Davis
see the
majority vote.
Paul Davis
--
Filipe David Manana,
Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men.
They're getting sneakier. Adding identica links to spam accounts next
to other people's entries.
I wonder if this is a person actually editing the page or a really
advanced spam bot. One makes me sad for the human race, the other in
pique's my curiosity.
On Tue, Sep 13, 2011 at 10:57 AM, Apache
Already done. Just forgot to close the ticket.
On Mon, Sep 12, 2011 at 5:00 PM, kowsik kow...@gmail.com wrote:
+1 There's also this:
https://issues.apache.org/jira/browse/COUCHDB-1265 (replication
introducing dups the _changes feed) Definitely would like that in
1.2.0.
K.
---
My only addition to this list:
Repeating a doc._id in a _bulk_docs request results in erroneous
Document conflict error
https://issues.apache.org/jira/browse/COUCHDB-911
Bob Dionne has a patch and tests for it. The only concern is that this
is touching a noticeable amount of important code in
or that contains more than 10 byte ranges
That's an odd number. Is it specified in 2616 or something?
On Sun, Sep 11, 2011 at 10:50 AM, rnew...@apache.org wrote:
Author: rnewson
Date: Sun Sep 11 10:50:11 2011
New Revision: 1168196
URL: http://svn.apache.org/viewvc?rev=1168196view=rev
Log:
I think we got this straightened out on IRC, but the key here is that
the #full_doc_info{} gets the udpate_seq+1 value, but the #doc_info{}
record that's generated in couch_db_updater:new_index_entries ends up
only consulting the leaves of the revision tree to figure out which
update_seq to
On Sat, Aug 27, 2011 at 2:39 PM, Chris Anderson jch...@apache.org wrote:
Devs,
Couch has not had any sort of per-document access control in the past.
This is because it is deemed too much of burden on implementors of
secondary indexers (like GeoCouch, CouchDB Lucene, etc) to enforce
reader
On Sun, Aug 28, 2011 at 3:45 AM, Dustin Sallings dus...@spy.net wrote:
On Aug 26, 2011, at 6:10 PM, Paul Davis wrote:
The mirror:
http://git.apache.org/couchdb.git
The writable repo:
http://git-wip-us.apache.org/repos/asf/couchdb.git
I haven't looked into this at all yet myself
On Sat, Aug 27, 2011 at 3:35 PM, Randall Leeds randall.le...@gmail.com wrote:
On Sat, Aug 27, 2011 at 12:05, Chris Anderson jch...@apache.org wrote:
On Sat, Aug 27, 2011 at 9:14 AM, Benoit Chesneau bchesn...@gmail.com
wrote:
_security doc or object is something we need available each time
On Fri, Aug 26, 2011 at 3:13 AM, Dustin Sallings dus...@spy.net wrote:
On Aug 25, 2011, at 1:55 PM, Paul Davis wrote:
Oh right. Not entirely certain how fixable that's going to be.
On Thu, Aug 25, 2011 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:
On Aug 24, 2011, at 06:04 , Paul Davis
On Fri, Aug 26, 2011 at 5:58 PM, Randall Leeds randall.le...@gmail.com wrote:
On Aug 26, 2011 2:56 PM, Chris Anderson jch...@apache.org wrote:
On Thu, Aug 25, 2011 at 8:55 PM, Jason Smith j...@iriscouch.com wrote:
On Fri, Aug 26, 2011 at 8:59 AM, Paul Davis paul.joseph.da...@gmail.com
wrote
, 2011 at 7:12 PM, Dustin Sallings dus...@spy.net wrote:
On Aug 26, 2011, at 1:32 AM, Paul Davis wrote:
Basic story is that I translated the git.apache.org mirror script to
Python and made some tweaks (that shouldn't affect hashes) but the
hashes are apparently different. Original mirroring
On Fri, Aug 26, 2011 at 9:09 PM, Randall Leeds randall.le...@gmail.com wrote:
On Aug 26, 2011 4:31 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
On Fri, Aug 26, 2011 at 5:58 PM, Randall Leeds randall.le...@gmail.com
wrote:
On Aug 26, 2011 2:56 PM, Chris Anderson jch...@apache.org wrote
On Fri, Aug 26, 2011 at 10:01 PM, Jason Smith j...@iriscouch.com wrote:
On Sat, Aug 27, 2011 at 9:09 AM, Randall Leeds randall.le...@gmail.com
wrote:
The issue here is that adding a revision tree most likely means a
requirement that the HTTP API changes to use MVCC tokens.
_local docs
On Fri, Aug 26, 2011 at 10:17 PM, Filipe David Manana
fdman...@apache.org wrote:
On Fri, Aug 26, 2011 at 8:01 PM, Jason Smith j...@iriscouch.com wrote:
1. Does this require updating the replicator to update _local docs correctly?
Yes
2. Only admins can change _security. But anybody with read
On Fri, Aug 26, 2011 at 10:46 PM, Jason Smith j...@iriscouch.com wrote:
On Sat, Aug 27, 2011 at 10:17 AM, Filipe David Manana
fdman...@apache.org wrote:
On Fri, Aug 26, 2011 at 8:01 PM, Jason Smith j...@iriscouch.com wrote:
1. Does this require updating the replicator to update _local docs
Oh right. Not entirely certain how fixable that's going to be.
On Thu, Aug 25, 2011 at 3:49 PM, Jan Lehnardt j...@apache.org wrote:
On Aug 24, 2011, at 06:04 , Paul Davis wrote:
What commit-hash thing?
Where the commit hashes in current git.a.o are different from the test repo.
Cheers
On Thu, Aug 25, 2011 at 6:03 PM, Chris Anderson jch...@apache.org wrote:
MVCC semantics would be helpful for the _security object.
If caching + aliasing it to _local/security is the easier way to add
this, then I think it is OK.
OTOH it would probably be simple to add a basic (local docs)
On Thu, Aug 25, 2011 at 7:35 PM, Chris Anderson jch...@apache.org wrote:
On Thu, Aug 25, 2011 at 4:06 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
On Thu, Aug 25, 2011 at 6:03 PM, Chris Anderson jch...@apache.org wrote:
MVCC semantics would be helpful for the _security object
I bet you're hitting a bug we just recently fixed on trunk. Basically,
there was a possibility that errors in some of the JS functions would
end up causing a couchjs process to be come unusable without removing
it from the list. Eventually there wouldn't be any spots left and
clients would get
That link is to trunk. We should backport it to 1.1.x so it's in 1.1.1
as well. Perhaps even a 1.0.4.
On Wed, Aug 24, 2011 at 4:05 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Wed, Aug 24, 2011 at 1:53 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
I bet you're hitting
this, I can't wait.
Cheers
Jan
--
On Aug 22, 2011, at 05:55 , Paul Davis wrote:
Fellow Committers,
I've gotten a Git clone of the SVN repository configured to receive
actual writes. Now for everyone to try writing to it start causing
mischief.
Things that committers should do:
1. Clone
Its a commit summary email. We're testing Git hosting.
On Mon, Aug 22, 2011 at 12:25 PM, Noah Slater nsla...@apache.org wrote:
What is this?
On 22 Aug 2011, at 11:51, bitdid...@apache.org wrote:
davisp - GIT OK
Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
Commit:
hooks.
On Mon, Aug 22, 2011 at 12:38 PM, Noah Slater nsla...@apache.org wrote:
Was wondering why people are putting GIT OK after their name.
On 22 Aug 2011, at 18:32, Paul Davis wrote:
Its a commit summary email. We're testing Git hosting.
On Mon, Aug 22, 2011 at 12:25 PM, Noah Slater nsla
I should note, this isn't at all official. Still early testing phase. etc etc.
On Sun, Aug 21, 2011 at 10:55 PM, Paul Davis
paul.joseph.da...@gmail.com wrote:
Fellow Committers,
I've gotten a Git clone of the SVN repository configured to receive
actual writes. Now for everyone to try writing
I don't think its an issue that the 404 is there. It *is* deleted after all.
Though there's an argument to be made why we don't show the deleted body in the
response.
I would say that it should be a view option, but this will get a bit wonky for
you. You'll need to see if *any* of the views
On Tue, Aug 16, 2011 at 6:45 AM, Jan Lehnardt j...@apache.org wrote:
Hi Benoit,
thanks for raising this again. I think we have a good plan to get started but
it wouldn't hurt to get a little more organised. I think the plan is as
follows:
1. Move to git, this makes all the subsequent steps
Me and Adam were just mulling over a similar endpoint the other night
that could be used to generate plain-text backups similar to what
couchdb-dump and couchdb-load were doing. With the idea that there
would be some special sauce to pipe from one _dump endpoint directly
into a different _load
Not only should no one object, but infrastructure would object to
people objecting. :D
Thanks for helping with and cleaning up this release. I'll try and not
be moving across country when I do the next one.
On Tue, Aug 16, 2011 at 5:35 AM, Jan Lehnardt j...@apache.org wrote:
Hi,
in the spirit
On Tue, Aug 16, 2011 at 1:10 PM, Adam Kocoloski kocol...@apache.org wrote:
Wow, this thread got hijacked a bit :)
You must be new here.
On Tue, Aug 16, 2011 at 4:46 PM, Randall Leeds randall.le...@gmail.com wrote:
-1 on _skip_validation and new role
One can always write a validation document that considers the role, no? Why
can't users who need this functionality craft a validation function for this
purpose? This sounds like
300 versions of
node out there, and I'd hate for our tests to keep breaking because of node's
development pace. libcurl is nothing if not stable.
Adam
On Aug 14, 2011, at 12:55 PM, Paul Davis wrote:
My plan was to rewrite couch.js to use the new request/response
classes internally
Did a quick review. Posted to the ticket.
On Mon, Aug 15, 2011 at 8:29 PM, Filipe David Manana
fdman...@apache.org wrote:
Developers, users,
It's been a while now since I opened a Jira ticket for it (
https://issues.apache.org/jira/browse/COUCHDB-1153 ).
I won't describe it here with detail
already have this T(...) and TEquals() funs which seem to do the trick.
All that said, I have a few hours today to hack on this today if you want
some help just ping me on #couchdb
Bob
On Aug 12, 2011, at 11:46 AM, Paul Davis wrote:
Here's a bit of a brain dump on the sort
Here's a bit of a brain dump on the sort of environment I'd like to
see our CLI JS tests have. If anyone has any thoughts I'd like to hear
them. Otherwise I'll start hacking on this at some point over the
weekend.
https://gist.github.com/1142306
...@apache.org wrote:
On Wed, Aug 10, 2011 at 5:58 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
Since no one seems to have believed me I decided to take a closer look
I believe you, and in my machine, replication.js, takes about 120ms.
at replication.js tests. And as I pointed out
On Thu, Aug 11, 2011 at 3:47 AM, Jason Smith j...@iriscouch.com wrote:
On Thu, Aug 11, 2011 at 2:29 PM, Robert Newson rnew...@apache.org wrote:
I wonder if we should add a custom request header like
X-CouchDB-NoCache which sets all the cachebusting headers (Expires in
the paste, etc) rather
On Thu, Aug 11, 2011 at 5:57 AM, Jason Smith j...@iriscouch.com wrote:
On Thu, Aug 11, 2011 at 4:29 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
All very good except this one paragraph. The CouchDB definitely should
not be expected to run with an intermediary server. If an intermediary
On Wed, Aug 10, 2011 at 3:45 PM, fdman...@apache.org wrote:
Author: fdmanana
Date: Wed Aug 10 20:45:53 2011
New Revision: 1156360
URL: http://svn.apache.org/viewvc?rev=1156360view=rev
Log:
Prevent data loss on db creation request
1) Create and populate a database
2) Restart the server
On Wed, Aug 10, 2011 at 12:49 AM, Paul Davis
paul.joseph.da...@gmail.com wrote:
On Tue, Aug 9, 2011 at 8:11 PM, Filipe David Manana fdman...@apache.org
wrote:
On Mon, Aug 8, 2011 at 11:43 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
The entire test suite takes about 4 minutes to run
I've been running the Futon test suite quite a bit lately and I've
noticed that they starting to take quite a bit longer again.
The entire test suite takes about 4 minutes to run on a semi recent
MBA. Most of the tests are fairly speedy, but four of them stick out
quite drastically:
On Tue, Aug 9, 2011 at 2:40 AM, Robert Dionne
dio...@dionne-associates.com wrote:
Also, I've been thinking more and more about beefing up the JavaScript
test suite runner and moving more of our browser tests over to
dedicated code in those tests. If anyone's interested in hacking on
some C
, Paul Davis paul.joseph.da...@gmail.com wrote:
On Tue, Aug 9, 2011 at 2:40 AM, Robert Dionne
dio...@dionne-associates.com wrote:
Also, I've been thinking more and more about beefing up the JavaScript
test suite runner and moving more of our browser tests over to
dedicated code in those tests
On Tue, Aug 9, 2011 at 9:38 AM, Adam Kocoloski kocol...@apache.org wrote:
On Aug 9, 2011, at 4:48 AM, Paul Davis wrote:
On Tue, Aug 9, 2011 at 2:40 AM, Robert Dionne
dio...@dionne-associates.com wrote:
Also, I've been thinking more and more about beefing up the JavaScript
test suite runner
On Tue, Aug 9, 2011 at 4:04 PM, Dave Cottlehuber d...@muse.net.nz wrote:
On 10 August 2011 03:19, Paul Davis paul.joseph.da...@gmail.com wrote:
Also, yes. I've finally become irritated enough with clearing the
browser cache between every test that I feel its time to do something
productive
On Tue, Aug 9, 2011 at 5:30 PM, Randall Leeds randall.le...@gmail.com wrote:
On Tue, Aug 9, 2011 at 14:48, Paul Davis paul.joseph.da...@gmail.comwrote:
On Tue, Aug 9, 2011 at 4:04 PM, Dave Cottlehuber d...@muse.net.nz wrote:
On 10 August 2011 03:19, Paul Davis paul.joseph.da...@gmail.com
On Tue, Aug 9, 2011 at 8:11 PM, Filipe David Manana fdman...@apache.org wrote:
On Mon, Aug 8, 2011 at 11:43 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
The entire test suite takes about 4 minutes to run on a semi recent
MBA. Most of the tests are fairly speedy, but four of them stick
On Mon, Aug 8, 2011 at 1:14 PM, Dustin Sallings dus...@spy.net wrote:
On July 31, 2011 9:29:40 AM, Paul Davis wrote:
4. Before making the complete switch I'll end up making a handful of
Git clones to check that our history is preserved. I plan on writing a
script to make Graphviz images
to notice
merges and such, so those tools are superior to git-svn (assuming it's
not just a newer version of git-svn itself).
B.
On 8 August 2011 19:22, Paul Davis paul.joseph.da...@gmail.com wrote:
On Mon, Aug 8, 2011 at 1:14 PM, Dustin Sallings dus...@spy.net wrote:
On July 31, 2011 9:29:40
On Mon, Aug 8, 2011 at 1:57 PM, Dustin Sallings dus...@spy.net wrote:
[sorry for screwing up the subject]
On Aug 8, 2011, at 11:22 AM, Paul Davis wrote:
Nice! Any hints you have about validating SVN-Git conversions or
tooling would be greatly appreciated. I don't really have much
On Mon, Aug 8, 2011 at 2:23 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
On Mon, Aug 8, 2011 at 1:57 PM, Dustin Sallings dus...@spy.net wrote:
[sorry for screwing up the subject]
On Aug 8, 2011, at 11:22 AM, Paul Davis wrote:
Nice! Any hints you have about validating SVN-Git
:
+1
On Jul 31, 2011, at 12:29 PM, Paul Davis wrote:
Dearest Devs,
A few months ago I did some work in preparing a solution to using Git
as a primary VCS at the ASF. Now that we have released 1.1.0 and 1.0.3
there's a bit of a lull in large events dealing with the code base. As
such I
.
I am open to either method. The srcmv script I wrote a long time ago
to handle the SVN commands to make it happen would need a lot of
cleaning up to handle it though.
+1 for prohibiting merge commits to stable branches.
B.
On 31 July 2011 17:29, Paul Davis paul.joseph.da...@gmail.com wrote
On Thu, Jul 21, 2011 at 1:01 PM, Travis Jensen travis.jen...@gmail.com wrote:
So is there anything I can do to help solve this right or should I just
put my hack in place for now and call it good for the time being?
tj
We like to refer to it as organically grown. :D
But in seriousness, the
On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen travis.jen...@gmail.com wrote:
couch_httpd.erl seems to be confused about what it wants to do with HEAD
requests.
On the one hand, it supports catching {http_head_abort, Resp} and will throw
that in start_response/3 and start_response_length/4 if
On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds randall.le...@gmail.com wrote:
On Wed, Jul 20, 2011 at 15:09, Paul Davis paul.joseph.da...@gmail.com wrote:
On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen travis.jen...@gmail.com
wrote:
couch_httpd.erl seems to be confused about what it wants
On Wed, Jul 20, 2011 at 6:32 PM, Randall Leeds randall.le...@gmail.com wrote:
On Wed, Jul 20, 2011 at 15:20, Paul Davis paul.joseph.da...@gmail.com wrote:
On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds randall.le...@gmail.com
wrote:
On Wed, Jul 20, 2011 at 15:09, Paul Davis paul.joseph.da
On Mon, Jul 4, 2011 at 1:37 PM, Robert Newson robert.new...@gmail.com wrote:
From the existing thread (which I can't find either!), we had several
votes for DocBook, the source of those docs to live alongside the code
in the same svn repository we all know and love (or keep at arms
length with
On Mon, Jul 4, 2011 at 9:07 AM, Noah Slater nsla...@apache.org wrote:
On 4 Jul 2011, at 13:28, Apache Wiki wrote:
+ * [[http://www.rechtsanwalt-24.net/|Rechtsanwalt]] is a law-related
platform using CouchDB for their search queries.
+ * [[http://www.ehescheidung-jetzt.de/|Online
On Wed, Jun 29, 2011 at 4:14 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Wed, Jun 29, 2011 at 01:08, Paul Davis paul.joseph.da...@gmail.com wrote:
*Nothing* should change on anything that isn't trunk.
You mean that 1.1 will never support SpiderMonkey 1.8.5? That would
kind of suck.
Its
On Wed, Jun 29, 2011 at 5:41 AM, Jan Lehnardt j...@apache.org wrote:
On 29 Jun 2011, at 01:06, Randall Leeds wrote:
On Tue, Jun 28, 2011 at 15:54, Paul Davis paul.joseph.da...@gmail.com
wrote:
On Tue, Jun 28, 2011 at 6:41 PM, Randall Leeds rand...@apache.org wrote:
I recently committed
On Tue, Jun 28, 2011 at 10:52 AM, Andrey Somov
trophyb...@googlemail.com wrote:
Hi all,
the trunk contains now duplicates for 2 Erlang files: mochijson2.erl and
mochinum.erl
They reside both in 'ejson' and in 'mochiweb' folders.
The content is almost identical (just two lines are swapped)
://nelsonhaha.com/
HTH,
Paul Davis
, making them official makes the curl dependency
non-optional for release managers and testers, so there's also that.
Yours truly,
Paul Davis
On Tue, Jun 28, 2011 at 6:41 PM, Randall Leeds rand...@apache.org wrote:
I recently committed a patch from Chris Coulson to support the new
1.8.5 release of SpiderMonkey[1].
While some effort was put into supporting the breaking changes from
1.8.5 and it's been verified that the new trunk
On Tue, Jun 28, 2011 at 7:06 PM, Randall Leeds randall.le...@gmail.com wrote:
On Tue, Jun 28, 2011 at 15:54, Paul Davis paul.joseph.da...@gmail.com wrote:
On Tue, Jun 28, 2011 at 6:41 PM, Randall Leeds rand...@apache.org wrote:
I recently committed a patch from Chris Coulson to support the new
On Mon, Jun 27, 2011 at 7:16 AM, Andrey Somov trophyb...@googlemail.com wrote:
Hi all,
I wanted to know how couch_key_tree:merge() works running 060-kt-merging.t
from trunk.
While looking in the documentation I could not find the answer to a couple
of questions:
1) How can I see the
On Mon, Jun 27, 2011 at 9:42 AM, Andrey Somov trophyb...@googlemail.com wrote:
Thank you Paul.
Should it be added to the documentation ?
Andrey
You could add it at [1] if you like.
http://wiki.apache.org/couchdb/Test_procedure
On Fri, Jun 24, 2011 at 12:59 PM, Randall Leeds randall.le...@gmail.com wrote:
On Fri, Jun 24, 2011 at 03:36, Robert Dionne
dio...@dionne-associates.com wrote:
This is interesting work, I notice some substantial changes to couch_btree,
a new query_modify_raw, etc..
I'm wondering though if
This is the release vote for Apache CouchDB 1.0.3
Changes in this release:
* Fixed compatibility issues with Erlang R14B02.
* Fix bug that allows invalid UTF-8 after valid escapes.
* The query parameter `include_docs` now honors the parameter `conflicts`.
This applies to queries against
:)
On Jun 22, 2011 5:58 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
While preparing the 1.0.3 release I stumbled across an awesome bug in
the attachments.js test. Apparently Chrome will set the Content-Type
to null if the Content-Length is 0 and the response is served from
127.0.0.1. I can
Reproduced a test case for this that fails on Chrome but passes on
Safari. Reported in the Chromium tracker as an extension of a very
similar bug:
http://code.google.com/p/chromium/issues/detail?id=79556
On Thu, Jun 23, 2011 at 9:54 AM, Paul Davis paul.joseph.da...@gmail.com wrote:
I'm
While preparing the 1.0.3 release I stumbled across an awesome bug in
the attachments.js test. Apparently Chrome will set the Content-Type
to null if the Content-Length is 0 and the response is served from
127.0.0.1. I can reproduce this easily by just changing between
127.0.0.1 and my local
On Tue, Jun 21, 2011 at 2:25 AM, Benoit Chesneau bchesn...@gmail.com wrote:
Hi all,
I'm back on this topic. I know that @davisp made a script to split the
file structure etc, but I wonder why or what we are waiting to do
this. Also why using a script when we could move everything once? (and
On Tue, Jun 21, 2011 at 5:51 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Tue, Jun 21, 2011 at 10:05 AM, Randall Leeds randall.le...@gmail.com
wrote:
I like this.
I'd love to see a branch that contains all the incremental changes
from trunk to this build.
I would build and test it and
On Tue, Jun 21, 2011 at 10:30 AM, Noah Slater nsla...@apache.org wrote:
On 21 Jun 2011, at 15:25, Paul Davis wrote:
The problem with 'doing it once' is that its not entirely that
straight forward unless you want to have a single absolutely massive
commit. And that's something I wanted
On Tue, Jun 21, 2011 at 10:37 AM, Noah Slater nsla...@apache.org wrote:
On 21 Jun 2011, at 15:31, Paul Davis wrote:
Perhaps we should just write a small tool that does the
compilation in parallel instead of trying to wedge a square hole into
a hypercube.
GNU Make has parallel builds baked
bigcouch is technically a
fork of couchdb as it requires a few tweaks to make couchdb a distributed
database.
I'm confused. Are you advocating a full on switch to rebar?
[1] https://github.com/bdionne/bitstore
On Jun 21, 2011, at 10:36 AM, Paul Davis wrote:
On Tue, Jun 21, 2011
On Tue, Jun 21, 2011 at 11:59 AM, Noah Slater nsla...@apache.org wrote:
On 21 Jun 2011, at 16:19, Benoit Chesneau wrote:
why not at top level? Currently everything is an src folder and I
don't see any reason except arbitrary concern? Why split everything in
folders that have not really a
that patch? It's related to a change
that ended up only in 1.1.x and trunk (use of mochiweb's
Request:accepts_content_type/1).
On Wed, Jun 15, 2011 at 2:04 AM, Paul Davis paul.joseph.da...@gmail.com
wrote:
On Tue, Jun 14, 2011 at 8:55 AM, Jan Lehnardt j...@apache.org wrote:
Good find Paul,
On 14
On Wed, Jun 15, 2011 at 10:49 AM, Sam Bisbee s...@sbisbee.com wrote:
On Wed, Jun 15, 2011 at 9:43 AM, Paul Davis paul.joseph.da...@gmail.com
wrote:
I'm not at all sure that I need to. My reasoning for consideration was
as such: I looked at it, it wasn't in 1.0.x. The diff looked like
I'm officially kicking of the 1.0.3 release procedure.
Everyone should double check the NEWS and CHANGES files and tell me
that everything is ok on that end. Then you should vote whether to
continue along with things. I'll be making a dry run of rolling the
tarball tonight and tomorrow I'll start
On Wed, Jun 15, 2011 at 8:09 PM, Noah Slater nsla...@apache.org wrote:
On 16 Jun 2011, at 01:04, Paul Davis wrote:
During the 1.0.2 release it became apparent that when a vote fails and
we have to redo the whole thing that it can become confusing what's
being voted on as there exists
In reference to:
http://wiki.apache.org/couchdb/Release_procedure
Anyone object if I move If working on a branch, make sure NEWS and
CHANGES are synced with trunk. from the Checklist at top to the House
Keeping section at bottom? Seems like something that shouldn't be done
until after the
Seems like no one cares about it anymore (anecdotally from IRC and ML
traffic). Pretty sure we decided to do it during the dist cleanup.
Anyone want to pull the trigger?
I think it is mentioned in the housekeeping section.
I would consider this Robert Newson forgetting it during the 1.1.x
houskeeping section in which case its overdue.
On Tue, Jun 14, 2011 at 9:37 AM, Jan Lehnardt j...@apache.org wrote:
Hooray what a great thread :)
I was on the cusp of starting one like it myself, although for different
reasons. Turns out the the details are all the same.
First, the wiki. While it works most of the time and includes most
Paul always goes on about how I'm some Autotools guru. But the real truth of
the matter is that I just broke the damn thing so many times that eventually
it worked for most people, most of the time.
Don't lie. You're my Mr. Miyagi.
http://www.youtube.com/watch?v=J1gAHil89Z4
I'd also propose to not bother with SVN on this one as long as the
technical side of things is taken care of (Paul?).
Not sure what you mean here.
ASF is starting to roll out git infrastructure. If we go for a new repo, I'd
say we skip SVN provided the foundation for that is solid. Since
On Tue, Jun 14, 2011 at 8:55 AM, Jan Lehnardt j...@apache.org wrote:
Good find Paul,
On 14 Jun 2011, at 01:22, Paul Davis wrote:
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
501 - 600 of 1210 matches
Mail list logo
