Backwards compatibility
I was just trying to upgrade the first of my servers to 1.2, and it wasn't that pretty. As I understand it, compatibility with pre-0.10.0 databases has been dropped. However, this isn't mentioned in the release notes, nor in the Breaking changes. Thus, I had to downgrade to 1.1.1, compact a database and install 1.2.0 again. This is just a PITA, and it seems fairly trivial that something like this should be in the release notes and in the breaking changes. Apart from that, it's also just a pain to find out if I have any databases in an old version. The only simple way that I can see is looking at the /db page (either in a browser or scripted), for each database. It would be helpful if there was perhaps something like a Futon page listing my databases along with their on-disk version numbers and perhaps other relevant sysadmin information (like on-disk size and the new percentage that's used to trigger auto-compaction). As it is, I wasn't aware of the relevance of the on-disk format version, so some databases that just don't need compaction (either because they don't change that often, or because there's not that many documents in there) didn't get compacted. I think I'm perhaps slightly more attuned to the internals of CouchDB (at least I read the developer mailing list) than the average user, so this might be even worse for other users. Also, perhaps the auto-compaction can be upgraded to (optionally) also compact if the on-disk version if older than current-1, so people don't have to pay as much attention to this. Presumably there's already some scheduling going on to prevent auto-compaction from hitting every database at the same time. Cheers, Dirkjan P.S. I'm slightly annoyed, and it probably shows; I hope that doesn't diminish the value of this feedback.
Re: Backwards compatibility
On Mon, Apr 9, 2012 at 15:12, Dirkjan Ochtman dirk...@ochtman.nl wrote: I was just trying to upgrade the first of my servers to 1.2, and it wasn't that pretty. As I understand it, compatibility with pre-0.10.0 databases has been dropped. However, this isn't mentioned in the release notes, nor in the Breaking changes. Thus, I had to downgrade to 1.1.1, compact a database and install 1.2.0 again. This is just a PITA, and it seems fairly trivial that something like this should be in the release notes and in the breaking changes. Forgot to mention something I'm not sure is an issue, but should be checked: how resistant is CouchDB against inaccessible _users or _replicator? It seems like even _users might at some point be in an unsupported on-disk version. I run all of my couches in Admin Party mode so I never even look at the _users database, but it probably wouldn't work all that well. Cheers, Dirkjan
Re: Backwards compatibility
On Mon, Apr 9, 2012 at 15:41, Benoit Chesneau bchesn...@gmail.com wrote: Your probably right about the user migrations. Basically if your use document doesn't have any owner doc a normal user won't be abble to update it. On the other hand it should still be possible to update/delete them with an admin. Can ou create separate issues about this on jira ? (one for migration , and the other for the users db migration) ? It will help to track the problem. Sorry, not sure what you mean here. Cheers, Dirkjan
Re: Help shape the future of CouchDB: your voice needed!
On Sun, Apr 15, 2012 at 12:02, Robert Newson rnew...@apache.org wrote: He's what I have so far: https://gist.github.com/2387973 Looks nice. I think it might make sense to fold WebSockets and EventSource into a single item, i.e. AFAICT the main point is to allow non-polling forms of consuming _changes from JavaScript-in-the-browser. Cheers, Dirkjan
Re: website jira
On Tue, Apr 17, 2012 at 16:27, Miles Fidelman mfidel...@meetinghouse.net wrote: With all due respect and appreciation for your efforts marketing is one thing, utility is another. While there's value to marketing, (IMHO) utility counts more. We're not talking about a magazine ad, we're talking about a web site that people have taken some effort to find and go to - they're (we're) looking for information - if the information isn't there, it doesn't matter how pretty the site is. I'm sure Noah agrees with you, and the information/utility value will get added soon. However, there's also plenty of value to be found in having a site that's easy on the eyes. Perhaps the balance swung a little too far in the marketing direction this time, but that will get corrected. Arguing over it on this mailing list doesn't really help at this point -- pointing out stuff that you would like to be able to easily access and isn't, currently, (like your MarkMail point, on which I probably agree) does. Even better if you add notes like that to the aforementioned wiki page. Cheers, Dirkjan
A slightly crazy idea?
Hi all, It seems like view indexing gets hit for one of two reasons: 1. There are new documents (or document revisions) to index 2. The design document has been updated Currently, for both cases, the default is to have the view wait until after all documents (revisions) have been indexed using the latest design doc contents before returning results. I was wondering if it might be sensible to keep the indexing the same for the first case, but default to returning stale results (possibly including using the previous design doc to index the new documents/revisions) and kick off a process to regenerate results with the new design doc (update_after-like). There could be a negative value for stale= to indicate that the view should wait (i.e. stale=wait). Rationale: I usually want to wait for indexing new revisions, because we don't generally add revisions at high speed. However, old views have generally worked fine for a long time, and it's annoying when many parts of my app have to wait for the index to regenerate. Does that make sense? Alternatively, are there other ways to attack this issue? Maybe I could copy my design doc, update it, hit it, then move it to the old name when it's done? If that works, perhaps Futon could make that easier? Cheers, Dirkjan
Re: A slightly crazy idea?
On Tue, May 1, 2012 at 6:07 PM, Robert Newson rnew...@apache.org wrote: I may have missed a nuance but I don't see that there's anything you're asking for that isn't covered by https://wiki.apache.org/couchdb/How_to_deploy_view_changes_in_a_live_environment. Well, some Futon support for that stuff, I guess. Cheers, Dirkjan
Re: Post-mortem
On Fri, May 11, 2012 at 2:29 PM, Robert Newson rnew...@apache.org wrote: Making a single view indexing process faster keeps coming up. For one thing, it's not that easy, otherwise it would have been done by now. For another, this problem vanishes when you shard (and the BigCouch merge will bring this to CouchDB). What does sharding mean in this context? Running CouchDB/BigCouch on multiple servers, or just running multiple processes on a single box? If the latter, why can't we run multiple threads/Erlang processes within a single shard/OS process? If the former, that's kind of silly, in the sense that building indexes (at least for me) is CPU-bound but leaves many of the cores in my server idle. Cheers, Dirkjan
Re: Post-mortem
On Fri, May 11, 2012 at 2:44 PM, Robert Newson rnew...@apache.org wrote: Fundamentally, the issue is that updating a view is processing an incoming, ordered list of changes, there's not much parallelism to be had there. Why is that? I don't see how the list of changes is ordered. ISTM that updated documents may be passed to the view indexer in any order, which is why M/R works. If that's true and computing keys and values is CPU-bound, parallelizing running the view function on the updated documents shouldn't be that hard. Cheers, Dirkjan
Re: Post-mortem
On Fri, May 11, 2012 at 3:25 PM, Robert Newson rnew...@apache.org wrote: We're veering off-topic here, but there are several remaining issues. First is that the view file is at some update_seq relative to the database file. Being at update_seq N for a view means it has all the changes up to and including N, but nothing after N, so while those updates could be processed in parallel, they'd have to be applied to the view process and view file in order. Yeah, you'd have to serialize and buffer when writing to disk again. Secondly, and more importantly, is how to handle rows that, for whatever reason, cause an exception when evaluated in the function (e.g, the common case where there's an undefined property and no guard clause). If the order is not determined, then two database, with the same data and same view code, will have different view results for the same input. I'm actually not clear on what happens with erroring view functions. Does it just stop processing any further document revisions? In any case, it seems okayish to do have the document updates be in a defined ordering but parallellize execution of the view function, then serialize back into document order when the results come back, doing a little buffering if the results aren't in order. Cheers, Dirkjan
Re: Hierarchical comments Hacker News style
On Wed, May 16, 2012 at 2:53 PM, Luca Matteis lmatt...@gmail.com wrote:
Isn't there a better way?
Since the ordering of descendants depends on the scores of ancestors
(if you're talking about getting the whole thread in order), and you
don't want to update descendants when ancestors get modified (scores),
there by definition is no way to cleanly do this. I think the best way
you can do it is to emit the [ancestor_id, score] for each comment,
which I think would allow you to build the tree structure in a single
loop over all documents:
docs, roots = {}, []
for key, doc in documents:
if key[0] == null:
roots.append(doc.id)
docs[doc.id] = doc
if key[0]:
docs[key[0]].children.append(doc.id)
(In horrible pseudo-Python-JS.)
Cheers,
Dirkjan
Re: Hierarchical comments Hacker News style
On Wed, May 16, 2012 at 3:19 PM, Luca Matteis lmatt...@gmail.com wrote: Ok. Where would it be appropriate to build such a tree? Can I do it in a list function? I'm using Couch directly and not interacting with it using other languages, so I need Couch to do all the work. Should be possible to do it in the list function, but I haven't worked with list functions before. Also note that this topic is solidly off-topic for dev@, and should actually be discussed on user@. Cheers, Dirkjan
Re: Efficient way to identify documents
On Thu, Jun 7, 2012 at 2:57 PM, pjmorce pji...@gmail.com wrote: Is there any more efficient way to do this? I think this solution is not performant when large amount of documents will be in the database... You should really ask the user@ list. Cheers, Dirkjan
Re: [PROPOSAL] Official roadmap, and merge procedure
On Sat, Jun 16, 2012 at 6:45 PM, Noah Slater nsla...@tumbolia.org wrote: 1. We'd like to proposed formal time-based releases Love it. In fact, I think I proposed it before. I think this will be a much better way of making CouchDB administration easy. Details of these proposals can be found here: http://wiki.apache.org/couchdb/Roadmap_Process Looks good, but supporting 4 feature releases at the same time sounds like a lot of work, particularly given the current amounts of developer participation. ISTM supporting two, maybe three releases would probably be Good Enough. Cheers, Dirkjan
Re: dependancy tracking
On Thu, Jun 21, 2012 at 9:23 AM, Dave Cottlehuber d...@muse.net.nz wrote: I think we're only talking about OTP apps (snappy, ejson/jiffy, mochiweb) here. Would you want those as separate packages? Yes, preferably. To give an example, if for some reason there was a security vulnerability in snappy, it would be great if the distro doesn't have to go around checking which packages might package their own snappy, and instead can just update the canonical snappy. This goes for the other stuff, too. I should really have helped out more on making it easier to build against system versions of these apps, but that requires some autotools and/or Erlang foo that I really don't have. I filed https://issues.apache.org/jira/browse/COUCHDB-1458 for snappy two months ago. Cheers, Dirkjan
Re: dependancy tracking
On Tue, Jul 3, 2012 at 9:07 AM, Paul Davis paul.joseph.da...@gmail.com wrote: Also, we patch a number of our Erlang deps, so that's another vote in favor of having them in the repo. It seems like it would be a Good Idea to have those patches go upstream. Cheers, Dirkjan
Re: http PATCH support?
On Mon, Jul 30, 2012 at 5:28 PM, Dave Cottlehuber d...@muse.net.nz wrote: Any other corner cases? I don't think CouchDB should invent it's own JSON patching scheme. I guess it would be best to implement, say, http://tools.ietf.org/html/draft-pbryan-json-patch-04 (but make sure to track the ID until it becomes a standard). Cheers, Dirkjan
Re: Docs, second try
On Tue, Jul 31, 2012 at 4:01 PM, Robert Newson rnew...@apache.org wrote: Those are all good points, thanks. I haven't used Sphinx, is it popular? Are there any other choices? It's quite popular. Look at readthedocs.org (free Sphinx hosting) or the Python documentation for some examples. Using Sphinx/reST would definitely make it easier for me to finally contribute more to CouchDB, whereas DocBook would definitely not. Cheers, Dirkjan
Re: Docs, second try
I've converted the docs into reST + Sphinx here (via Pandoc): https://github.com/djco/couchdb/tree/docs/share/docs/sphinx-docs http://couchdb.readthedocs.org/en/latest/ This needs a little more reordering and structuring, but I think it looks pretty good already. I'd be happy to work on this more so it'll be a good resource before the next release. Cheers, Dirkjan
Re: Docs, second try
On Wed, Aug 1, 2012 at 1:11 PM, Dave Cottlehuber d...@muse.net.nz wrote: Do we have a concensus now to go for RST python nirvana? If we do, a proposed plan forward, with Dave and Robert N.: - Keep the docs branch as it is, with DocBook docs - Iterate on the Sphinx docs in the docs branch (for example based on my csets) - When everything has properly been converted to Sphinx, remove DocBook files - At this point, merge docs into master and do further improvement This means the DocBook version is safely in repository history for archival purposes. Sphinx building can easily be integrated into Makefiles, we'll also need to update some READMEs etc to document Sphinx dependencies. We should probably not wait until the docs are perfect before merging into master, but make sure everything from the DocBook version is in there. I'll note that I think the pace of movement around the Sphinx stuff indicates that this significantly helps contribution to the docs, so I think this would be a great way to move forward. Cheers, Dirkjan
Re: Docs, second try
On Wed, Aug 1, 2012 at 2:00 PM, Noah Slater nsla...@tumbolia.org wrote: What is Pytohn nirvana? Is that related to the Sphinx effort I checked out towards the end of this thread? Sphinx is written in Python, but I'm not sure why Dave mentioned the Python nirvana. You don't need to write any Python to improve Sphinx docs, just installing some Python-based tools to turn them into HTML or any of other output formats. I think once the docs are converted to RST and the Sphinx work looks okay, we should merge this into master, and I am offering to take over from there. I will happily integrate this into the build system, hook it up with Futon, update the README files, etc. What is standing between here and there? What is there left to do before we can get the Sphinx work into master for further iteration? The conversion from DocBook to Sphinx isn't perfect, so it needs a bit of tweaking to fix up links and some minor syntax issues. I'm happy to work on that; I think it makes sense to keep this work on the docs branch for a bit longer while these small issues get fixed. I'm also happy to do further work after that (though I may not be the best person to work on autotools integration, other than calling the Sphinx Makefile from one of the other Makefiles). Cheers, Dirkjan On Wed, Aug 1, 2012 at 12:28 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Wed, Aug 1, 2012 at 1:11 PM, Dave Cottlehuber d...@muse.net.nz wrote: Do we have a concensus now to go for RST python nirvana? If we do, a proposed plan forward, with Dave and Robert N.: - Keep the docs branch as it is, with DocBook docs - Iterate on the Sphinx docs in the docs branch (for example based on my csets) - When everything has properly been converted to Sphinx, remove DocBook files - At this point, merge docs into master and do further improvement This means the DocBook version is safely in repository history for archival purposes. Sphinx building can easily be integrated into Makefiles, we'll also need to update some READMEs etc to document Sphinx dependencies. We should probably not wait until the docs are perfect before merging into master, but make sure everything from the DocBook version is in there. I'll note that I think the pace of movement around the Sphinx stuff indicates that this significantly helps contribution to the docs, so I think this would be a great way to move forward. Cheers, Dirkjan -- NS
Re: Docs, second try
On Fri, Aug 3, 2012 at 5:47 AM, Benoit Chesneau bchesn...@gmail.com wrote: I'm trying to summarize the actions we need to put in place here: 1. create the doc branch , start to track the process of the conversion to make sure we didn't lost an information. I have a docs branch working on this: https://github.com/djco/couchdb/commits/docs 2. hack the autotools to handle this makefile and the needed check I can make a start with that, but Noah will take it further as needed. 3. hoock it to git? (can we do that actually on the apache website) I've set this up for readthedocs.org (hook from my branch, mentioned above), we can switch that later. Where do we host the doc? I'll leave that to the committers. readthedocs.org works nicely, though, will let you do automatic updating using a hook, and I think can do custom domains. Where do we place the donated docs? The consensus in IRC was that they would remain in the repository history of the docs branch, but not in new commits once the Sphinx conversion is complete. Cheers, Dirkjan
Re: Sphinx docs
On Sunday, August 12, 2012, Dave Cottlehuber wrote: Let me know if that's OK with y'all. TBH I don't really like squashing (since I think having full small-chunk history is useful), but if that's the way CouchDB commits are done I guess it's fine. Stripping out the docbook tool chain sounds like a good idea. Cheers, Dirkjan
Re: [VOTE] acceptance of CouchBase-provided API documentation (ref COUCHDB-1523)
On Thu, Aug 23, 2012 at 2:27 PM, Dave Cottlehuber d...@muse.net.nz wrote: I would like call a vote for including the CouchBase API documentation into the CouchDB project: Source repo: https://github.com/janl/couchdb-docs commit SHA: 9fc95b422060d020ba25f559e893fc7fb98c9a15 NB only the required XML* files to complete the export to RST format will actually added to the CouchDB git repo. +1. Cheers, Dirkjan
Re: Part2: What's up dev? About couchapps.
On Tue, Sep 25, 2012 at 10:16 AM, Simon Metson si...@cloudant.com wrote: I was thinking about this reference implementation this morning. I think having a bunch, in multiple languages might not be a bad idea. So a simplified erica, couchapp.py, the node.js couchapp tool etc could all be there. That would make picking up and reusing in a 3rd party app easier (since I'd just import/require the thing) and might help constrain the functionality and scope down to something really minimal… Having a bunch sounds like a strong argument in favor of not shipping them with Apache CouchDB. Cheers, Dirkjan
Re: Part2: What's up dev? About couchapps.
On Tue, Sep 25, 2012 at 1:08 PM, Noah Slater nsla...@tumbolia.org wrote: I think the multiple language thing is a slippery slope. By extension, we should ship client libraries too then. No way. The goal is to bootstrap Futon, and to provide a simple tool to demo in our docs. This whole discussion makes me even more convinced that CouchDB and CouchApps should be separate things. In my view, CouchDB is a database. The REST API and some of the other features it offers conspire to make this CouchApp thing possible, but it shouldn't distract from CouchDB-the-database. Sure, concrete feature requests for CouchApp-type things should be fed back into CouchDB development, but that doesn't mean that CouchDB itself (or Futon, which I consider an important part of CouchDB) should be organized around CouchApps. I think that currently, the swirling vortex of CouchApp-like projects is more of a distraction to the CouchDB community than a force for constructive feedback. Cheers, Dirkjan
Re: couch has docs!
On Thu, Sep 27, 2012 at 7:07 AM, john.tiger john.tigernas...@gmail.com wrote: maybe it's late, but I cannot figure out the docs build from linux make html did not work, neither did python conf.py - what am i missing ? It would be helpful if you were somewhat more specific than did not work. In any case, you need to install the Sphinx tool (written in Python), along with its dependencies (just docutils and pygments, I think). easy_install, pip, or your friendly local package manager should be able to handle this with ease. Cheers, Dirkjan
Re: couch has docs!
On Wed, Sep 26, 2012 at 11:02 PM, Dave Cottlehuber d...@jsonified.com wrote: - /docs/ lags master a wee bit, nothing serious Do we have an ETA (or dependencies) for merging docs back into master? Cheers, Dirkjan
Re: Part1: What's up dev? About energy.
On Fri, Sep 28, 2012 at 8:41 PM, Noah Slater nsla...@tumbolia.org wrote: Let's focus on getting the docs integrated, and then chasing up BigCouch. And then I think we should focus on the stuff you mention. Though, my next biggest priority is actually implementing a release cadence. Can I suggest that the 1.3 release is prioritized over the BigCouch stuff? Cheers, Dirkjan
Re: OTP releases and autotools
On Sat, Sep 29, 2012 at 10:48 AM, Benoit Chesneau bchesn...@gmail.com wrote: Voilà, hopefully this thread can be a good start for merging rcouch, bigcouch apache couchdb and will ease merge of the other features imo. As a distributor, the most important deficiency in today's release tarballs is the fact that pretty much all the dependencies are bundled, with no convenient way to use system copies. IMO this should be done especially for C libraries like snappy and spidermonkey, but preferably also for the Erlang parts with an alive upstream. I haven't tracked it to closely, but I always get the impression that CouchDB just vendors upstream and isn't that good about making sure patches end up upstream as well (and tracking what versions correspond to the dependencies shipped with a given CouchDB tarball). Cheers, Dirkjan
Re: OTP releases and autotools
On Mon, Oct 1, 2012 at 3:16 PM, Dave Cottlehuber d...@jsonified.com wrote: Seems like the right thing for couchdb to do, but I'm not sure I understand this fully. Do you mean that you'd like to (say) ./configure --use-this-snappy-library --use-that-other-library approach, and as a distributor you would be deciding at that point which OTP release other dependencies are required, to build into your rpm or deb packaging tool? In my ideal scenario, CouchDB comes with an INSTALL.txt that outlines exactly what versions of dependencies are required (i.e. snappy-1.0.1 or newer), and configure would have a --with-system-snappy option. That would allow me to encode the dependencies into my packaging system, so it'll use whatever's already available and install the rest before trying to build CouchDB. Cheers, Dirkjan
Re: OTP releases and autotools
On Mon, Oct 1, 2012 at 3:33 PM, Benoit Chesneau bchesn...@gmail.com wrote: Not sure what you mean. spidermonkey is choosed on the system while snappy is build statically if it's what you mean. My proposal for package maintainer is to use the autotools for that. Which would solve all of their needs. The autootols here would detect or use the path choosen by the package maintainer. While we keep the possibility to build static releases. Sounds about right. About upstream version, I don't think it's really a problem. We shouldn't stop ourself to improve couchdb just because a distributions is slow to upgrade to latest stable release. Which doesn't mean we should always choose an upstream version. It should be choosed because it will improve the user experience. I'm not saying you have to wait for distributions to upgrade stuff, I *am* saying that it would be useful if you get upstream for CouchDB dependencies to release the fixes you need before releasing the version of CouchDB that relies on them. And that you then clearly communicate what versions those are, so that distributors can pick up the new versions and build everything together. Cheers, Dirkjan
Re: 1.3.0 discussion
On Wed, Oct 3, 2012 at 7:42 PM, Robert Newson robert.new...@gmail.com wrote: imo, 1.3 should be bug fixes, docs and CORS, the latter being the most at-risk. There's also a bunch of other stuff already in the tree, right? I think there was a new view processor or something, and EventSource support for changes feeds? Cheers, Dirkjan
Re: Moving JIRA emails to a separate list
On Sat, Oct 6, 2012 at 11:47 AM, Noah Slater nsla...@tumbolia.org wrote: Should we move JIRA emails to a new list? I previously complained about the JIRA emails. I've since filtered them to mark them all as read. I really like a compromise I've seen on another list: the list only gets email for each new bug. I believe that's reasonable because everyone gets to pick the bugs they're interested in and CC themselves on those, instead of everyone getting every small bug change. Some kind of weekly bug summary would also be nice (i.e. which bug I wasn't CC'ed on was the most active). Cheers, Dirkjan
Re: Branching for the CouchDB 1.3 release
On Tue, Oct 23, 2012 at 6:42 PM, Robert Newson rnew...@apache.org wrote: Can I get some votes on my proposal to branch today please? Yes, please! Cheers, Dirkjan
Re: Futon.Next
On Thu, Oct 25, 2012 at 12:19 PM, Garren Smith g...@redcometlabs.com wrote: What Couchapp tool do we use? Erica seems a good choice with it being talked about with Couchdb otherwise Nodejs + Couchapp + grunt.js could also be a good fit. Some decisions that have already been made: Futon.Next will be a single page couchapp. Using node.js seems to be at odds with having a single-page CouchApp? Also, please don't build this on top of node.js. I would consider it a regression if I have to use another application server along side CouchDB just to be able to use a nice CouchDB frontend. Cheers, Dirkjan
Re: Is pagination possible with multiple keys query?
On Thu, Oct 25, 2012 at 5:54 PM, boazc bcit...@gmail.com wrote: Using keys with startkey is not possible, so I don't know how to tell couchdb to start from a given document of a given key (in my case of using keys parameter). Please discuss this on the user list, not the dev list. Cheers, Dirkjan
Re: Futon.Next
(please don't top-post) On Thu, Oct 25, 2012 at 6:01 PM, Garren Smith g...@redcometlabs.com wrote: I think I need to explain that bit. If we want to use Bootstrap and less.js we need a build tool that will compile the less files into css and then upload the couchapp into couchdb. Grunt.js is a good fit but it is an extra dependancy as it requires node.js. Maybe Erica could do that instead. At this stage these are pretty minor issues that will be easy to sort out later. Also the less-to-CSS could be done at release time instead of run-time, so only the people who hack on Futon will have to install node. That would be fine with me, of course. Cheers, Dirkjan
Re: [ANN] Dave Cottlehuber joins the PMC
On Tue, Oct 30, 2012 at 11:55 PM, Noah Slater nsla...@apache.org wrote: Everybody, please join me in congratulating Dave! Yay, Dave! Well-deserved. Cheers, Dirkjan
Re: Packagers, Maintainers 1.3.0 release
On Wed, Nov 28, 2012 at 4:23 PM, Dave Cottlehuber d...@jsonified.com wrote: - are you happy to be added to the wiki as a maintainer? Yes, for Gentoo. - alternatively, a link to bugtracker (or where we can identify the maintainer) would be fine - is the link below correct for your platform? http://packages.gentoo.org/package/dev-db/couchdb Yes. I haven't tested with 1.3 yet -- I generally do so when there's a tarball. It would be really nice if some effort was spent on making it easier to use system versions of dependencies, but I believe that is targeted for the near future? /packagers-hat Cheers, Dirkjan
Re: Packagers, Maintainers 1.3.0 release
On Sun, Dec 2, 2012 at 9:51 PM, Noah Slater nsla...@apache.org wrote: Can you clarify? COUCHDB-1458. Then, similar things for yajl, and preferably also for the Erlang dependencies (ejson, mochiweb, ibrowse), making sure that there are upstream versions that work with CouchDB. But AIUI this is part of Benoit's build system overhaul plan for 1.4. Cheers, Dirkjan
Re: [VOTE] Apache CouchDB maintenance releases, first round for 1.0.4, 1.1.2, 1.2.1
On Sat, Dec 29, 2012 at 9:12 PM, Dave Cottlehuber d...@apache.org wrote:
We would like to call a vote for Apache CouchDB, 1.0.4, 1.1.2, and 1.2.1,
first round, maintenance releases, to start your New Year with a bang.
Gentoo Linux, R15B, SpiderMonkey 1.8.5;
1.2.1: make check passes, browser test suite fails spectacularly with
Firefox 19.0a2.
All the first tests work, then it gets to cookie_auth:
Assertion failed: CouchDB.session().userCtx.name == 'Jason Davies'
Assertion failed: CouchDB.session().userCtx.name == 'Jason Davies'
Exception raised: {error:forbidden,reason:You may only update
your own user document.}
After that, everything fails:
Exception raised: {error:unauthorized,reason:You are not a
server admin.}
This is while running in Admin Party mode.
Cheers,
Dirkjan
Re: [VOTE] Apache CouchDB maintenance releases, first round for 1.0.4, 1.1.2, 1.2.1
On Sun, Dec 30, 2012 at 1:13 PM, Jan Lehnardt j...@apache.org wrote: tl;dr: reload the page and run the test suite again. You might have to restart CouchDB as well. Tried all of that a few times, same result. Feel free to ignore my browser-based test results. :) Cheers, Dirkjan
Re: Nested views: iterative map reduce implementation
On Tue, Jan 22, 2013 at 4:18 PM, nicholas a. evans n...@ekenosen.net wrote: I've started hacking on an implementation of iterative map reduce that I'm calling nested views. It's not nearly finished, but well overdue for feedback from people who know what they're doing with CouchDB and Erlang. :) This sounds awesome! I think this same feature was previously called chained map/reduce (or views) around these parts. Cheers, Dirkjan
Re: Branch to switch from SpiderMonkey to Node.js
On Fri, Jan 25, 2013 at 12:06 PM, Jason Smith j...@apache.org wrote: This is an experiment just to see how things feel. I want to see how it feels to stop saying CouchDB requires libjs185/xulrunner/spidermonkey/whatever and start saying CouchDB requires Node.js. What do we need Node.js for, over just v8? Cheers, Dirkjan
Re: [VOTE] Import Fauxton
On Thu, Feb 7, 2013 at 12:44 PM, Simon Metson si...@cloudant.com wrote: Hi, It's a complete rewrite using Backbone and Bootstrap. Attached are a few screen grabs, it should be easy to set up on your own CouchDB instance - you can grab the code as now from https://github.com/cloudant-labs/couchdb/tree/fauxton/src/fauxton You forgot the attachments, I guess? :) Cheers, Dirkjan
Re: replication on touchdb and authentication
On Thu, Feb 14, 2013 at 4:34 AM, Jason Smith j...@apache.org wrote: Jens would it help if Persona were an official feature of CouchDB? Persona is awesome, great to see it applied to this. Cheers, Dirkjan
Re: [DISCUSS] Goals for 2013
(warning, grumpy rant forthcoming...) On Wed, Mar 6, 2013 at 7:14 PM, Noah Slater nsla...@apache.org wrote: Thoughts? It seems to me that a lot of this hinges on releases. Releases generate publicity and therefore developer interest, thus developer engagement. Releases make sure that work developers do gets into user's hands soon. CouchDB, and I am sorry to have been banging this drum for a few years now, is the worst open source project at doing releases I know. Here's a quote from this list, from February 13: I plan to cut a release candidate from the 1.3.x branch this weekend. And another, from Nov 13: when we set out to ship 1.3.0, we thought the cors and docs branches were just around the corner. That was a couple of weeks ago. We are just starting with this, but the whole idea of time-based releases is that we do not wait for feature branches to be ready. I’d like to propose that we ignore everything we’ve said before and do the following: - ship 1.3.0 as reflected in the 1.3.x branch now. Here's another, from October 23: It's been a while since we released and I want to change this now. I propose making a 1.3.x branch from today's master (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there. Another, from June 16: 1. We'd like to proposed formal time-based releases Et cetera. As an example, the EventSource bits, which are actually something which would be very useful for us at work, were committed to the tree on May 16. They are yet to be released. I feel a bit hypocritical for saying all this, since I don't contribute much to core CouchDB (although I did do a bunch of the doc conversion, try to be helpful around the edges and maintain couchdb-python). The reason for this is mostly that I thoroughly dislike Erlang as a language, and have no intention of learning it just to help out with CouchDB. I did some Futon work back in the day, but had lots of trouble getting it committed since no one's really owned Futon for a while (and right now, it looks like other people have that bit covered, though they're using a modern but also quite complex development stack that will make it unlikely for a lowly back-end web developer dude like me to be able to contribute much). So, IMNSH and annoyingly harsh O, stop talking so much about how to energize the project, and Just. Ship. It. Every month, preferably. Fix the test suite and whatever else makes it so damn hard to release. Insert story here about that dude who realized people were trying to fix the wrong problem [1]. End of rant, cheers, Dirkjan [1] http://www.azarask.in/blog/post/the-wrong-problem/
Re: [ANNOUNCE] Alexander Shorin elected as CouchDB committer
On Tue, Mar 19, 2013 at 5:52 PM, Noah Slater nsla...@apache.org wrote: Please join me in extending a warm welcome to Alexander! Cool, congrats Alexander! Cheers, Dirkjan
Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
On Sat, Mar 30, 2013 at 8:29 PM, Jan Lehnardt j...@apache.org 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 perception (as someone who doesn't really need clustering), it seems that different would be more complicated here in most cases, so I'm a little bit ambivalent about BigCouch merging into CouchDB (although obviously there could be lots of great stuff too, I don't really know!). Also, +1 on Jan's point re minimizing the amount and size of flag days (i.e. big 2.0.0 release). Cheers, Dirkjan
Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
On Sun, Mar 31, 2013 at 9:42 PM, Jan Lehnardt j...@apache.org 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-1765 filled out for discussion details. Thanks, that looks very useful (and takes away pretty much all of my qualms). Will _purge be going away entirely? Cheers, Dirkjan
Re: Roadmap process and merge procedure
On Wed, Apr 17, 2013 at 3:45 PM, Noah Slater nsla...@apache.org 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, so that we can move forward as we originally planned to, with features only landing on a release branch with tests, docs, etc. Sorry, this might just be me, but why would you want to branch for 1.4.x now instead of, like, 2 (or 4) weeks before the intended release date? Cheers, Dirkjan
Re: Roadmap process and merge procedure
On Wed, Apr 17, 2013 at 4:02 PM, Noah Slater nsla...@apache.org 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 every time. Cheers, Dirkjan
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Tue, May 7, 2013 at 9:23 PM, Robert Newson rnew...@apache.org 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 what the minimum time that community members feel they can respond. I don't mean this as horribly as it will sound, but, to a degree, if someone can't take the time, in 3 days, to reply with '-1' to a thread, perhaps that's a problem too? The whole point of lazy consensus is to move forward quickly. We don't always need to wait for a large number of +1's to get work done. Finally, I'll agree that lazy consensus can be used inappropriately, I just don't think I agree that it's happened yet. +1 to all of that. Cheers, Dirkjan
Re: wiki choice: moinmoin vs confluence
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 new Sphinx-based docs? I think they're a huge improvement over both the wiki and the book drafts. Personally, I think it would make a lot of sense to invest more time in those, rather than moving wiki content around. We could port wiki content that's missing from the docs to reST so it gets included in every CouchDB release (where it's easily accessible through Futon). I think the biggest problem with the wiki is that wikis require a lot of what I tend to think of as gardening to make them easy to navigate. I don't think MoinMoin is the larger problem here (though I tend to agree that it's pretty unattractive). If we want to go one step further with reST, it would even be possible to have similar handling for the blog. I use Pelican for my personal blog and it uses reST as well. We could have a directory blog in the tree somewhere where people can collaborate on blog entries which subsequently get published to the interwebz. Cheers, Dirkjan
Re: 0.9.0 Delay or Release?
On Mon, Feb 9, 2009 at 16:15, Paul Davis paul.joseph.da...@gmail.com wrote: Or at least make a 0.10 release that's a quick follow up. I'd rather have a few versions closer together than too few versions too far apart. I'd like that, too. I'm on trunk now, because it has a bunch of good stuff that's not in 0.8.1, but it would be nicer if there was a release I could refer people to. Cheers, Dirkjan
Re: Ideas for Changes to the Test Suite
On 13/02/2009 19:52, Chris Anderson wrote: I know for sure that in-browser tests are a big part of what brought me to CouchDB. They tell the story of a web-native database in a way that nothing else can really touch. They also make it *incredibly easy* for newcomers to contribute. They also make it incredibly easy for newcomers to get confused, due to the involvement of the browser. That is, I ran the tests using Firefox 3.1b2, and they crapped all over themselves. Of course I thought I hadn't installed Couch just right; but it was the browser's fault in this case. I agree that the in-browser test suite is incredibly snazzy, but I definitely feel for Paul's argument about more basic testing, too. Cheers, Dirkjan
Failing tests
Hello there,
(Paul Davis mentioned that I should ping the list on this)
I just upgraded to a new nightly build (r755866), but some of the
tests fail. Paul tells me that the problems with stats are known, but
the both of us also see problems with rev_stemming. This is the error
message I get:
# Assertion failed: db.open(bar, {revs:
true})._revisions.ids.length == newLimit
Just to let you know. My upgrade seems to have made Couch much faster,
so thanks for all the hard work!! Looking forward to the actual 0.9
release.
Cheers,
Dirkjan
Re: JavaScript 1.8 Features in SpiderMonkey (Please?)
On 23/03/2009 19:34, Paul Davis wrote: I don't think it'd be a good idea to require until it hits general consumption (as in, shows up in package managers). Their build procedure is at best, 'interesting'. Also, there's nothing to keep you from linking couchjs against a newer version of the library. I haven't groked all of the API breakage but there was a report on the list awhile back that seemed to indicate that it only involved a minor patch. Can you specify what's bad about their build procedure? I seem to recall that a lot of work on that was done in the past few months, and if not, I think I know who's in charge of it, so I could ask them about it. Cheers, Dirkjan
Re: unicode output representation
On Tue, Apr 14, 2009 at 00:39, Chris Anderson jch...@apache.org wrote: Any thoughts on how best to do this? Should utf8 be the default, or \u? Since RFC 4627 says JSON SHALL be encoded in Unicode, and the default as specified in the RFC is UTF-8, I think utf8 as the default is better option here. Maybe it could be switchable based on Accept: application/json;charset=ascii in the request. Cheers, Dirkjan
Re: Wiki instruction about Gentoo install needs update
On Tue, Apr 28, 2009 at 13:05, Vicente Jiménez goo...@gmail.com wrote: But the wiki page http://wiki.apache.org/couchdb/Installing_on_Gentoo is not updated. Now the ebuilds for version 0.8.1 and 0.9 are officials so the installation is easy now. I've drastically simplified the page. I hope to push the devs to make it stable in a week or so, so we can eliminate one more step. (You could just have changed it yourself, by registering on the wiki and editing the page.) Cheers, Dirkjan
Re: patches that need reviewing
On Sun, Jun 21, 2009 at 23:53, Damien Katzdam...@apache.org wrote: I haven't been keeping very good track lately of patches. Sorry if you have a patch we haven't reviewed yet. If their are any patches waiting review, respond here and I'll try to get to it soon or reassign to someone else to review. I'd like my patch on COUCHDB-301 to be reviewed. It's a simple addition to Futon that I think is valuable, even if some consider it not generic enough. Personally, I think the balance of usefulness/simplicity in both use and implementation is high enough that it would be a good addition. Cheers, Dirkjan
Re: RIP Temp Views?
On Wed, Jul 15, 2009 at 17:57, Jan Lehnardtj...@apache.org wrote: If you like temp views, I'd like to take your concerns into consideration. I like testing out views from Futon, but it seems you're going to keep that anyway. I wonder if keeping a somewhat-compatible copy of the Couch API in JS isn't expensive in terms of developer time, but otherwise the proposal (from skimming) sounds good to me. Cheers, Dirkjan
Time to move bugspam to a separate list?
Now that volume for both conversation and usage of the bugtracker has increased, might this be a good time to move all JIRA mail to a different list? I like to track high-level discussions, but most of the bugs aren't that interesting to me. It'd be nice to bring volume down a little. Of course I could filter them out client-side, but I thought I'd float this here first. Cheers, Dirkjan
Re: POST with _id
On Mon, Aug 3, 2009 at 20:27, Jan Lehnardtj...@apache.org wrote: I remember stumbling over this at least twice in the (distant) past. I prefer the forced PUT, but then I'm also the one to argue intuitive APIs. Considering no downsides (usually Damien adds or leaves out features for a reason), I don't see anything wrong with Brian's proposal. I also agree with Brian's proposal. I think per the spec the server can still use a resource component the client proposed in a POST, it's just not obliged to do so. Cheers, Dirkjan
Re: What's your Erlang VM version?
On Thu, Aug 6, 2009 at 09:56, Brian Candlerb.cand...@pobox.com wrote: My other boxes run Jaunty which has 12b5, so I wouldn't actually object if that were made the minimum. My (stable) Gentoo boxen also have 12b5. Cheers, Dirkjan
Re: Uneasiness with use of github for experimentation
On Fri, Aug 7, 2009 at 08:53, Noah Slaternsla...@apache.org wrote: Do any of the other committers have Bugzilla experience? Is it that bad? Not a committer, but I think recent versions of Bugzilla (e.g. the 3.2 or 3.4 range) are substantially improved from the old 2.18/2.20 crap everyone is used to hating on. I usually prefer Trac myself, because it gets you bug tracker, wiki and repo tracking in one relatively neat little package, but that may not be useful at the ASF, where all of these services are provided for separately. (Admittedly, the Trac UI has gone a little stale, but I still find it alright. Haven't used Redmine or Lighthouse or whatever much, though.) Cheers, Dirkjan
Re: Uneasiness with use of github for experimentation
On Fri, Aug 7, 2009 at 13:51, Robert Dionnedio...@dionne-associates.com wrote: Trac rocks. I introduced it some time ago on a contract with a small group of scientists working collaboratively. Being able to set up and track milestones, doc meetings with a WIKI, integration with SVN (perhaps it supports Git now?), it's a sweet tool. I hear Trac's Git support isn't that good, but its Mercurial support is awesome. :) (We're kind of off-topic at this point, though, so we should probably stop discussing Trac here.) Cheers, Dirkjan
Re: Apache sub-projects
On Sun, Aug 16, 2009 at 18:21, Jan Lehnardtj...@apache.org wrote: In a project as big as PHP, this makes sense and was needed badly. CouchDB is not that big yet. I'd say let's figure out how to incorporate sub projects into our subversion tree (e.g. couchdb/trunk is couchdb-trunk, where do sub projects go? couchdb/projects/...?) and how to make releases (separate or bundled with CouchDB, Futon e.g. could be bundled and couchdb-lucene a separate package) and worry about splitting out independent sub projects when when the need arises. As someone who is involved in a lot of repository migrations (to DVCS), please don't do any weird layouts. If you're going to do trunk/tags/branches, put every project on the same level and t/b/t in each of them. For source code, facilitating your way out of a specific system is a good idea. Futon: - The developers are currently the CouchDB committers and we got contributions small and big from users through patches. - A future Futon-only developer doesn't necessarily have to know any Erlang and I'd trust her to not touch that part of the code until everybody feeling comfortable with this. (Besides, Erlang is so simple on the couch_http_*-end that small fixes in the HTTP API could be done without much hassle). And we're using SVN, if any unwanted changes, accidental or deliberate are introduced, we'll revert them. - Futon always has to be current with CouchDB, even through trunk-only development phases. Splitting this out to a separate schedule doesn't make much sense to me. - Working on Futon is a great way for new developers to get into CouchDB via simpler, more familiar means (web development). Having Futon as a somewhat separate project sounds interesting. I've been porting another site to CouchDB over the past week, and I've been having some ideas (but putting up a CouchDB snapshot has prevented me from hacking on it so far -- making that easier would be interesting...). A major detriment to my last Futon patch was also the fact that it sat untouched in JIRA for months, which wasn't very motivating. (It eventually got applied, but without mentioning so on the bug, so I didn't even know about that... Kind of a pity, that.) Relatedly, I wonder if couchdb-python would also be a good fit for being a subproject. Note that both Futon and couchdb-python have suffered a bit in the past from the fact that the primary author has had little time to deal with patches, bugs, etc. That happens to everyone, but it would be nice if we could prevent the projects from stalling as much as possible. Cheers, Dirkjan
Re: Ready for 0.10 Release?
On Tue, Aug 18, 2009 at 01:34, Jan Lehnardtj...@apache.org wrote: I'd like the history patch to be simmering in the 0.10.x branch. I'm working on another patch to provide view options in Futon. Would it be possible to include that for 0.10 as well? Also, I wonder if my HATEOAS patches ever went anywhere (I put them in the tracker, don't remember where right now). Basically, it would be nice if it was possible to find all the special URLs from the root without having to know any beforehand. Cheers, Dirkjan
Re: contrib files, svn layout
On 23/08/2009 19:08, Jan Lehnardt wrote: Locally, I've put them under `svnroot/couchdb/contrib/scripts` but I can see an argument for not putting them into the source tree. Maybe `svnroot/contrib/trunk` is a better place (starting a new layout where projects next to CouchDB live in parallel directories in SVN. I think putting this kind of thing in the repository is a good thing, but I don't really see the value of a root/contrib/trunk kind of thing. Since these scripts are intended for use by CouchDB developers and people interested in hacking on CouchDB, why make it harder on them by having to check out a separate working dir? I don't think putting them in couchdb/contrib(/scripts?) comes with some cost that justifies that. Cheers, Dirkjan
Re: 0.10.1
On Wed, Nov 4, 2009 at 17:31, Jan Lehnardt j...@apache.org wrote: we've seen a bunch of fixes in the 0.10.x branch that warrant a 0.10.1 release. I think now is a good time to cut it. Sounds great to me. Is there a changelog somewhere noting the fixes so far? Cheers, Dirkjan
Re: Increasing Spidermonkey version
On Thu, Nov 19, 2009 at 13:47, Paul Davis paul.joseph.da...@gmail.com wrote: I think this is the bug we want: https://bugzilla.mozilla.org/show_bug.cgi?id=479473 which was last updated in May. Most people are already on 1.8.1 libraries because packagers appear to have started pulling it from projects like XUL runner instead of building in isolation. I'm CC'ed on that one as well, but I think the consensus in #jsapi was that they would release something called 1.8.0. The topic of releases of SpiderMonkey is apparently not very popular with some of the crowd there, though. Cheers, Dirkjan
Improving pagination for views
This weekend I tried to implement pagination for one of the modules of a Couch-based site I maintain. Here's a rambling account of things that I don't like and ideas about how maybe it could be improved. In short: it kind of sucks. I usually prefer to get a list of pages so people can jump around a little bit more, and because it provides feedback about the size of an item list (I was working with a photo gallery in this case). On MySQL-based databases, I'd usually issue a single count query, which could be quite fast, to count the matching items, then divide that by page size, use the standard LIMIT/OFFSET approach to pagination. On Couch, as far as I can see, pre-issuing a count query means actually retrieving all the row data, which doesn't seem to scale nicely. Apparently, the alternative solution is to page sequentially, meaning I retrieve one extra document and pass its document id so that I can start the next page from there. That gets me a single next page link (works okayish so far). Then, if I also want to provide a previous page link, I'd have to either pass current startkey to the next page (ugly URLs, more state than I'd like; also, switching on existence of parameter instead of just parameter value + default value to check for the first page), or retrieve twice the page size + 1. Conclusion: I'd like to be able to specify to a view, take a little bit more time but give me some more metadata to work with. Currently I get total rows for the view and offset from the first index to the current startkey. In the CouchDB book's pagination story, that means the offset changes on every page, and using limit means I can't really use rows.length to calculate the offset of the end of this result set. It would be swell if I could just get the index offset for the startkey and the endkey, ignoring skip/limit and whatever else. Since it seems retrieval of those index offsets would not be too expensive (Jan say O(large m + n)), it seems like a nice idea to provide e.g. a meta=true option on views that will do the extra work to retrieve those indexes for me and make pagination a whole lot easier. Sorry for the rambling, I don't think I can express it any clearer (I tried really hard in IRC, and it still took a few hours to get some people to understand all this). Does this sound at all sensible? Cheers, Dirkjan
Re: [VOTE] Apache CouchDB 0.10.1 release
On Wed, Nov 25, 2009 at 02:19, Noah Slater nsla...@tumbolia.org wrote:
I would like call a vote for the Apache CouchDB 0.10.1 release.
On Gentoo x86, SpiderMonkey 1.7, Erlang 13B2, I get one failure in the
Futon test suite:
erlang_views fails with Exception: {}
All other tests pass.
Cheers,
Dirkjan
Re: [VOTE] Apache CouchDB 0.10.1 release
On Wed, Nov 25, 2009 at 14:44, Jan Lehnardt j...@apache.org wrote: Do you happen to test this over a remote connection or locally? Over ssh -L 5984:localhost:5984. Cheers, Dirkjan
Re: Updating the CouchDB roadmap
On Fri, Dec 4, 2009 at 18:32, Noah Slater nsla...@tumbolia.org wrote: Hey, does anyone want to start the discussion off? Question from one of those trailing around on actual releases, that may help getting started: what big-ticket features are in trunk, but not 0.10.1? Cheers, Dirkjan
Re: Updating the CouchDB roadmap
It seems weird that none of the core developers have bothered to write up some of their ideas here, for ten days running now. I understand you're all busy with Relaxed, but it doesn't have to take so long, does it? IMO it would be nice to have some kind of idea of where CouchDB is going and/or what will be in the next release. Cheers, Dirkjan
Re: authentication cleanup
On Fri, Dec 25, 2009 at 00:58, Chris Anderson jch...@apache.org wrote: So I think I'm gonna switch to docids like user:jch...@apache.org and user:Monty4eva. If this is a stupid idea please convince me not to do it. Making the user IDs the document IDs seems to make sense, but I'm not sure what the user: prefix (which seems a little ugly) buys you. Are there documents in the users database that are not users? Cheers, Dirkjan
Re: authentication cleanup
On Fri, Dec 25, 2009 at 16:40, Chris Anderson jch...@apache.org wrote: Not yet, but who knows what the next hundred years will bring. :) YAGNI. ;) Christmas cheers, Dirkjan
Re: CouchDB speakers
On Wed, Dec 30, 2009 at 18:25, Chris Anderson jch...@apache.org wrote: If you are looking for someone to talk at a conference, or if you see conferences that could use speakers, these lists are a great place to connect people. So if you'd like to talk, or looking for speakers, reply to this thread and let's see what comes together. I'd be happy to talk about Couch in the Netherlands. Cheers, Dirkjan
Re: Nightly and binary builds
On Wed, Jan 20, 2010 at 22:20, Ben Schwarz ben.schw...@gmail.com wrote: As a follower of the macruby project, I've found that I log more bugs because I'm able to install a nightly of macruby without much of an investment to keep up with the details of LLVM and its other dependencies. http://macruby.icoretech.org/ Are you aware of http://build.couchdb.org/? Cheers, Dirkjan
Re: better wiki
On Sat, Jan 23, 2010 at 09:29, Brian Candler b.cand...@pobox.com wrote: But in any case the Apache wiki server is dog slow and often gives 500 errors, so for that reason alone I give a +1 to moving to anything else. Concur on slowness and (intermittent) 500 errors. One thing that I think baffles people is that pages show up as ImmutablePage for everyone who isn't logged in. I've heard there's some TextCha setup that you can use to verify editors, so you can make non-logged-in people be able to edit pages. Maybe that would lower the barrier in the meantime? Cheers, Dirkjan
Re: Updating the CouchDB roadmap
On Fri, Dec 18, 2009 at 20:30, Damien Katz dam...@apache.org wrote: I think we should set a hard date of Feb 1. for feature freeze, 0.11.0 is the last new feature release. Did this ever turn into some kind of consensus, or is there no idea yet about a 0.11 release time frame? Cheers, Dirkjan
Re: couch_config_writer.erl: meaning of single backslash in regular expression
On Fri, Apr 8, 2011 at 13:16, Andrey Somov trophyb...@googlemail.com wrote:
{ok, Pattern} = re:compile([^(, Key, \\s*=)|\\[[a-zA-Z0-9\_-]*\\]]),
What does the single backslash mean (\_)? When I remove it the tests still
succeed. (to be precise they fail in the same way as with the single
backslash)
I'm guessing it's supposed to be an escape character, but I don't know
of any regex dialect where the underscore is meaningful inside a
character range.
Cheers,
Dirkjan
Re: 1.1.0
On Wed, Apr 27, 2011 at 11:53, Robert Newson robert.new...@gmail.com wrote: Damien and Chris say the 1141 behavior is intentional. I'd like to open that up for discussion. While it may have been intended, it was obviously unknown to Paul and Jan, and, I'd wager, every single user of CouchDB and every author of every client library too. My view is that the default should be that delete deletes. If there is still a case to preserve other metadata (a 'deleted_at' or 'deleted_by' field, say), an extra flag would allow that case ?preserve_body=true, or something. I thought the same thing. Perhaps the delete can only preserve fields prefixed with '_' or even '_delete', but I think the current behavior is very surprising to users, and thus somewhat harmful. It would be nice if someone could write a script or view or something that helps find instances of this. Cheers, Dirkjan
Re: Welcome Randall Leeds and Robert Dionne as new Committers
On Fri, May 6, 2011 at 09:56, Jan Lehnardt j...@apache.org wrote: Both have been long time contributors and are valuable members of the community and development team. Here's to Randall and Robert and many more contributions! Great stuff, congratulations both! Cheers, Dirkjan
Helping out with releases
Hi there, Since I note that the release process for 1.1 seems to have been stalled again, I wonder if there was stuff I could do. I'd be happy to join the RM team to help Apache CouchDB provide more timely releases so that companies like mine can benefit sooner from the latest fruits of the committers. Please let me know how I would go about learning all the stuff I need to know (and hopefully at some point keys to the required infra). Cheers, Dirkjan
Re: Helping out with releases
On Sun, May 15, 2011 at 18:34, Paul J. Davis paul.joseph.da...@gmail.com wrote: 1.0.3 is on my list for today Any progress? Thanks, Dirkjan
Re: [VOTE] Apache CouchDB 1.1.0 release
On Tue, May 17, 2011 at 16:17, Robert Newson rnew...@apache.org wrote:
We are voting on the following release artifacts:
http://people.apache.org/~rnewson/dist/1.1.0/
I tested it on amd64 Gentoo Linux. etap tests passed, browser tests
mostly passed. I got these failures, but I'm running this on a recent
Firefox 5.0 alpha:
oauth
Exception raised: {error:db_not_found,reason:could not open
http://localhost:15984/test_suite_db_a/}
replication
Exception raised: {error:db_not_found,reason:could not open
http://localhost:15984/test_suite_db_b/}
replicator_db
Exception raised: {}
security_validation
Exception raised: {error:db_not_found,reason:could not open
http://localhost:15984/test_suite_db_b/}
The failures in oauth, replication and security_validation are the
same as in 1.0.2 in this setup. The replicator_db obviously didn't
exist in 1.0.2, so not sure about that.
Cheers,
Dirkjan
Re: replication document timestamps as rfc3339 timestamps
On Fri, May 20, 2011 at 10:41, Filipe David Manana fdman...@apache.org wrote: Yesterday, via the IRC channel, Max Odgen suggested using RFC3339 [1] compliant timestamps in replication documents. Currently they are Unix timestamps (number of seconds since January 1st 1970). I like the idea, I find it much more human readable (it's text based). Any objection about doing this change before 1.1.0 is released? [1] http://tools.ietf.org/html/rfc3339 Sounds good, supposing it won't delay 1.1.0 too much. Cheers, Dirkjan
Re: [VOTE] Apache CouchDB 1.1.0 release, round 3.
On Tue, May 31, 2011 at 15:23, Dave Cottlehuber d...@muse.net.nz wrote: What Jan said! This release has been a real saga and you are awesome!! +1. (I've tried the release and make check passes for me. I don't think any of the browsers I run are supported for the Futon tests, so I'm skipping those -- but most look good, anyway.) Cheesr, Dirkjan
Re: Archiving old releases
On Mon, Jun 6, 2011 at 16:44, Robert Newson rnew...@apache.org wrote: For my part, I'd like Downloads to hold just 1.1.0 and 1.0.2 and archive everything else. Sounds just right to me. Cheers, Dirkjan
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
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 becomes, How many people contributed to the wiki that couldn't manage to fill out a JIRA issue? Wouldn't or couldn't? Cheers, Dirkjan
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Tue, Jun 14, 2011 at 19:13, Noah Slater nsla...@apache.org wrote: +0 docbook +1 REST Seriously, let's not fall into this trap. And let us not be seduced by so called plain text formats. We made this mistake on the book and I'm in no rush to repeat it. Sorry to contribute to the bikeshed, but I'm just going to get this off my chest. From your email, this seems like a false generalization, at least, going from AsciiDoc to all plain text formats. I don't know if you've used reStructuredText, but it's seriously flexible and comes with good (easily customizable) latex and html conversion out of the box. I understand DocBook is awesome for print things, but experience has also shown that DocBook has a significantly higher barrier to entry. Going from a wiki to DocBook is like moving to the entire other end of the scale (okay, going with latex would be worse). You had a bad experience with AsciiDoc, but Sphinx is just awesome. Cheers, Dirkjan
Re: SpiderMonkey Version Support
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. Since 1.2 isn't more than a reference to trunk, there's not much (IMO) keeping us from dropping our support for everything pre-1.8.5 (except being nice to users I guess). Doesn't that depend on when 1.2 comes out? 1.8.5 is not that old. Cheers, Dirkjan
Re: SpiderMonkey Version Support
On Wed, Jun 29, 2011 at 18:46, Jan Lehnardt j...@apache.org wrote: Except if people have trouble installing / upgrading CouchDB, it leaves a bad taste. I'd rather not put users between a rock (1.7-based SpiderMonkey version) and a hard place (CouchDB only supporting 1.8.5 and up) Right. Also, if 1.2 takes a long time in coming (like some of the previous releases), it would be nice if we'd get to use the state of the art in JS sooner. Cheers, Dirkjan
Re: Improving password hashing.
On Wed, Jul 6, 2011 at 14:43, Robert Newson rnew...@apache.org wrote: Some time ago I wrote some code to implement the PBKDF2 protocol. This is a cryptographically sound means of deriving a key from a password. Why is this better than stuff like bcrypt or scrypt? The page for the latter, at least, states that it is designed to be far more secure against hardware brute-force attacks than alternative functions such as PBKDF2. Cheers, Dirkjan
Re: community of CouchDB developers in the Netherlands
On Wed, Sep 14, 2011 at 18:54, Andrey Somov trophyb...@googlemail.com wrote: I would be happy to join a meetup of CouchDB developers. Googling did not help to find either CouchDB or Erlang community here in the Netherlands. Can someone help me ? Is there one ? There are a few Dutchies involved with CouchDB, but I don't think there's been much actual contribution in terms of Erlang code. AFAIK, most of us just use CouchDB in one way or another (or help out around the edges; couchdb-python, paisley, Futon). Cheers, Dirkjan
Re: community of CouchDB developers in the Netherlands
On Wed, Sep 14, 2011 at 19:26, Andrey Somov trophyb...@googlemail.com wrote: Do you have plans to attend any local conference in the nearest future ? (by the way I live in Den Haag) That wouldn't be much use for this, because I'm not conversant in Erlang at all. :) Cheers, Dirkjan
