either way their COC doesn't comply to *your* standards.
Fosdem is the event to go if you would like to meet many technologies and
meet really different people and not the usual average attendee of trendy
conferences.
If you're really curious ans open then the fosdem is the event to go in
europe.
On Wed, Mar 27, 2013 at 10:05 PM, Wendall Cada wrote:
> In 1.3.0, there is a new part of the test suite to run the javascript tests
> from the command line. I'm running into various issues on different
> hardware/OS configurations. Mostly, tests hanging or timing out and failing.
> These are reall
Hi,
As promised, I finally had time to test a build of Apache CouchDB
using latest stable spidermonkey from Mozilla [1] . For this test I
used rcouch which only use the spidermonkey 1.8.5 version of couchjs
but the code is similar to the one in Apache CouchDB.
All tests are green. It didn't imply
I should have posted it since a while but was side tracked by work and
travel. Anyway here is a workflow I had in mind since a long time. It's not
here to forbid the use of Github PR or system like one. On the contrary it is
trying to find a way to work with them while keeping the @dev mailing-list
], [
@@ -256,6 +257,7 @@ Is the Mozilla SpiderMonkey library installed?])
])
])
])
+])
# Figure out what version of SpiderMonkey to use
- benoît
On Thu, Mar 28, 2013 at 4:54 AM, Wendall Cada wrote:
> On 03/27/2013 07:36 PM, Benoit Chesneau wrote:
>&
On Fri, Mar 29, 2013 at 12:47 AM, Olafur Arason wrote:
> 22. _changes feed for views on https://gist.github.com/rnewson/2387973 is
> already supported.
> http://comments.gmane.org/gmane.comp.db.couchdb.user/14891
> so /mydb/_changes?filter=_view&view=mydesign/my_view
>
> I only recently stumbled o
Sound like more changes are needed. I will post a new patch with that.
- benoit
On Thu, Mar 28, 2013 at 6:05 PM, Randall Leeds wrote:
> lgtm but I'll test it today
>
> On Thu, Mar 28, 2013 at 3:26 AM, Benoit Chesneau wrote:
>> This patch seems to be enough but I wil
On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt wrote:
> Hi all,
>
> It is time to think about how to square the upcoming changes to CouchDB and
> the next releases.
>
> Robert Newson and I hashed out this plan:
>
> 1. Compile a list of API changes between now and after the BigCouch merge
> (https
On Sat, Mar 30, 2013 at 11:20 PM, Dave Cottlehuber wrote:
>> On 29 March 2013 03:35, Benoit Chesneau wrote:
>> Sound like more changes are needed. I will post a new patch with that.
>>
>> - benoit
>
> Woo! What platform/OS was that on please?
I had to go back
+1
Note: Install.unix probably needs more details for ubuntu server. The following
packages need to be installed:
sudo apt-get install autoconf autoconf-archive libtool
sudo apt-get install pkg-config
- benoît
On Sat, Mar 30, 2013 at 4:54 PM, Noah Slater wrote:
> Dear community,
>
> I
rry
for that. But this is really missing when you build it from sources.
- benoît
>
>
> On 1 April 2013 14:01, Benoit Chesneau wrote:
>
>> +1
>>
>> Note: Install.unix probably needs more details for ubuntu server. The
>> following
>> packages need to be
not totally related but why not sending the TZ patch upstream btw? Is
there anything against that?
I'm worried we have to maintain our own versions for dependencies for
a long time instead of pushing upstream our changes I reckon that for
a limited time we have to maintain our own set of patches
Noah,
There is a link to the latest 1.2.2 posted by Alexander Shorin:
https://plus.google.com/u/0/113807980501912604291/posts/LJTt5SrPFJc
The community page is here:
https://plus.google.com/u/0/communities/112687873154936256826
Once you join it I will be happy to give you credentials to it.
-
t;> On Thu, Mar 28, 2013 at 3:12 AM, Benoit Chesneau
>> wrote:
>> > I should have posted it since a while but was side tracked by work and
>> > travel. Anyway here is a workflow I had in mind since a long time. It's
>> not
>> > here to forbid the use
On Tue, Apr 2, 2013 at 8:54 PM, Noah Slater wrote:
> I have joined. Can you mod me?
>
>
done.
> On 2 April 2013 19:53, Noah Slater wrote:
>
>> Ah, got it. I might add this to the release process.
>>
>> Does Google+ have the concept of a "page" like Faceeook does? Like we have
>> an official Cou
On Tue, Apr 2, 2013 at 9:06 PM, Noah Slater wrote:
> What would this Git repos be for?
>
to start the work on some scripts. Can also be done somewhere in the
repo we already have? What would it be the best according to you?
- benoît
>
> On 2 April 2013 19:59, Benoit Chesneau wrot
you want to do? You seem to be our Google+ guy.
> Add me as a mod when you're done please.
Yes, will do it tonight.
- benoît
>
>
> On 2 April 2013 20:01, Benoit Chesneau wrote:
>
>> On Tue, Apr 2, 2013 at 8:54 PM, Noah Slater wrote:
>> > I have joined. Can yo
I didn't know about that one. But yes probably!
On Tue, Apr 2, 2013 at 9:26 PM, Noah Slater wrote:
> https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git
>
>
> On 2 April 2013 20:08, Benoit Chesneau wrote:
>
>> On Tue, Apr 2, 2013 at 9:06 PM, Noah Slater wrote
On Tue, Apr 2, 2013 at 9:39 PM, Randall Leeds wrote:
> On Tue, Apr 2, 2013 at 11:59 AM, Benoit Chesneau wrote:
>> Cool,
>>
>> Thanks Randall & Noah for the feedback. I think we are all OK to start
>> to work on that then. Randall can you provide a link for
On Tue, Apr 2, 2013 at 9:25 PM, Noah Slater wrote:
> Thanks!
https://plus.google.com/109226482722655790973
is the link to the page. I also invited you to be a manager but if you
want to use another adress please let me know.
- Benoît
>
>
> On 2 April 2013 20:09, Benoit Che
If the intention is to remove that filter, then why just comment it?
Imo the patch should be reworked.
Also not sure it should be re removed, the question is more why should
we accept any JSON value there? What is the purpose? Shouldn't we on
the contrary fix the replicator db to not accept that?
Thinking more about that issue, and I think that once the patch for
the view changes will be integrated there is a need to accept any JSON
value there for the view params. Then maybe just removing the comments
since we won't have it anymore.
On Fri, Apr 5, 2013 at 8:12 PM, Benoit Chesneau
What is UK summer time? Let's talk about UTC, this standard around the world ;)
- benoit
On Tue, Apr 9, 2013 at 3:29 PM, Dave Cottlehuber wrote:
> Hi all,
>
> We'll be having the usual meeting in #couchdb-meeting
> onirc.freenode.org at 20:00 *UK summer time* Wednesday as usual.
>
> The meeting
Of course you can ignore anything that is asked during a meeting. But
what is a point of a meeting then? Note that "obligatory" was under
quotes in my original sentence as well.
A meeting if needed should be constructive. My point when *I*
suggested to have a meeting was to have an informal meetup
On Wed, Apr 17, 2013 at 7:55 AM, Stephen Bartell wrote:
>
> But for what I was doing, no, I wasn't specifying since. I would expect the
> fundamentals to be the same as well. What I was see is that even without
> `since` given, no changes would come through until that second source was
> adde
g:
>>> var source1 = new
>>> EventSource('/source1/_changes?feed=eventsource&timeout=5000&heartbeat=5000')
>>>
>>> Watch the Network panel. It looks like EventSource does not pass the query
>>> params. I'm probably being an idiot
any possibility to have the file?
On Thu, Apr 18, 2013 at 1:49 PM, Jan Lehnardt wrote:
> Hey all,
>
> not to be too alarmist, but I found this via twitter:
>
> http://nicollet.net/2013/04/couchdb — “CouchDB database corruption”
>
> Bob N looked at this and found this in the logs
>
> https://g
On Thu, Apr 18, 2013 at 2:38 PM, Jan Lehnardt wrote:
> It's linked in the post.
>
> Cheers
> Jan
> --
>
Last mail linked it as well.
On Thu, Apr 18, 2013 at 3:05 PM, Robert Newson wrote:
> Hi Victor,
>
> Thanks for the report and for capturing a .couch file in this state. I
> have reproduced the error locally with 1.2.0.
>
> Can you tell me anything about what was happening before this
> happened? Did you ever run out of disk s
That could be a good Idea, at least could drain more activity on the
g+ page and community.
- benoit
On Fri, Apr 19, 2013 at 7:30 PM, Noah Slater wrote:
> Hi,
>
> Now that we have a CouchDB Google+ "page", I figure the "page" can +1
> things, no?
>
> So what if we allow any interested parties to
Can you provide any dmesg logs and anything you have to check your
disks ? That could help us to check if it's a couchdb bug or the
result of a faulty hardware.
- benoit
On Thu, Apr 18, 2013 at 2:17 PM, Victor Nicollet wrote:
> Hello,
>
> The @CouchDB twitter account thought you might find this
master i would say.
On Tue, Apr 23, 2013 at 7:11 PM, Dave Cottlehuber wrote:
> On 9 April 2013 16:55, Paul Davis wrote:
>> I'm all for bumping our minimum requirement. Reading Bob's commit I'm
>> not exactly sure which part is requiring a newer Erlang. Maybe one of
>> the crypto functions is new
Quite in phase of what I proposed 6 months ago:
http://markmail.org/thread/ec3okssflzbms4pw
- benoit
On Mon, Apr 29, 2013 at 3:48 PM, Noah Slater wrote:
> Does anybody have any other thoughts on this? We need to choose something
> as soon as possible.
>
>
> On 25 April 2013 23:01, Robert Newson
Great news! Welcome Dale!
On Mon, Apr 29, 2013 at 3:52 PM, Noah Slater wrote:
> Dear community,
>
> I am pleased to announce that the CouchDB Project Management Committee has
> elected Dale Harvey as a CouchDB committer.
>
> Apache ID: dale
>
> IRC nick: daleharvey
>
> Twitter: @daleh
imo production branches should only be rebased, no merge so you keep
the history easier for people asynchronously branching from
productions branch. merges can be really difficult to handle along the
time when you have a branch that differs a lot.
Also this is why the develop branch exist, so peop
On Tue, Apr 30, 2013 at 12:06 AM, Robert Newson wrote:
> If production branches follow that rule then there will be broken
> commits that won't build. A feature, or fix, will not land atomically,
> but in all its constituent parts. That's the thing we are striving to
> avoid.
>
Well a feature or
On Tue, Apr 30, 2013 at 9:02 PM, Dave Cottlehuber wrote:
> On 30 April 2013 15:57, Noah Slater wrote:
>> snip
>
> Of note against rebasing merges, is this:
> http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
>
> TL;DR rebase gives a linear history but the timestam
+1
On Tue, May 7, 2013 at 8:35 PM, Robert Newson wrote:
> +1
>
> On 7 May 2013 19:34, Noah Slater wrote:
>> Devs,
>>
>> We're switching over to time-based releases.
>>
>> I took a moment to review our existing release branches today, and I have
>> prepared a list of recommendations for you. Plea
I would like to discuss about the lazy concensus here.
Side notte: I already read http://www.apache.org/foundation/voting.html thanks.
So these votes happend quite often this last 4 months either in
@private or @dev ml, and I'm quietly becoming very annoyed by them.
Especially when they expect a
On Tue, May 7, 2013 at 9:23 PM, Robert Newson wrote:
> I'm not sure I fully agree. All the lazy consensus's of late have had
> a 72 hour window on them which is the same duration we use for couchdb
> releases.
This si another topic. Also votes on release need a majority of
approval, and are done
On Wed, May 8, 2013 at 6:19 AM, Benoit Chesneau wrote:
> On Tue, May 7, 2013 at 9:23 PM, Robert Newson wrote:
>> I'm not sure I fully agree. All the lazy consensus's of late have had
>> a 72 hour window on them which is the same duration we use for couchdb
>> rele
On Thu, May 9, 2013 at 2:02 AM, Noah Slater wrote:
> On 7 May 2013 20:07, Benoit Chesneau wrote:
>
>>
>> Lazy consensus give this false idea that because no-one objected in
>> time then it's OK to process.
>
>
> This is not a false idea. This principal
On Thu, May 9, 2013 at 4:02 AM, Noah Slater wrote:
> On 9 May 2013 01:02, Noah Slater wrote:
>
>>
>> I would be happy to use the subject tag PROPOSAL when lazy consensus is
>> being used, to separate these threads out from general DISCUSS threads.
>> Please note, however, that in my mental model
+1 for opening a branch with it. I think I have some questions but
will put them as separate thread.
Thanks for all this code :)
- benoit
On Tue, May 7, 2013 at 10:34 PM, Robert Newson wrote:
> Hi All,
>
> I propose to merge in the following work,
> https://github.com/rnewson/couchdb/tree/nebra
roject is more or
less active. But this is out of topic.
- benoit
On Thu, May 9, 2013 at 5:48 PM, Noah Slater wrote:
> On 9 May 2013 07:10, Benoit Chesneau wrote:
>
>> Lazy consensus aren't here to obtain a real consensus.
>>
>
> You are incorrect.
>
> Lazy con
On Thu, May 9, 2013 at 7:26 PM, Noah Slater wrote:
> I'm not sure what you find offensive in my email.
>
> I was pointing out that your understanding of lazy consensus is incorrect.
> And the arguments you make from that misunderstanding are similarly
> incorrect.
>
> You came close to making a co
On Fri, May 10, 2013 at 10:39 AM, Benoit Chesneau wrote:
> On Thu, May 9, 2013 at 7:26 PM, Noah Slater wrote:
>> I'm not sure what you find offensive in my email.
>>
>> I was pointing out that your understanding of lazy consensus is incorrect.
>> And
he proposed policy to
use the lazy consensus *by default*. I hope it's clear now. And this
discussion is perfectly legal imo.
Voila.
- benoit
On Fri, May 10, 2013 at 4:48 PM, Noah Slater wrote:
> On 10 May 2013 09:39, Benoit Chesneau wrote:
>
>> Though I failed in this bad (imo)
expect to make a release sometimes next wee and commit first
bits over the week-end.
Hopefully it will work as expected.
- benoit
On Thu, Mar 28, 2013 at 11:12 AM, Benoit Chesneau wrote:
> I should have posted it since a while but was side tracked by work and
> travel. Anyway here is a wo
On Fri, May 10, 2013 at 8:47 PM, Jan Lehnardt wrote:
> Maybe what is missing from this is that lazy consensus leads to things
> that can never every be changed again. It is just a tool to keep a
> distributed team going. If we do a thing and it gets lazy consesus’d
> and implemented and even shipp
On Fri, May 10, 2013 at 8:46 PM, Noah Slater wrote:
> Benoit,
>
> Please produce a draft of the by-laws you would like to see.
>
> Thanks,
I'm not sure what yo mean by-laws here. But I will draft a set of
rules I have in mind. Not until next week anyway since I am working
on some other topics r
On May 15, 2013 12:06 AM, "Dave Cottlehuber" wrote:
>
> On 14 May 2013 23:24, Robert Newson wrote:
> >
> > I'd like to see the mochiweb work for R16 compatibility in 1.3.1.
> >
> > B.
>
this can't happen since it removes the r13 compatibility. imo it has to
wait for 1.4.
in the mean rime ws cou
welcome :)
On Fri, May 17, 2013 at 1:40 PM, Garren Smith wrote:
> Congrats Dirkjan thats awesome.
>
> On 17 May 2013, at 1:39 PM, Noah Slater wrote:
>
>> Dear community,
>>
>> I am pleased to announce that the CouchDB Project Management Committee has
>> elected Dirkjan Ochtman as a CouchDB commi
+!.
I have actually one vm available. I will be back on Friday and will
make it available.
- benoit
On Mon, May 20, 2013 at 12:44 PM, Jan Lehnardt wrote:
> Hi all,
>
> a number of other open source projects have started providing
> Vagrant[1] VMs that come with all development tools preinstalle
Skipping r15???
On May 20, 2013 3:03 PM, wrote:
> Skip R15B02, R15B01, R15B, R14B03 for Travis tests.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
> Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/46b141dd
> Tree: http://git-wip-us.apache.org/repos/asf/couchdb/
On May 20, 2013 2:59 PM, "Dirkjan Ochtman" wrote:
>
> Hi there,
>
> Keeping Makefile.am in sync with the actual documentation is a PITA,
> and doesn't add any value. In fact, I broke the build over the weekend
> by not removing some files from the Makefiles. Instead, we can use
> invocations of fi
On May 20, 2013 3:15 PM, "Dirkjan Ochtman" wrote:
>
> On Mon, May 20, 2013 at 3:11 PM, Benoit Chesneau
wrote:
> > Skipping r15???
>
> No, just older R15 and R14 releases. You'll note R15B03 is still here.
>
> Discussed this with Jan in IRC after I observ
Then I should just let the test fail as a constant reminder for us
that we need to do something ;)
- benoit
On Mon, May 20, 2013 at 4:14 PM, Dirkjan Ochtman wrote:
> On Mon, May 20, 2013 at 4:10 PM, Benoit Chesneau wrote:
>> Anyway are these just tests failing or an issue in our su
On Mon, May 20, 2013 at 4:14 PM, Dirkjan Ochtman wrote:
> On Mon, May 20, 2013 at 4:10 PM, Benoit Chesneau wrote:
>> Anyway are these just tests failing or an issue in our support for these
>> versions? Do we also need to update the doc?
>
> Since we have also have a few bui
On May 20, 2013 10:56 PM, "Dirkjan Ochtman" wrote:
>
> On Mon, May 20, 2013 at 5:39 PM, Noah Slater wrote:
> > I'm torn on this issue.
> >
> > See:
> >
> > http://www.gnu.org/software/automake/manual/automake.html#Wildcards
> >
> > (Please read that whole section.)
> >
> > Summary is:
> >
> > *
I thought we needed to support n and n-1. Did that change?
- benoît
On May 21, 2013 3:43 AM, "Noah Slater" wrote:
> Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards
> compatible, and is the recommended upgrade path for anyone on 1.2.x.
>
>
> On 20 May 2013 20:56, Jan Lehn
+1
On Tuesday, May 21, 2013, Dirkjan Ochtman wrote:
> On Tue, May 21, 2013 at 11:33 AM, Jan Lehnardt >
> wrote:
> > It is all documented here:
> http://wiki.apache.org/couchdb/Release_Procedure
>
> Oh, good. We should definitely pull stuff like that into a developer
> chapter of the docs, IMO.
>
Hello,
I was looking at the PPA from Randall which is the most up to date I
think (correct me if I'm wrong) and wanted to create a pseudo-official
one, at least one that we can give the link. I have have also 3 goals:
- having the stable version always available
- having a nightly build
- optionn
done. Sorry for the spam...
- benoit
On Tue, May 21, 2013 at 5:24 PM, Launchpad Email Validator
wrote:
>
> Hello
>
> The Launchpad user named 'Benoit Chesneau (bchesneau)' requested the
> registration of 'dev@couchdb.apache.org' as the contact email addre
On Tue, May 21, 2013 at 5:15 PM, Robert Newson wrote:
> The cloudant packages repository is no longer maintained fwiw, it's
> only not been deleted in case someone wanted to take it on.
OK thanks for the info :)
On Tue, May 21, 2013 at 8:54 PM, Randall Leeds wrote:
> I had been using git-buildpackage tools to maintain debian, upstream,
> and pristine-tar branches. I was doing this all from my local couchdb
> repo. I don't know whether or not it makes sense to push all this to
> apache git or not, but I w
Why not having both? I mean I don't want to have to read an RST to
know how to install.
Having plain ascii is good imo. Also this is a common known place to
find install docs.
- benoit
On Wed, May 22, 2013 at 10:06 AM, Dirkjan Ochtman wrote:
> Hi there,
>
> I think it would make sense to pull o
I'
On Wed, May 22, 2013 at 10:43 AM, Jan Lehnardt wrote:
>
>
> On 22.05.2013, at 10:26, Benoit Chesneau wrote:
>
>> Why not having both? I mean I don't want to have to read an RST to
>> know how to install.
>>
>> Having plain ascii is g
On Wed, May 22, 2013 at 11:32 AM, Dirkjan Ochtman wrote:
> On Tue, May 21, 2013 at 10:26 PM, Jan Lehnardt wrote:
>> So far.
>
> There are some things here I like, and some I don't like that much.
>
> I like the emphasis on do-ocracy, and the encouragement for
> non-committers to just do stuff (an
On Wed, May 22, 2013 at 6:11 PM, Noah Slater wrote:
> +1 on moving RPM/DEB meta data into the main source tree. (Jan, these tools
> expect specific top level dirs/files, but they're usually self-contained.
> As you say, we can change things if it gets cluttered.)
>
> Benoit, what about maintaining
ess. But I
will check asap.
- benoit
> On 21 May 2013 16:59, Benoit Chesneau wrote:
>
>> done. Sorry for the spam...
>>
>> - benoit
>>
>> On Tue, May 21, 2013 at 5:24 PM, Launchpad Email Validator
>> wrote:
>> >
>> > Hello
>
On Wed, May 22, 2013 at 9:47 PM, Noah Slater wrote:
> Does Ubuntu streamline the process of adding the PPA to your
> /etc/apt/sources.list?
yes, for ex:
sudo add-apt-repository ppa:couchdb/apache-couchdb
done.
It can also do the work for us when it's about building the package
for the differe
so maintain its own debian repo.
- benoit
>
> On 22 May 2013 20:51, Benoit Chesneau wrote:
>
>> On Wed, May 22, 2013 at 9:47 PM, Noah Slater wrote:
>> > Does Ubuntu streamline the process of adding the PPA to your
>> > /etc/apt/sources.list?
>>
>> yes,
To make this is not that I want to be on launchpad or whatever, just
found that it could be useful for some to be there. But I won't stand
on it if most think it is requiring too much works or is useless.
- benoit
On Wed, May 22, 2013 at 10:00 PM, Benoit Chesneau wrote:
> On Wed, May
On Fri, May 24, 2013 at 6:32 PM, Noah Slater wrote:
> Activity from elsewhere:
>
> http://markmail.org/message/5pxv3ni6qvc2k2jo
>
> http://markmail.org/message/czkylvo2wvbrrikj
>
> http://markmail.org/message/2ybvoo2yjwxmfwze
>
> http://markmail.org/message/ohjwjh6ri72yuagh
>
> http://markmail.org
+1
On Mon, May 27, 2013 at 5:42 PM, Robert Newson wrote:
> Hi All,
>
> Rather than manually maintaining the NEWS and CHANGES files I'd like
> to save us time by using the output of git log as our release notes
> after 1.3.1.
>
> To make this work we'll need to be better at commit messages. The de
uh? i thought the consensus was to not apply it on 1.3. When this change
has been decided? ( and tested)
benoît
On May 28, 2013 8:06 PM, wrote:
> Update NOTICE/NEWS/CHANGES/Changelog.rst for mochiweb backport
>
>
> Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
> Commit: http://git
-- Forwarded message --
From: "Dirkjan Ochtman"
Date: May 28, 2013 8:23 PM
Subject: Re: [2/2] git commit: updated
refs/heads/1696-backport-mochiweb-2-4-2-1.3.x to 266cd32
To: "dev@couchdb.apache.org"
Cc:
> On Tue, May 28, 2013 at 8:12 PM, Benoit Che
master and
release. Ie. only atomic or self-described commits should go on
master. The point is that without control on the commits the changelog
will quickly become useless. Thoughts?
- benoit
On Mon, May 27, 2013 at 5:44 PM, Benoit Chesneau wrote:
> +1
>
> On Mon, May 27, 2013 at 5:42 PM, R
On Tue, May 28, 2013 at 8:57 PM, Noah Slater wrote:
> We're dropping this for 1.3.1.
>
OK, that's a good news imo. Thanks for the info.
- benoit
>
> On 28 May 2013 19:42, Benoit Chesneau wrote:
>
>> -- Forwarded message --
>> From: "Di
On Wed, May 29, 2013 at 10:54 AM, Noah Slater wrote:
> I'm worried about it for two reasons:
>
> 1) It sets a precedent The test suite forms a "contract" between us and
> our users. They expect it to work. If we're prepared to ship software with
> failing tests, then what is the point of the test
I probably miss w dependency to build couch. I get this error right now:
make -C bin distcheck-hook
make[2]: Entering directory `/vagrant/couchdb/bin'
if test ! -s couchdb.1; then \
../build-aux/dist-error couchdb.1; \
else \
if test ! `cat couchdb.1 | wc -l` -gt 1; then \
../build-au
enoit
>
>
> On 29 May 2013 13:03, Dirkjan Ochtman wrote:
>
>> On Wed, May 29, 2013 at 1:57 PM, Benoit Chesneau
>> wrote:
>> > I probably miss w dependency to build couch. I get this error right now:
>> >
>> > make -C bin distcheck-hook
>&g
On Wed, May 29, 2013 at 2:03 PM, Dirkjan Ochtman wrote:
>
> So, help2man?
>
That's it, thanks!
- benoit
Why do we need pygments >= 1.5 ? I don't see anything in our doc that
would require it. Also the version installed on an ubuntu LTD is 1.4.
So if there are no reason I think we should decrease the requirements
(or simply removing it).
- benoit
On Wed, May 29, 2013 at 2:30 PM, Benoit Chesneau wrote:
> Why do we need pygments >= 1.5 ? I don't see anything in our doc that
> would require it. Also the version installed on an ubuntu LTD is 1.4.
>
> So if there are no reason I think we should decrease the requirements
&
I would like to start to rewrite all of our tests to make them really relianle.
The problems that I want to fix are the following:
- try to remove most of the sleep w e have around
- remove JS tests when it's about testing the HTTP API. There are
actually no reason to test the HTTP API by faking
On Wed, May 29, 2013 at 6:31 PM, Pavan Sudheendra wrote:
> Cool. Also, do i need to consider multiple engines to collect metrics like
> Folsom, Graphite or should i stick to only 1 (Folsom) ?
Once you have folsom you can easily plug on top of it others systems.
For graphite it has already be done
Why isn't it in a branch ? :/
On Fri, May 31, 2013 at 8:06 PM, wrote:
> Updated Branches:
> refs/heads/master f15f54d56 -> c98ba5612
>
>
> Allow storing a pre-hashed admin password
>
> When duplicating a couch, it is difficult to copy the _config/admins/*
> values. Storing the encoded value do
sh signature . It would also keep the api simple.
On Fri, May 31, 2013 at 8:47 PM, Benoit Chesneau wrote:
> Why isn't it in a branch ? :/
>
> On Fri, May 31, 2013 at 8:06 PM, wrote:
>> Updated Branches:
>> refs/heads/master f15f54d56 -> c98ba5612
>>
>>
On Jun 1, 2013 6:37 AM, "Jason Smith" wrote:
>
> Both methods have their own restrictions.
>
> When editing an .ini file, you *can* trivially set a password cyphertext
> (just paste it in), but you cannot set a password to literally
> "-pbkdf2-...". (You could calculate the hash yourself and then
On Thu, Jun 6, 2013 at 9:58 AM, Garren Smith wrote:
> I agree with Jason and Bob, the simplest way is going to be the easiest for
> us to implement.
>
> With us wanting to use commit messages in the release notes, could we not
> mark specific commit messages e.g. [Release Notes] so that only spe
On Thu, Jun 6, 2013 at 10:26 AM, Benoit Chesneau wrote:
> On Thu, Jun 6, 2013 at 9:58 AM, Garren Smith wrote:
>> I agree with Jason and Bob, the simplest way is going to be the easiest for
>> us to implement.
>>
>> With us wanting to use commit messages in the
or more review, (ie +1) then we are fine. On
other branch it is still time to rebase with a new commit msg when
it's about commiting on master imo.
- benoit
> On 6 June 2013 09:40, Benoit Chesneau wrote:
>
>> On Thu, Jun 6, 2013 at 10:26 AM, Benoit Chesneau
>> wrote:
>>
Well capababilities idea come from the SMTP world at first but same
idea. That's indeed a good idea. Identification per see would't be
efficient on a client level. We don't really want to reproduce the
nightmare we have with the browsers with different U/A. Testing
capabilities is definitely a good
On Mon, Jun 10, 2013 at 1:23 PM, Noah Slater wrote:
> I would like to reverse my position on this.
>
> I've just watched CloudStack abort a sequence of main project releases
> because the Debian packaging apparatus was broken. This wouldn't happen if
> the Debian build was kept separate.
>
> I thi
Hi all,
I've written sometimes ago for another usage a document describing the
replication algorithm in pseudo-code:
https://github.com/refuge/rcouch/wiki/Replication-Algorithm
Utltimately this document would allow me to write an alternative
replicator to couchdb that would work with any kind of
Hi All,
I propose to merge rcouch (http://rcouch,org) in the official Apache
CouchDB repository to a new branch (i.e, *not* master). Once there, the
full CouchDB developer community can begin the work to incorporate the
code here into an official release.
You do not need to respond if you are in
If that helps, in gunicorn we used to have all the packaging in the
repo, then the debian upstram packager asked to us to remove it if we
can. (we removed it).
So I guess it's probably better to keep the packaging outside the main repo.
- benoit
On Wed, Jun 26, 2013 at 3:41 PM, Robert Newson wr
to help Dave with the Windows packaging after this
> hits.
>
> -Joan
>
> On Wed, Jun 26, 2013 at 09:03:36PM +0200, Dave Cottlehuber wrote:
>> >>> On 25 June 2013 17:43, Benoit Chesneau wrote:
>> >>>
>> >>>> Hi All,
>> >
1 - 100 of 2237 matches
Mail list logo
