All,
A few weeks ago I put out a call for new maintainers on the couchdb-python
mailing list; after being the main maintainer for 8 years, I'd like to
spend my time on other things.
However, there have been no responses so far on the list. I remember that
the Apache CouchDB project at some point
On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt wrote:
> Bikeshed away! :)
Will there be discussion on API changes for BigCouch stuff? I don't
really have a clue on how BigCouch is different from CouchDB exactly,
all I know is it does some clustering and that's why some things are
different. In my
On Sun, Mar 31, 2013 at 9:42 PM, Jan Lehnardt wrote:
> We will be collecting things here:
>
> https://issues.apache.org/jira/browse/COUCHDB-1756
>
> There is an (incomplete) list of differences down on:
>
> http://bigcouch.cloudant.com/api
>
> Robert & Paul et.al will help getting the COUCHDB-
On Wed, Apr 17, 2013 at 3:45 PM, Noah Slater wrote:
> At a minimum, we need to create the 1.4.x branch. But I'd really like for
> us to properly document our merge procedure (which has languished because I
> don't know Git well enough to fill out the details) and then for us to call
> a vote on it
On Wed, Apr 17, 2013 at 4:02 PM, Noah Slater wrote:
> So that features can be merged into it as they become ready.
>
> Check out:
>
> http://wiki.apache.org/couchdb/Merge_Procedure
>
> Thoughts?
Seems like you could call the next-feature-release branch "master",
and not have to start a new branch
dev@ before you can merge in.
>
>
>
>
> On 17 April 2013 15:18, Dirkjan Ochtman wrote:
>
>> On Wed, Apr 17, 2013 at 4:02 PM, Noah Slater wrote:
>> > So that features can be merged into it as they become ready.
>> >
>> > Check out:
>&
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.
>
> However, we can discuss what the minimum lazy consensus period can be
> based on wha
> Anyway, I'm really excited about CouchDB and I really want to contribute to
> the global documentation out there, but MoinMoin ain't making it easy. I
> really think that a move to a better documentation tool could be a huge
> push to CouchDB's adoption. Thanks for listening.
Have you seen the n
On May 17, 2013 7:25 PM, "Dave Cottlehuber" wrote:
> Did we? Mmm it shouldn't fail on that, did I miss some travis-specific
> thingummie?
Looks like the build is now passing on master, at least. I pushed a fix for
a Sphinx warning, but I doubt that was the problem.
Cheers,
Dirkjan
On Thu, May 9, 2013 at 12:53 PM, Robert Newson wrote:
> I'm -0.9 (see http://www.apache.org/foundation/voting.html) on
> switching to Confluence. The choice of wiki technology is a tiny
> factor, in my opinion. No wiki is useful without active maintenance.
> Unless there's a horde of editors just
On Fri, May 17, 2013 at 1:39 PM, Noah Slater wrote:
> Please join me in extending a warm welcome to Dirkjan!
Thanks all, for the kind words!
Cheers,
Dirkjan
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 find to find the relevant files in these cases:
html_files := $(s
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 observed that R15B and R15B01
were somewhat more likely to fail our tests on Travis.
Cheers,
Dirkjan
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 builds passing, it looks like those
releases are more sensitive to intermittent issues wi
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:
>
> * Wildcards make it easy to distribute the wrong files (either too many, or
> to
On Mon, May 20, 2013 at 4:59 PM, Benoit Chesneau wrote:
> I was thinking to the INSTALL doc. If e know that these versions are
> broken maybe we should tell it when the 1.3.1 will be released.
>
> Or just fix it, then I wonder why removing it. Maybe we need such
> pressure to fix these errors ;)
On Tue, May 21, 2013 at 9:00 AM, Alexander Shorin wrote:
>> Alex/Dirkjan - have you any more outstanding doc bits to merge in? We
>> also have Stefan's github PR https://github.com/apache/couchdb/pull/58
>> to go in.
>
> I'd take this changes as modified patch into my local repo since I
> have a b
On Mon, May 20, 2013 at 11:29 PM, Noah Slater wrote:
> My concern is that when you use wildcards, a malicious (or broken) program
> could add files to the output that are then bundled up, and we end up
> shipping them in a release. At the moment, every file that we ship has been
> explcitly includ
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.
Cheers,
Dirkjan
On Tue, May 21, 2013 at 9:33 PM, Noah Slater wrote:
>> This could easily go in a git branch of its own
>
> Repositories are cheep... ;)
Yeah, a branch doesn't make much sense to me.
Cheers,
Dirkjan
On Tue, May 21, 2013 at 9:30 PM, Noah Slater wrote:
> The CHANGES entry for 1.3.1 is showing:
>
> *Nothing*
>
> The NEWS entry for 1.3.1 is showing:
>
> *Nothing*
>
> Please take the time to edit these files so that they reflect the existing
> changes on this branch.
Personally, I don't t
Hi there,
I think it would make sense to pull our installation documentation
into the larger docs effort. To guide people along, we can replace
INSTALL.Unix and INSTALL.Windows with an INSTALL file that points to
either the reST source and/or the generated HTML files.
Any objections?
Cheers,
Di
On Wed, May 22, 2013 at 10:23 AM, Rana Bunnni wrote:
> I would like to create a database that can store music.
> How can I save music in couchDB ?
> and how can i retrieve a specific music from the database ?
This mailing list is about developing CouchDB itself. You should ask
your question on th
On Wed, May 22, 2013 at 10:18 AM, Alexander Shorin wrote:
> Good idea. Already handled it:
>
> http://kxepal.iriscouch.com/docs/1.3/install/index.html
>
> Porting other install guides in progress. I have to check them against
> 1.3 release since most of them against old releases.
Alexander,
Coul
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 (and get elected as a committer soon
thereafter). Or, rather more genera
On Wed, May 22, 2013 at 1:51 PM, Noah Slater wrote:
> Let's aim to get down to a single README.md file that:
Maybe README.rst, since we're already using that for docs?
> a) looks good on GitHub, and
> 2) gives a GitHub style overview, and
I'm not sure what Github-style overviews look like, have
On Wed, May 22, 2013 at 2:15 PM, Jan Lehnardt wrote:
> And again, I think this is very good feedback, keep it coming :)
Perhaps using less SHOUTY TAGS for some of the more common things
(like PROPOSAL, which could just be RFC instead) would already be a
bit better.
Cheers,
Dirkjan
On Wed, May 22, 2013 at 3:29 AM, Randall Leeds wrote:
> On Tue, May 21, 2013 at 6:22 PM, Randall Leeds
> wrote:
>> Here's a diagram. In this I show a feature branch landing on master
>> and a backport of it landing on 1.3.x, but if we follow the procedure
>> I'm suggesting I think it can even be
On Thu, May 23, 2013 at 11:30 AM, Dave Cottlehuber wrote:
> TL;DR does it make sense to keep the n and n-1 active releases on the
> mirrors, or shall I just point people to
> http://archive.apache.org/dist/couchdb/binary/win/1.2.2/ etc? Maybe
> add a link on our website?
I think it makes sense t
On Mon, May 27, 2013 at 5:42 PM, Robert Newson wrote:
> 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
> facto standar
On Mon, May 27, 2013 at 3:53 PM, Noah Slater wrote:
> Last day to get in changes and update these files. Release day is tomorrow.
I've reviewed changes that are on master that seem like they are
low-risk bug fixes (and as such, should also be shipped on 1.3.x).
I found these:
4abe8cd9 - Merge r
On Mon, May 27, 2013 at 7:14 PM, Robert Newson wrote:
> If people want more than the one line summary, they can get the full
> details from the commit message, so I'm not keen on doing extra work
> (and commits) to generate redundant information. I'm -1 on adding the
> section and jira information
On Tue, May 28, 2013 at 10:10 AM, Robert Newson wrote:
> 1) We're all for including the JIRA ticket, for traceability, the
> question I have is why put that in the summary line?
Because it makes things easier for people trawling through high-level
commit logs (e.g. me when I start to edit change
On Tue, May 28, 2013 at 8:12 PM, Benoit Chesneau wrote:
> uh? i thought the consensus was to not apply it on 1.3. When this change
> has been decided? ( and tested)
It's being tested right now, join #couchdb-dev and help. ;)
Cheers,
Dirkjan
On Tue, May 28, 2013 at 11:55 PM, Noah Slater wrote:
> Also, is there any place I can look that would alert me to these failures
> before I do the whole release procedure?
Travis has been failing 140-attachment-comp.t intermittently for a while now.
On Wed, May 29, 2013 at 1:36 AM, Noah Slater
On Tue, May 28, 2013 at 11:45 PM, Noah Slater wrote:
> Please cast your votes now.
+1
Gentoo Linux, Erlang R15B2, Spidermonkey 1.8.5.
Sig, SHA OK.
make distcheck only fails 140-attachment-comp.t here as well.
BTW, within the Gentoo packaging environment, the tests run like shit,
with lots of
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
> make[2]: Entering directory `/vagrant/couchdb/bin'
> if test ! -s couchdb.1; then \
>../build-aux/dist-error couchdb.1; \
> else \
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
> (or simply removing i
On Fri, May 31, 2013 at 5:24 PM, Wendall Cada wrote:
> I'm limited on time today, but I'll spend some time testing and evaluate
> over the weekend. Do we have a ticket for this?
Awesome! COUCHDB-1711.
BTW: I'll be mostly AFK for the next week.
Cheers,
Dirkjan
On Thu, Jun 20, 2013 at 12:12 PM, Dave Cottlehuber wrote:
> 1. a special 1.4.0 release that only support R15B+ is 1.3.1 + the
> changes that are only on master at the moment (
> 1696-update-mochiweb-2-4-2 branch).
"Special" releases sounds... not good.
> 2. providing homebrew with a .patch file
On Wed, Jun 19, 2013 at 9:38 PM, Russell Branca wrote:
> Looks like I tried to get too fancy with embedding dropbox images. Here's
> public urls viewable on dropbox.com:
>
> all dbs: https://www.dropbox.com/s/0plfvfcwtaod0sz/Fauxton_all_dbs.png
>
> all docs and views:
> https://www.dropbox.com/s/7
On Thu, Jun 20, 2013 at 6:16 PM, Randall Leeds wrote:
> I think we should ship this as an addition to Futon in a release ASAP!
+1 for shipping in 1.4.0 alongside Futon!
Cheers,
Dirkjan
On Thu, Jun 20, 2013 at 10:18 PM, Dave Cottlehuber wrote:
>>> 3. a stable 1.3.1+R16B-backport fork for homebrew with the same fix as
>>> #2.. I would be ok to maintain that until the next master-based
>>> release if required.
>>> (1696-backport-mochiweb-2-4-2-1.3.x branch again). This would be fin
On Fri, Jun 21, 2013 at 1:58 PM, Jan Lehnardt wrote:
> I think this could be easily done by requiring a log-in for Futon proper,
> and changing CouchDB‘s setup procedure that the user/admin has to set
> a CouchDB Server Admin on first-start, something that makes sense for
> various other reasons a
On Wed, Jul 3, 2013 at 6:13 PM, Noah Slater wrote:
> So, I am proposing that we attempt to do a new release four weeks after the
> last release.
+1.
> One other change I am proposing: I think that in three weeks, we should cut
> whatever is ready. If that means a major point revision, so be it.
On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater wrote:
> Yep. One that date we can look at master and see what we have. If we have
> any features, then we bump the minor version. If we have anything that
> breaks backwards compatibility, then we bump the major.
So that means we have no guarantees of
On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt wrote:
> A database event is one of `created`, `updated`, `deleted`.
>
> The API endpoint supports a `?feed=` parameter with the
> options: `longpoll`, `continuous` and `eventsource`.
>
> A second parameter `timeout=` specifies when the server should
Some action items for myself.
On Wed, Jul 17, 2013 at 10:12 PM, ASF IRC Services
wrote:
> 19:20:35 [nslater]: it should also have some CTAs to check the github PR
> backlog, JIRA tickets with patches, etc
> 19:20:42 [nslater]: it's a call to action for people to prep so you can hit
> the ground
On Thu, Jul 18, 2013 at 11:22 AM, Dave Cottlehuber wrote:
> I wonder if Alex or Dirkjan might be interested in co-mentoring this,
> I can take care of paperwork & stuff, but I'm not in a position to
> offer useful technical guidance as I'm not a pythoneer yet.
I'm happy to review Python code for
Fauxton Folks (and other interested parties),
Yesterday at the meeting there was some consensus that we're shipping
Fauxton in 1.4, alongside Futon. I was talking about this with Russell
and Garrett on IRC before that (and they were in the meeting), but I
just want to make sure we have our ducks i
On Mon, May 27, 2013 at 5:42 PM, Robert Newson wrote:
> I'd like to vote on two questions;
>
> 1) That we adopt the git commit message guidelines above.
> 2) That we delete NEWS/CHANGES from master before the next release after
> 1.3.1.
>
> The voting rules are lazy consensus with a 72 hour waiti
On Thu, Jul 18, 2013 at 4:32 PM, Benoit Chesneau wrote:
> I'm not sure what prompted the urgency of this change but the vote was
> aborted until we find a way to generate the new changelog correctly and
> keep the old one.
>
> Note that I quite like to have the changes available on the doc (though
On Thu, Jul 18, 2013 at 10:55 PM, Russell Branca wrote:
> Agreed. Alright, new Fauxton ship target is 1.5.
So that would likely be the August release, then?
And, to consider all the options: how much more delay *would* be enough
to ship 1.4? A few days? A week?
Cheers,
Dirkjan
On Thu, Jul 18, 2013 at 9:21 PM, Yashin Mehaboobe wrote:
> I've installed couchdb on a Linux VPS. I cloned the git repository and
> compiled it from source but I haven't created any databases yet. I've looked
> through the /share/doc/src rst files as well as the sphinx conf.py file. How
> I plan o
On Sat, Jul 20, 2013 at 9:19 PM, Jan Lehnardt wrote:
> I thought marking it as EXPERIMENTAL until there are tests is an ok trade-off
> about getting this into people’s hands and potentially get a few more bug
> reports before we call this stable.
>
> Dirkjan, do you think this is blocking the merg
Are we comfortable now advertising as CORS?
If not, what would it take to make us comfortable?
If we do, is the experimental part only in the docs or do we have code
stuff for that?
Cheers,
Dirkjan
On Wed, Jul 17, 2013 at 10:37 PM, Jan Lehnardt wrote:
> I spent a day and a half to get this sorted and got nowhere. Be my guest :)
What are we doing to make sure we get tests at some point? Is there an
issue? Are you or is someone else taking responsibility?
Cheers,
Dirkjan
On Mon, Jul 22, 2013 at 12:21 PM, Jan Lehnardt wrote:
>> X-Couch-API-Stability idea is too complex. Better to have only
>> `X-Couch-Deprecated: true`. Experimental features should be enabled in
>> configs so user takes responsibility for any behavior it provides.
>
> Fair point, happy to have the
On Mon, Jul 22, 2013 at 1:57 PM, Alexander Shorin wrote:
> - Big merges: we'll have a lot of "unstable" or not "tested
> extensively in production" API for quite large period of time.
I don't think that's an actual problem. Big merges (that are not
confined to a single or a small set of API endpo
Hi there,
Due to silly circumstances over the past few days, I haven't been able
to gather up release notes before now, and it appears that that will
require some more work. I'm going to Relax now and try again tomorrow
in the morning. I apologize to everyone who has rushed things to be
ready.
Ch
On Wed, Jul 24, 2013 at 8:27 AM, Jan Lehnardt wrote:
> Jason said some work was done by someone else (OcastaLabs), so we need to do
> some legal due diligence before we can make a branch in ASF-git land.
>
> In the meantime, I believe this is the code:
>
> https://github.com/iriscouch/browserid_
On Wed, Jul 24, 2013 at 9:14 AM, Benoit Chesneau wrote:
> Dirkjan,
>
> What is the status of the spec at the moment? Can we now pass different
> providers in the login?
>
> I'm really curious about the current status, do you have any link for
> dummies that could help?
Persona as a whole is said
On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater wrote:
> So, if you have any thoughts about this, speak up!
For me, CouchDB is about:
- Schema-less/document-oriented
- Replication
I also like that it's built "of the web", as Jacob KM wrote, but for
my usage, that's mostly extra convenience and ele
On Wed, Jul 24, 2013 at 1:42 PM, Noah Slater wrote:
> For the why, I am thinking something more akin to the sorts of stuff that
> CouchDB can enable. The peer-to-peer replication of apps and datasets. Of
> being able to have your data everywhere. Why? Why are these things
> important to us? Replic
On Tue, Jul 23, 2013 at 10:04 PM, Dirkjan Ochtman wrote:
> Due to silly circumstances over the past few days, I haven't been able
> to gather up release notes before now, and it appears that that will
> require some more work. I'm going to Relax now and try again tomorrow
On Fri, Jul 26, 2013 at 11:56 AM, Jan Lehnardt wrote:
> Not to worry! Let us know if we can help with anything!
You can: please review the changelog I've come up with. It was a bit
messy, because the 1.3.x branch dragged on for a long time.
Either review the spiffy HTML version:
http://dirkjan.
On Fri, Jul 26, 2013 at 2:57 PM, Alexander Shorin wrote:
> erhm..Dirkjan,
>
> you should know that "USE=latex emerge sphinx" is a bad style to
> emerge things since this would be broken on next emerge -uDN world
> why not to suggest to put this flag to /etc/portage/package.use
> instead as Gentoo
On Fri, Jul 26, 2013 at 3:09 PM, Alexander Shorin wrote:
> Oh how I hope that you have to right. The first thing that they'll hit
> will be missed sudo, I'm sure (:
> Ok, I'll fix this in docs.
There's not really that many developers who'll be reading this, anyway.
Cheers,
Dirkjan
On Mon, Jul 29, 2013 at 6:13 AM, Jason Smith wrote:
> Thanks, Jim. That is basically my plan. To be clear, I would ship
> "outsourced mode" (browserid.org hosted JavaScript and verification)
> in a CouchDB release. It's just that I would work to get "tinfoil hat
> mode" added in for a subsequent r
On Mon, Jul 29, 2013 at 12:02 PM, Jason Smith wrote:
> To clarify, "tinfoil hat" mode is actually just a complete
> implementation of the RP role, notably that it does not require the
> POST to browserid.org/verify to verify an assertion. Thus, CouchDB
> could be used on an intranet where an exist
On Mon, Jul 29, 2013 at 5:26 PM, Jim Klo wrote:
> Right. The key difference from other 3-party solutions is that, once the
> BrowserID protocol is up and running with a really stable release, Identity
> verification should be untraceable by the IdP. BrowserID uses a model where
> the client ge
On Mon, Jul 29, 2013 at 5:24 PM, Dale Harvey wrote:
> On the topic of browser_id support in CouchDB, it feels like this is a big
> chance to push for usable plugins, should the aim for this not to be
> included into core but to be available as a one click install from
> futon/fauxton (this and geo
Dear community,
I would like to propose that we release Apache CouchDB 1.4.0.
The project aims to produce time-based releases. If your favourite
feature is not ready for this version, it can be included in the next
version. However, if you know of anything that should block the
release, please sp
On Wed, Jul 31, 2013 at 9:35 PM, ASF IRC Services
wrote:
> Members present: nslater, jan, mainerror, Kxepal
Sorry I couldn't be there tonight. Thanks for rounding out the issues
with the release. Will try to dive in tomorrow.
Cheers,
Dirkjan
P.S. Plugin stuff sounds awesome.
On Wed, Jul 31, 2013 at 9:35 PM, ASF IRC Services
wrote:
> 2. 1.4.0 release
> a.
> http://mail-archives.apache.org/mod_mbox/couchdb-dev/201307.mbox/%3CCAKmKYaCRhU%3DECCNVz%2BvmY8QwKM4G9%3Da1XGB7dENQdYeiLAZrnw%40mail.gmail.com%3E
> (Kxepal, 2)
> b. help djc and dch to solve blocking issues 13
On Wed, Jul 31, 2013 at 6:14 PM, Robert Newson wrote:
> Note: there's a blocking bug against the new "configurable whitelist
> of user document properties" which needs to be either resolved, marked
> "won't fix", or the current work on master needs reverting.
I'm distchecking my way through
1334-
On Sat, Aug 3, 2013 at 5:48 PM, Dirkjan Ochtman wrote:
> I'm distchecking my way through
> 1334-revert-feature-view-server-pipelining and
> https://github.com/adamlofts/couchdb/tree/1493-fix-zerobyte-json-parsing.
This part is done, I merged both to master. Tests are clean for
On Wed, Aug 7, 2013 at 6:44 PM, Noah Slater wrote:
> But this leaves us in a bit of a pickle, because the code is on master. And
> part of our agreed-upon-but-not-documented Git workflow is that master is
> always shippable.
>
> Another part of our agreed-upon-but-not-documented Git workflow is th
On Wed, Aug 7, 2013 at 11:28 PM, Noah Slater wrote:
> From what I understand, Dirkjan will be on vacation for 10 days. Nobody
> else has indicated that they intend to do the release. So perhaps that's
> enough of a window?
Yeah, final message; I'm bowing out for now. Would be awesome if
someone e
On Fri, Aug 9, 2013 at 11:10 AM, Alexander Shorin wrote:
> Hope to finish some few base things till 1.4 votes (thanks for Dirkjan
> vacations, it's not too late for docs updates, right?) before merge
> it.
I'd like to do a thorough review of your branch, ideally before it
gets merged (though it m
On Thu, Aug 8, 2013 at 4:21 PM, Sue Lockwood wrote:
> If you want to check out the new design, go to Fauxton
> https://github.com/apache/couchdb/tree/master/src/fauxton
> And follow the instructions on the readme file.
Awesome! Are we confident enough to ship this as experimental in 1.4?
Cheers,
ease has been
> trickier than usual, too. ;)
>
>
> On 7 August 2013 22:42, Dirkjan Ochtman wrote:
>
>> On Wed, Aug 7, 2013 at 11:28 PM, Noah Slater wrote:
>> > From what I understand, Dirkjan will be on vacation for 10 days. Nobody
>> > else has indicated that t
On Sun, Aug 18, 2013 at 9:20 PM, Noah Slater wrote:
> So we re-cut from master, keep Fauxton in, but do not link to it. As was
> the original plan. No need to remove Fauxton, on master or the branch. Nor
> should we hold back the release for the Fauxton work.
Yup, sounds good to me.
Cheers,
Dir
On Mon, Aug 19, 2013 at 10:47 PM, souza.davirs wrote:
> thanks for help!
Please redirect your messages to u...@couchdb.apache.org instead of
dev@couchdb.apache.org. This list is intended for discussion of
development of CouchDB itself, not developing code on top of CouchDB.
Cheers,
Dirkjan
Dear community,
I would like to release Apache CouchDB 1.4.0-rc.1.
Changes since last round:
*
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.4.x
We encourage the whole community to download and test these release
artefacts so that any critical issues can be r
Dear community,
The vote has now closed.
Thank you to everyone who participated!
The results are:
+1 - 9 votes
+0 - 0 votes
-0 - 0 votes
-1 - 0 votes
The vote has passed, I will be making the release shortly.
Thanks,
Dirkjan
Hi everyone,
I think we want to release binaries with the release. Are people
available to build these today?
http://wiki.apache.org/couchdb/Release_Procedure#Preparing_the_Binary_Packages
We would like to release todayish because that would get 1.4.0 into
the upcoming Ubuntu release cycle. This
Dear community,
Apache CouchDB 1.4.0 has been released and is available for download.
CouchDB is a database that completely embraces the web. Store your
data with JSON documents. Access your documents with your web browser,
via HTTP. Query, combine, and transform your documents with
JavaScript. C
Dear community,
Being a volunteer organisation, we rely on you to help us promote releases.
Here is the official blog post:
https://blogs.apache.org/couchdb/entry/apache_couchdb_1_4_0
Here is the official tweet:
https://twitter.com/djco/status/374966350789083136
And Google+ post:
Hi all,
We're quickly getting towards the end of this release cycle. I'll be
your RM again; ideally I'd get an artefact out on October 3, as I'm
leaving for a few days after that. Some things on the table:
- Docs work: we'll be shipping Alexander's branch (whether he wants to
or not ;))
- Fauxton
On Wed, Sep 25, 2013 at 9:04 PM, Dave Cottlehuber wrote:
> Would there be any objections to pushing minor doc fixes & additions directly
> to master?
No! In fact, I was doing that already even before 1.3.1 came out, I think.
> The quicker we can get updates out into docs.couchdb.org, the better
On Mon, Sep 30, 2013 at 7:18 PM, Jan Lehnardt wrote:
> I just pushed a branch remove-e4x-tests that removes all traces of E4X
> (which we deprecated in 1.3.0 / last year).
>
> How does everyone feel about getting that into 1.5?
+1. Can you formulate something for the changelog? Either put it in
t
Hi all,
I'm looking at cutting an RC1 in about 24h plus change. There are a
few issues that look like we could/should get them in before then:
https://issues.apache.org/jira/browse/COUCHDB-1425
DoS-vulnerable, and we have a branch to fix it... Any reason we
haven't merged this?
https://issues.ap
On Wed, Oct 2, 2013 at 3:11 PM, Adam Kocoloski wrote:
> Ah, I've been sitting on a fairly significant fix for retries of attachment
> transfers during replication. Would love to see if I can sneak that in. I'll
> make it a priority as soon as I have a couple of minutes today.
Sounds good, than
On Wed, Oct 2, 2013 at 7:48 PM, Jan Lehnardt wrote:
> How does everyone feel about getting this in?
+1 SHIP MOAR AWESOME.
On Wed, Oct 2, 2013 at 9:23 PM, Sue wrote:
> This is temporary to get fauxton into this release. For the next release,
> we hope to have fauxton as part of the build script.
>
> That being said, Fauxton is ready to go.
\o/
On Wed, Oct 2, 2013 at 11:03 AM, Dirkjan Ochtman wrote:
> I'm looking at cutting an RC1 in about 24h plus change.
This is about 25h ago now. I still have to do changelog, but there's
only about a couple hours left.
Jan, plugins?
Adam, 1901?
Jason, X-Forwarded-For?
Cheers,
Dirkjan
On Thu, Oct 3, 2013 at 1:36 PM, Dirkjan Ochtman wrote:
> On Wed, Oct 2, 2013 at 11:03 AM, Dirkjan Ochtman wrote:
>> I'm looking at cutting an RC1 in about 24h plus change.
>
> This is about 25h ago now. I still have to do changelog, but there's
> only about a couple
On Thu, Oct 3, 2013 at 4:14 PM, Alexander Shorin wrote:
> There some other issues that was planned to be fixed for 1.5. release:
> https://issues.apache.org/jira/browse/COUCHDB-1572?jql=project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%221.5.0%22%20ORDER%20B
On Thu, Oct 3, 2013 at 2:40 PM, wrote:
> diff --git a/share/doc/src/whatsnew/1.5.rst b/share/doc/src/whatsnew/1.5.rst
> --- a/share/doc/src/whatsnew/1.5.rst
> +++ b/share/doc/src/whatsnew/1.5.rst
> @@ -29,3 +29,11 @@ Version 1.5.0
> .. warning::
>
> This version is not released yet.
> +
> +*
1 - 100 of 559 matches
Mail list logo
