[jira] Updated: (COUCHDB-457) Database crash with possibly non-UTF-8 document content
[ https://issues.apache.org/jira/browse/COUCHDB-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James William Dumay updated COUCHDB-457: Attachment: watercooler.couch > Database crash with possibly non-UTF-8 document content > --- > > Key: COUCHDB-457 > URL: https://issues.apache.org/jira/browse/COUCHDB-457 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.9.1 >Reporter: James William Dumay > Attachments: watercooler.couch > > > See the document with the id "http://www.stephenfry.com/blog/?feed=rss2"; in > the attached db. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Uneasiness with use of github for experimentation
On Fri, Aug 7, 2009 at 2:53 AM, Noah Slater wrote: > On Fri, Aug 07, 2009 at 02:46:06AM -0400, Paul Davis wrote: >> While we're at it lets use versioned tarballs and FTP instead of SVN. > > I'm not sure what you mean. Heh. > I mean, worse to worser is worst of all. > Do any of the other committers have Bugzilla experience? Is it that bad? > > Thanks, > > -- > Noah Slater, http://tumbolia.org/nslater >
[jira] Created: (COUCHDB-457) Database crash with possibly non-UTF-8 document content
Database crash with possibly non-UTF-8 document content --- Key: COUCHDB-457 URL: https://issues.apache.org/jira/browse/COUCHDB-457 Project: CouchDB Issue Type: Bug Affects Versions: 0.9.1 Reporter: James William Dumay See the document with the id "http://www.stephenfry.com/blog/?feed=rss2"; in the attached db. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Uneasiness with use of github for experimentation
On Fri, Aug 07, 2009 at 02:46:06AM -0400, Paul Davis wrote: > While we're at it lets use versioned tarballs and FTP instead of SVN. I'm not sure what you mean. Heh. Do any of the other committers have Bugzilla experience? Is it that bad? Thanks, -- Noah Slater, http://tumbolia.org/nslater
Re: Uneasiness with use of github for experimentation
> [snip a bazillion unnecessarily quoted lines] I wouldn't want to lose providence given the current topic of discussion. > We could always switch to bugzilla? Right. While we're at it lets use versioned tarballs and FTP instead of SVN. HTH, Paul Davis
Re: Uneasiness with use of github for experimentation
On Fri, Aug 07, 2009 at 02:23:43AM -0400, Paul Davis wrote: > A few shapeless and incomplete thoughts leap to mind: [snip a bazillion unnecessarily quoted lines] > Don't get me started on JIRA. We could always switch to bugzilla? JIRA is a big honking pile of crap. Best, -- Noah Slater, http://tumbolia.org/nslater
Re: Uneasiness with use of github for experimentation
A few shapeless and incomplete thoughts leap to mind: > > As previously mentioned, the JIRA does have an checkbox to indicate that a > contribution is intended as a contribution. That is intended as a > reinforcement (or an explicit refutation) of the implied license for things > posted on the mailing lists or in Bugzilla (which lacks the checkbox). The > implied license for contributions comes from item 5 in the ASL. > > > 5. Submission of Contributions. Unless You explicitly state otherwise, > any Contribution intentionally submitted for inclusion in the Work > by You to the Licensor shall be under the terms and conditions of > this License, without any additional terms or conditions. > Notwithstanding the above, nothing herein shall supersede or modify > the terms of any separate license agreement you may have executed > with Licensor regarding such Contributions. > As I read this, anyone that submits a patch to me on github has granted ASF license to that contribution unless they specifically state that their contribution was not intended for inclusion. Its still my ass on the line as a committer if I put something in SVN that violates this agreement. The radio button on JIRA is not an absolute requirement for inclusion. > In the case of a substantial contribution on the mailing list or bug > tracker, the PMC may think it is warranted to have a signed CLA on file > before incorporating the code. That is a judgement call left up to the PMC, > but as with anything can be overriden by the board. > > The mailing lists are archived, the bug trackers are logged and archived. > If there is ever a challenge the ASF should be able to trace any piece of > code back to a particular email or bug tracker or SVN user who represented > that the code was their original creation which they intended and had the > right to license under the ASL. > > The ASF license allows forking and commercialized or internal variants. > Unlike the GPL, however it does not require that forkers donate their code > back to the ASF. I'm fully within my legal limits to create "Curt's > Relaxing Database" from the Apache CouchDB code and make it available under > the ASL or under a more restrictive license as long as I comply with the ASF > terms on the code that I incorporated from the ASF. If I set up CRDb as > independent project under a different license and I accepted contributions > from others, I may not have the rights to relicense their contributions back > the the ASF if I ever decided to merge CRDb. Also, those contributions > would not be documented in the ASF infrastructure as would contributions > that had gone into CouchDB. Because of that, any convergence would need to > go through the Incubator to make sure that every contribution is documented. > > While not intentional doing collaborative development outside of the ASF > infrastructure has a lot of similarities to an intentional forking. For a > small window of time, a developer is offering a code base under the ASL may > be incorporating contributions from others where the ASL has no record of > either the transaction or the possible separate license agreement that was > executed between the forker and the contributor. > > > > The second issue is open, collaborative development: > > From http://www.apache.org/foundation/how-it-works.html#what > >> The Apache Software Foundation (ASF) is a 501(c)3 non-profit organization >> incorporated in the United States of America and was formed primarily to: >> >> • provide a foundation for open, collaborative software development >> projects by supplying hardware, communication, and business infrastructure >> ... >> >> We endeavour to conduct as much discussion in public as possible. This >> encourages openness, provides a public record, and stimulates the broader >> community. >> >> > > Using github is definitely more open than doing a whole lot of work off on > your private machine or code repository and then contributing a big pile of > work that the rest of the community now has to accept as a done deal. > However, I requires that I notice that your message about your work on > Github, that that I actively follow it independent of tracking the existing > development that is being done in the Apache SVN. If experimental > development is done under > http://svn.apache.org/repos/asf/couchdb/sandbox/whatever, then anyone who is > interested enough to subscribe to comm...@couchdb.apache.org will also see > the commits that occur on sandbox/whatever. > > I could see work on authentication and authorization warranting a branch in > the sandbox, maybe more than one if there are multiple competing ideas. > > The threshold to granting access rights could be a lot lower in the sandbox. > Obviously, my Erlang and CouchDB foo isn't sufficient to even think about > touching the trunk, but I might have an idea that would benefit from being > fleshed out in the sandbox. Current com
[jira] Updated: (COUCHDB-377) allow native view servers
[
https://issues.apache.org/jira/browse/COUCHDB-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hammond updated COUCHDB-377:
-
Attachment: native_view_js_tests.patch
The start of js tests - map and reduce are working fine, but the 'list' feature
needs some work...
> allow native view servers
> -
>
> Key: COUCHDB-377
> URL: https://issues.apache.org/jira/browse/COUCHDB-377
> Project: CouchDB
> Issue Type: Improvement
>Reporter: Mark Hammond
> Attachments: couch_native_process.erl,
> erlang_test_include_docs.patch, native_query_servers.patch,
> native_query_servers.patch, native_query_servers2.patch,
> native_view_js_tests.patch, query_proc.patch
>
>
> There has been some discussion on IRC etc about how to support 'native' view
> servers, such as 'erlview' in a generic way. Currently using erlview
> requires you to modify couch.
> I'm attaching a patch as a first attempt at supporting this. In summary, the
> patch now looks up a new 'native_query_servers' config file section for a
> list of view_server names with a {Module, Func, Args} style string specifying
> the entry-point of the view server. The code now passes an additional atom
> around indicating if the PID is 'native' or 'external', and map_docs takes
> advantage of this to avoid the json step. This patch allows erlview to work
> for me, but in theory any erlang code could be used here.
> I'm very new at erlang - please let me know if I should make stylistic or
> other changes, or indeed if I should take a different approach completely.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Dependencies in SVN
On Fri, Aug 07, 2009 at 12:10:45AM -0500, Curt Arnold wrote: > Apache Maven is implemented in Java, but the Maven master and its > mirrors aren't limited to delivering Java byte code and could deliver > source or beam files. Interesting. > The make file could download the dependencies using curl or wget. Hmm, that is an interesting proposal. > If mochiweb, ibrowse and erlang_auth have formal releases, a project > descriptor could be prepared for them and the descriptor and the release > could be uploaded to the master repo. If they don't, we could engage > with them to coordinate releases. Do you mean via Maven repository? Thanks, -- Noah Slater, http://tumbolia.org/nslater
Re: Dependencies in SVN
FWIW, in my two years with Erlang, I've never came across CEAN in any practical setting. I know it exists, but for all I know, nobody uses it. There are also the Faxien and Sinian[sp?] distribution tools, but they are not widespread either. For all I know, the Erlang community is longing for a release management system. Cheers Jan Apache Maven is implemented in Java, but the Maven master and its mirrors aren't limited to delivering Java byte code and could deliver source or beam files.The make file could download the dependencies using curl or wget. If mochiweb, ibrowse and erlang_auth have formal releases, a project descriptor could be prepared for them and the descriptor and the release could be uploaded to the master repo. If they don't, we could engage with them to coordinate releases.
Re: Uneasiness with use of github for experimentation
In retrospec, I should not write on a complicated topic while groggy and then head off to my day job. Standard disclaimer that I am not a lawyer. There are at least two issues, neither of them is specific to using git vs svn, but related to substantial or collaborative development occurring outside of the ASF infrastructure. The first is code provenance (ownership, license, etc): As previously mentioned, the JIRA does have an checkbox to indicate that a contribution is intended as a contribution. That is intended as a reinforcement (or an explicit refutation) of the implied license for things posted on the mailing lists or in Bugzilla (which lacks the checkbox). The implied license for contributions comes from item 5 in the ASL. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. CLA's are described on http://www.apache.org/licenses/. The following is a quote. Contributor License Agreements The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement (CLA) [PDF form]. The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. A signed CLA is required to be on file before an individual is given commit rights to an ASF project. Code should only get into an Apache project in one of the following ways: A contribution submitted on the mailing list or bug tracker that is either implicitly licensed under the ASF via item 5 or explicitly under a CLA. An individual contribution committed into the SVN under the terms of a signed CLA on file. An external contribution cleared through the incubator. In the case of a substantial contribution on the mailing list or bug tracker, the PMC may think it is warranted to have a signed CLA on file before incorporating the code. That is a judgement call left up to the PMC, but as with anything can be overriden by the board. The mailing lists are archived, the bug trackers are logged and archived. If there is ever a challenge the ASF should be able to trace any piece of code back to a particular email or bug tracker or SVN user who represented that the code was their original creation which they intended and had the right to license under the ASL. The ASF license allows forking and commercialized or internal variants. Unlike the GPL, however it does not require that forkers donate their code back to the ASF. I'm fully within my legal limits to create "Curt's Relaxing Database" from the Apache CouchDB code and make it available under the ASL or under a more restrictive license as long as I comply with the ASF terms on the code that I incorporated from the ASF. If I set up CRDb as independent project under a different license and I accepted contributions from others, I may not have the rights to relicense their contributions back the the ASF if I ever decided to merge CRDb. Also, those contributions would not be documented in the ASF infrastructure as would contributions that had gone into CouchDB. Because of that, any convergence would need to go through the Incubator to make sure that every contribution is documented. While not intentional doing collaborative development outside of the ASF infrastructure has a lot of similarities to an intentional forking. For a small window of time, a developer is offering a code base under the ASL may be incorporating contributions from others where the ASL has no record of either the transaction or the possible separate license agreement that was executed between the forker and the contributor. The second issue is open, collaborative development: From http://www.apache.org/foundation/how-it-works.html#what The Apache Software Foundation (ASF) is a 501(c)3 non-profit organization incorporated in the United States of America and was formed primarily to: • provide a foundation for open, collaborative software development projects by supplying hardware, communication, and business infrastructure ... We endeavour to conduct as much discussion in public as possible. This encourages openness, provides a public record, and stimulates the broader community. Using github is definitely more open than doing a whole lot of wor
Re: Website redesign
I like it 2 comments: 1. force the vertical scrollbar always to be there.This way when changing pages the column doesn't move when the scroll bar appears 2. The red headings look dirty, use a lighter red :) Nick On Thu, Aug 6, 2009 at 11:35 PM, maddiin wrote: > I was too lazy to set the site up on my machine and attached it to this > mail instead. You'll have to open the index.html in the htdocs folder to > start browsing. > > Since the screenshot I've: > > * darkened the page background, so your eyes will hopefully be less > distracted from the content > * added background color to section headers > * did something to the navigation bar > * and removed the search link from the navigation bar > o maybe add a search box to the top right of the header? > > The logo is still just a placeholder, I hope someone else jumps in to give > it some love. >
Re: Website redesign
On Thu, Aug 06, 2009 at 03:35:34PM +0200, maddiin wrote: >* darkened the page background, so your eyes will hopefully be less > distracted from the content Cool. >* added background color to section headers I think I preferred it when all the headers were that redish colour. >* did something to the navigation bar Cool. >* and removed the search link from the navigation bar > o maybe add a search box to the top right of the header? Does anyone use site search any more? Google FTW. Heh. On Thu, Aug 06, 2009 at 09:59:38AM -0400, Damien Katz wrote: > I like it except for the "Time to relax" in the logo. After seeing it, I think I agree. After having used it in the IRC topic for so many years, I wanted to see if we could get it on the website as the project strapline. Maybe it would work if it was right-aligned as in the header instead? On Thu, Aug 06, 2009 at 08:35:33AM -0700, Chris Anderson wrote: > Agreed, we should avoid changing our logo / word mark. Why? Brand evolution is healthy when done with care! > Also, I think I'm partial to the old darker colors. They seem a little > more serious... I always thought they looked boring. Heh. CouchDB is sexy! (Oh man, did I just describe a database as sexy?) The lighter colours are more complementary with Futon, which I think is a nice direction. > But also this design makes me realize that we should work on bringing > the content up to date not just the layout. Yes, I think this could be the next area to focus on. We've come a long, long way since we first did this website, and we would do well to re-align our website with our current status and the project goals. Reminds me off this essay: Thus, the differences between Redesigners and Realigners might be summarized as follows: The desire to redesign is aesthetic-driven, while the desire to realign is purpose-driven. One approach seeks merely to refresh, the other aims to fully reposition and may or may not include a full refresh. (Note that by “reposition,” I mean strategy and not physical location or dimensions.) - http://www.alistapart.com/articles/redesignrealign Best, -- Noah Slater, http://tumbolia.org/nslater
Re: History Proposal
On Thu, Aug 06, 2009 at 05:04:34PM +0100, Jason Davies wrote: > All in all, it seems to me that reusing _rev for history saves us having > to doing an additional read and an additional write (reading the old doc > or attachment and then writing it as an attachment). Is this a good > enough reason to reuse _rev for this? Without wanting to get involved in the technicalities of the discussions I will say that with all other things being equal, I would prefer a system that reused _rev for document history. That so many of our users try to do this naturally should be clue enough that it might be a good direction to take. Best, -- Noah Slater, http://tumbolia.org/nslater
Re: Help required with Debian CouchDB package
Hey, I hadn't realised that the Debian Erlang team was just me and Sergei! I was under the impression that there were at least a handful of other people. Oh well, I guess it's about to grow in size a little. Three of you have offered to help maintain the package: Jim Tarvid Sam Bisbee Elliot Murphy Thanks guys! I am overwhelmed by your response. I think that Sam and Elliot both have packaging experience, which is great. The other existing member of the Debian Erlang packaging team is: Sergei Golovan Sergei is a Debian developer, and maintains the core Erlang packages. While he is unable to help maintain the CouchDB package directly, he is happy to continue checking and uploading new versions of it for you. This means that Sergei will be your package sponsor. For this to work, you will need to prepare your changes in the existing Subversion repository, and then ask Sergei to review them and upload the new package version to Debian. You will need to request membership for the project: http://developer.berlios.de/projects/erlang-pkg/ I think Sergei will have to confirm that you're allowed to join the project. You can then check out the source via: http://developer.berlios.de/svn/?group_id=6649 The CouchDB package is under the couchdb directory: http://svn.berlios.de/svnroot/repos/erlang-pkg/couchdb/ Please also sign up to the Erlang team mailing list: https://lists.berlios.de/mailman/listinfo/erlang-pkg-devel I will remain on this list for a while, and monitor for any problems you have. Any more discussion should probably move to the Erlang list. For those totally new to Debian packaging, you should read through: http://www.debian.org/doc/maint-guide/ http://www.debian.org/doc/developers-reference/ http://www.debian.org/doc/debian-policy/ Some of the Debian mentor documentation might also be enlightening: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html However, you're not going to be using the Debian mentors system. This Debian mentors system traditionally provides a way for volunteers to maintain packages with a group of experienced Debian developers available to upload your changes after some peer-review. As Sergei has offered to do this for you, you get to short-circuit the whole procedure. Thanks Sergei! Sam Bisbee wrote: > Do we have a task list, or are we focusing on getting 0.9.0 and then 0.9.1 > through the gauntlet and obeying the latest Debian Policy? Elliot wrote: > Does preparing the 0.9.1 release involve anything else other than the normal > process for generating a source package for a new upstream release? 0.9.0-2 (any version with "-" in it is the Debian package version, in this case, it is the second Debian version of CouchDB 0.9.0) contains a patch that was merged into CouchDB 0.9.1 proper: http://svn.berlios.de/svnroot/repos/erlang-pkg/couchdb/trunk/debian/patches/pid.patch You should remove this patch for the next upload. Aside from updating the debian/changelog to 0.9.1-1 and checking that the debian/copyright file is still valid, I don't think there's much else to do. You should always build your package with pdebuild, because this builds and installs the CouchDB package in a chroot, and allows you to test properly. The Ubuntu instructions for pbuilder are more comprehensive than the Debian ones: https://wiki.ubuntu.com/PackagingGuide/Intro/Pbuilder My local customisation is: nsla...@tumbolia: ~ $ cat .pbuilderrc HOOKDIR=/home/nslater/.pbuilder-hooks nsla...@tumbolia: ~ $ ls -l ~/.pbuilder-hooks total 4.0K lrwxrwxrwx 1 nslater nslater 8 2008-11-04 16:45 B10shell -> C10shell -rwxr-x--x 1 nslater nslater 135 2009-08-06 23:42 C10shell nsla...@tumbolia: ~ $ cat .pbuilder-hooks/C10shell #!/bin/sh apt-get install -y --force-yes emacs22-nox less bash cd /tmp/buildd/*/debian/.. /bin/bash < /dev/tty > /dev/tty 2> /dev/tty I recommend you do the same. What this does is: * If the build fails, it gives you a shell in the chroot. * Once the package is installed, it gives you a shell in the chroot. You should use the first to debug. You should use the second to start CouchDB inside the chroot and run the unit tests via your browser. Doing this properly will save Sergei a lot of time having to send emails about how the package is broken for such and such a case. Elliot wrote: > Noah, I know that in Ubuntu we had made some permissions changes in the > packaging for couchdb to enable per-user couchdb instances to be started in > Ubuntu. Are there other changes that you know are pending for the package? Nope. For reference, the patch is: http://launchpadlibrarian.net/29425557/403575.debdiff I think you should apply the changes to the debian/postinst file. Elliot wrote: > Once I have a source package that I have been able to build in a pbuilder and > test, what is the process for getting a sponsor to upload to debian? Ah, another pbuilder user! Great! Sergei has offered to be th
Re: History Proposal
Hi Brian, On 6 Aug 2009, at 21:01, Brian Candler wrote: On Thu, Aug 06, 2009 at 05:04:34PM +0100, Jason Davies wrote: The other good thing about storing historical versions as attachments is that they would get replicated. Currently we don't replicate old MVCC versions, this would have to change as well as preventing them from being compacted as you say. However, we do replicate old MVCC versions if they are conflicting, and we do keep them through compaction. Perhaps "conflicting" and "historical" could be treated in roughly the same way? You resolve conflicts by deleting the conflicting rev(s). This could be done for deleting historical versions too. This is the approach I'm taking in my experimental branch. I will let you know how I get on! Thanks, -- Jason Davies www.jasondavies.com
Re: Uneasiness with use of github for experimentation
On Thu, Aug 06, 2009 at 02:45:44PM -0400, Paul Davis wrote: > You mean that we need to go find every person that's ever put a patch > on JIRA and get them to sign a legal document? As Jan pointed out, JIRA has a checkbox for this. Heh. > And how does this work if someone points out a one liner to me on IRC? Similar to what Dirkjan pointed out, the FSF maintains that anything under 15 lines is probably insignificant for copyright purposes. This opinion is based on legal advice, but has not been tested in court to the best of my knowledge. > Or over my shoulder? Same as above. > Or what if someone describes an idea for a feature and I implement it? This isn't how copyright works, thankfully. Copyright covers the actual creative output, not the ideas behind that creative output. I could take the idea behind Pulp Fiction, and shoot my own gritty northern version, set in Newcastle. I doubt Tarantino would mind. Similarly, I can re-implement someone else's idea without many problems. This happens all the time, for example: GNU, Linux, Mono, GNU Classpath, GNU Gnash, OpenOffice, &c. The thing you need to worry about is patents, but that's another kettle of fish. And in fact, the Apache license addresses this directly. > The more I ponder the legal ramifications of my interactions the more > I feel as though I should never read dev@ for fear that I unknowingly > introduce someone's intellectual property into SVN. This is probably a side effect of calling it intellectual property: It has become fashionable to toss copyright, patents, and trademarks — three separate and different entities involving three separate and different sets of laws — into one pot and call it “intellectual property”. The distorting and confusing term did not arise by accident. Companies that gain from the confusion promoted it. The clearest way out of the confusion is to reject the term entirely. - http://www.gnu.org/philosophy/not-ipr.html I would prefer it if the ASF stopped using this term and instead talked about copyright, patents, and trademarks. There is enough to get confused about as it is, as is demonstrated by your email, without making that any worse. Best, -- Noah Slater, http://tumbolia.org/nslater
Re: History Proposal
On Thu, Aug 06, 2009 at 05:04:34PM +0100, Jason Davies wrote: > The other good thing about storing historical > versions as attachments is that they would get replicated. Currently we > don't replicate old MVCC versions, this would have to change as well as > preventing them from being compacted as you say. However, we do replicate old MVCC versions if they are conflicting, and we do keep them through compaction. Perhaps "conflicting" and "historical" could be treated in roughly the same way? You resolve conflicts by deleting the conflicting rev(s). This could be done for deleting historical versions too.
Re: Uneasiness with use of github for experimentation
On 6 Aug 2009, at 20:45, Paul Davis wrote: On Thu, Aug 6, 2009 at 2:12 PM, Mikeal Rogers wrote: A CLA is required for any contribution, even patches. You mean that we need to go find every person that's ever put a patch on JIRA and get them to sign a legal document? JIRA has a checkbox that is an in-place CLA for patches in JIRA. Cheers Jan -- And how does this work if someone points out a one liner to me on IRC? Or over my shoulder? Or what if someone describes an idea for a feature and I implement it? The more I ponder the legal ramifications of my interactions the more I feel as though I should never read dev@ for fear that I unknowingly introduce someone's intellectual property into SVN. The scary part is I'm only half joking. HTH, Paul Davis
Re: feed=continuous and newline
On Thu, Aug 06, 2009 at 11:55:07AM -0400, Adam Kocoloski wrote: > I'm +1 on appending the newline immediately and moving the comma to the > beginning of the next line. Cool. Do you think it's worth making views consistent with this too, so clients can use the same code to parse both? (Although it will cause some one-off breakage for existing clients hardcoded to the old behaviour)
Re: Uneasiness with use of github for experimentation
On Thu, Aug 6, 2009 at 20:45, Paul Davis wrote: > The more I ponder the legal ramifications of my interactions the more > I feel as though I should never read dev@ for fear that I unknowingly > introduce someone's intellectual property into SVN. > > The scary part is I'm only half joking. I think the Python lawyers determined once that the size of a relevant contribution was at least 10-30 LOC, so one-liners should be fine. (And if you think that's a joke, it's probably only half a joke.) Cheers, Dirkjan
Re: Uneasiness with use of github for experimentation
On Thu, Aug 6, 2009 at 2:12 PM, Mikeal Rogers wrote: > A CLA is required for any contribution, even patches. You mean that we need to go find every person that's ever put a patch on JIRA and get them to sign a legal document? And how does this work if someone points out a one liner to me on IRC? Or over my shoulder? Or what if someone describes an idea for a feature and I implement it? The more I ponder the legal ramifications of my interactions the more I feel as though I should never read dev@ for fear that I unknowingly introduce someone's intellectual property into SVN. The scary part is I'm only half joking. HTH, Paul Davis
Re: Uneasiness with use of github for experimentation
A CLA is required for any contribution, even patches. An SVN repository doesn't inherently fix this as patches can still be sent to committers over email and then checked in. While it's true git encourages more distributed workflows it's still the responsibility of committers to make sure all contributions are contributed under a CLA whether they come through svn, git or osmosis. I'm skeptical that an apache lab repository would really be "under the oversight" of anybody since few would be watching it outside of those contributing to it which I assume are the same people currently working in github. Github does have he advantage of allowing *other* people to use this code easily and modify it for their own uses before it's made it in to the main line repository, even if those contributions don't make it back upstream because of CLA issues they are still providing some level of testing and stability checking over the work. -Mikeal On Aug 6, 2009, at August 6, 20095:24 AM, Curt Arnold wrote: While I'm bringing up contentious issues, use of github for a sandbox for developing significant modifications to CouchDB makes me uneasy. If I start something on github and accept contributions and ideas from other uses, I can't represent the eventual patch as my original work (as required by the CLA). Also, it reduces the visibility (barring an explicit opt-in) of the development from the radar of the PMC and community. Other ASF projects have created "sandboxes" in their SVN for experimental work and the threshold for commit access to the sandbox could be lower than the trunk (still would require CLA and an Apache account). Any Apache committer could use Apache Labs, but since that is not developed with the oversight of the community that still needs a pass through the Incubator. Having a sandbox or labs branch in the CouchDB SVN would provide a location for non-trunk development that is still under the oversight of the PMC and community.
[jira] Created: (COUCHDB-456) DB-level configuration system
DB-level configuration system - Key: COUCHDB-456 URL: https://issues.apache.org/jira/browse/COUCHDB-456 Project: CouchDB Issue Type: New Feature Reporter: Adam Kocoloski It would be very useful to have an analog of the _config system for each individual database. These settings could be changed by users without server admin privileges. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-455) get_result,infinity error when replicating an empty database
[
https://issues.apache.org/jira/browse/COUCHDB-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740132#action_12740132
]
Adam Kocoloski commented on COUCHDB-455:
Hi Enda, thanks for the report. I have to admit I'm a bit stumped at first.
The error message indicates that the replication gen_server had exited before
the call to get_result. Couch 0.9.0 and higher should protect against that.
Were there any other related error messages?
There is one scenario I can dream up. Are you triggering that same replication
multiple times simultaneously? That is
A POSTs to _replicate
B POSTs to _replicate with identical request body
A receives a response, replicator shuts down
B gets a noproc error
In this case we try to add B as a listener to the original replication, but
it's technically possible the replication could terminate in between when B
gets the process id and when it asks for the result.
> get_result,infinity error when replicating an empty database
>
>
> Key: COUCHDB-455
> URL: https://issues.apache.org/jira/browse/COUCHDB-455
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9
>Reporter: Enda Farrell
>
> We have code that regularly calls for CouchDB nodes to replicate with pairs
> in our other datacentre. It ocassionally has the follwing error:
> {code}
> INFO bbc.forge.engineering.couchdb.replicatr.ReplicateWorker 371 - Bad
> replication: [kv103.back.live.telhc.local:5986/tvp_yahoowidgets <-
> kv103.back.live.telhc.local:5986 (ACE_METADATA_)
> {"source":"http://kv103.back.live.telhc.local:5986/tvp_yahoowidgets","target":"tvp_yahoowidgets"}]:
> response:[HTTP/1.1 500 Internal Server Error -
> {"error":"noproc","reason":"{gen_server,call,[<0.17199.212>,get_result,infinity]}"}
> {code}
> The remote database
> "http://kv103.back.live.telhc.local:5986/tvp_yahoowidgets"; is empty:
> {code}curl http://kv103.back.live.telhc.local:5986/tvp_yahoowidgets
> {"db_name":"tvp_yahoowidgets","doc_count":0,"doc_del_count":0,"update_seq":0,"purge_seq":0,"compact_running":false,"disk_size":5920,"instance_start_time":"1249559096646177"}
> {code}
> This same "get_result,infinity", is seen on another empty database:
> {code}
> curl http://kv103.back.live.telhc.local:5984/avalanche150k
> {"db_name":"avalanche150k","doc_count":0,"doc_del_count":0,"update_seq":0,"purge_seq":0,"compact_running":false,"disk_size":250480,"instance_start_time":"1249559230162131"}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: History Proposal
Hi Brian, On 4 Aug 2009, at 10:56, Brian Candler wrote: On Mon, Aug 03, 2009 at 06:21:34PM +0100, Jason Davies wrote: Comments welcomed! ISTM that the "historical" versions are already stored, so why duplicate them in the form of an attachment to a new version? And what about historical versions of attachments anyway? Wouldn't it be simpler to: - keep the historical versions by _rev as they are now - somehow mark these historical versions as worth keeping or not (could be as simple as reusing the _deleted flag) - make the "worth keeping" versions survive compaction Then when you PUT a document, you'd have two options: apply the _deleted flag automatically to the old revision, or not. This could be chosen by URL parameter perhaps. Some views might want access to historical revs, but perhaps this should be controlled by a view parameter to filter them out for views which are only interested in the most recent one. (Incidentally, I would like views to have access to live conflicting revs too, but that's a separate issue) I like the simplicity of your idea, but I'd be interested to hear Damien's opinion on essentially using MVCC revisions as history too. Is there a potential difficulty with doing this that we're missing? You said that it seems unnecessary to duplicate the historical versions as attachments. Yes, you may have a point, but in the current way of doing things the duplicates would be removed after compaction. If I understand things correctly, only new attachments get written out to disk every time they are added, so it's not as if *all* historical versions are appended to the database file every time a document is modified, only a single old version would be appended (as an attachment) as well as the new doc, of course. The other good thing about storing historical versions as attachments is that they would get replicated. Currently we don't replicate old MVCC versions, this would have to change as well as preventing them from being compacted as you say. Good point about storing attachments in the history, this could potentially become a space issue assuming we simply write the attachments as JSON docs with the attachments embedded as base64. A better approach would be to store hashes and store the attachments themselves separate from the historical versions (using with some kind of prefix). This way we only write a new historical attachment if it changes. All in all, it seems to me that reusing _rev for history saves us having to doing an additional read and an additional write (reading the old doc or attachment and then writing it as an attachment). Is this a good enough reason to reuse _rev for this? Thanks, -- Jason Davies www.jasondavies.com
Re: feed=continuous and newline
On Aug 6, 2009, at 10:17 AM, Brian Candler wrote:
Raising a minor point here for discussion, rather than on JIRA.
With feed=continuous, the newline after the last record isn't sent
until the
*next* record is available. For example:
$ telnet localhost 5984
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test/_changes?feed=continuous HTTP/1.0
Host: localhost
HTTP/1.0 200 OK
Server: CouchDB/0.10.0a (Erlang OTP/R12B)
Date: Thu, 06 Aug 2009 14:11:26 GMT
Content-Type: text/plain;charset=utf-8
Cache-Control: must-revalidate
{"results":[
{"seq":1,"id":"1f9bcccaadf2c3e9508d42532838595f","changes":
[{"rev":"1-23202479633c2b380f79507a776743d5"}]},
{"seq":2,"id":"291e49cc084d2e180f3a5d313d255889","changes":
[{"rev":"1-3975759ccff3842adf690a5c10caee42"}]},
{"seq":3,"id":"a6bdc0e451df85169178f0d9619b605a","changes":
[{"rev":"1-027467bd0efec85f21c822a8eb537073"}]}
->
stops at end of line
When the next record is generated, it adds .
Whilst this makes the feed pretty to read, it doesn't make it easy
to parse,
as you basically need a full JSON stream parser to delimit the
record. Or
else, you're always one record behind.
Wouldn't it be better to send the record followed by a newline, and
then
for the next one? That is,
{"results":[
{"seq":1,"id":"1f9bcccaadf2c3e9508d42532838595f","changes":
[{"rev":"1-23202479633c2b380f79507a776743d5"}]}
,{"seq":2,"id":"291e49cc084d2e180f3a5d313d255889","changes":
[{"rev":"1-3975759ccff3842adf690a5c10caee42"}]}
,{"seq":3,"id":"a6bdc0e451df85169178f0d9619b605a","changes":
[{"rev":"1-027467bd0efec85f21c822a8eb537073"}]}
],
"last_seq":3}
Regards,
Brian.
Hi Brian, Matt Goodall brought this up last month too:
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/%3c214c385b0907070612r3ed4dad9ydc9e81c7aa3f6...@mail.gmail.com%3e
I'm +1 on appending the newline immediately and moving the comma to
the beginning of the next line.
Adam
Re: feed=continuous and newline
2009/8/6 Brian Candler :
> Raising a minor point here for discussion, rather than on JIRA.
>
> With feed=continuous, the newline after the last record isn't sent until the
> *next* record is available. For example:
>
> $ telnet localhost 5984
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /test/_changes?feed=continuous HTTP/1.0
> Host: localhost
>
> HTTP/1.0 200 OK
> Server: CouchDB/0.10.0a (Erlang OTP/R12B)
> Date: Thu, 06 Aug 2009 14:11:26 GMT
> Content-Type: text/plain;charset=utf-8
> Cache-Control: must-revalidate
>
> {"results":[
> {"seq":1,"id":"1f9bcccaadf2c3e9508d42532838595f","changes":[{"rev":"1-23202479633c2b380f79507a776743d5"}]},
> {"seq":2,"id":"291e49cc084d2e180f3a5d313d255889","changes":[{"rev":"1-3975759ccff3842adf690a5c10caee42"}]},
> {"seq":3,"id":"a6bdc0e451df85169178f0d9619b605a","changes":[{"rev":"1-027467bd0efec85f21c822a8eb537073"}]}
> ->
> stops at end of line
>
> When the next record is generated, it adds .
>
> Whilst this makes the feed pretty to read, it doesn't make it easy to parse,
> as you basically need a full JSON stream parser to delimit the record. Or
> else, you're always one record behind.
>
> Wouldn't it be better to send the record followed by a newline, and then
>for the next one? That is,
>
> {"results":[
> {"seq":1,"id":"1f9bcccaadf2c3e9508d42532838595f","changes":[{"rev":"1-23202479633c2b380f79507a776743d5"}]}
> ,{"seq":2,"id":"291e49cc084d2e180f3a5d313d255889","changes":[{"rev":"1-3975759ccff3842adf690a5c10caee42"}]}
> ,{"seq":3,"id":"a6bdc0e451df85169178f0d9619b605a","changes":[{"rev":"1-027467bd0efec85f21c822a8eb537073"}]}
> ],
> "last_seq":3}
Yep, I agree and already logged a ticket (with a patch) for this,
https://issues.apache.org/jira/browse/COUCHDB-405.
I'm actually sticking to using a longpoll feed for now to avoid the
messy parsing.
- Matt
[jira] Commented: (COUCHDB-452) couch logs an [error] record if a client disconnects
[
https://issues.apache.org/jira/browse/COUCHDB-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740117#action_12740117
]
Chris Anderson commented on COUCHDB-452:
The special case matches were added one at a time, because those are two
special cases where having a stacktrace in the logs can help with debugging on
the ML and IRC.
However, the general matcher now logs a stacktrace just the same as they did,
so it's fine to let the general case handle them. (I guess we finally got few
enough errors coming from deep within CouchDB that a stacktrace on any uncaught
error works fine.)
Removing the special case matchers just cleans up the code and does not change
functionality.
> couch logs an [error] record if a client disconnects
>
>
> Key: COUCHDB-452
> URL: https://issues.apache.org/jira/browse/COUCHDB-452
> Project: CouchDB
> Issue Type: Improvement
>Reporter: Mark Hammond
> Attachments: dont_log_error_on_disconnect.patch
>
>
> If a client makes a request which returns multiple rows (eg, a query) but
> disconnects before reading the response, couch logs:
> [error] [<0.66.0>] Uncaught error in HTTP request: {exit,normal}
> [info] [<0.66.0>] Stacktrace: [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_view,send_json_view_row,5},
> {couch_httpd_view,'-make_view_fold_fun/6-fun-0-',12},
> {couch_view,fold_fun,4},
> {couch_btree,stream_kv_node2,7},
> {couch_btree,stream_kp_node,7},
> {couch_btree,fold,5}]
> This could lead someone to conclude couch has an error which is not correct.
> A simple [info] record recording the premature normal exit is probably more
> appropriate.
> FYI, the easiest way I found to repro this was to execute:
> % python -c "import urllib;
> urllib.urlopen('http://127.0.0.1:5984/your_db/_design/your_design_doc/_view/your_view?reduce=false').close()"
> which causes Python to open a connection and close it without reading
> anything. I'll attach a patch as suggested generally by jchris.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Uneasiness with use of github for experimentation
On Aug 6, 2009, at 9:31 AM, Stephan Wehner wrote: On Thu, Aug 6, 2009 at 6:21 AM, Jan Lehnardt wrote: On 6 Aug 2009, at 15:13, Robert Dionne wrote: Git really encourages a more distributed, less centralized approach to development, that allows the centers of gravity to move as they evolve. This is a good and healthy thing in many contexts, perhaps less so in others. I'm not sure what the issue is with respect to the CLA. What prevents you from representing a contribution as your original work because it originated in GitHub? How does playing in an internal Apache sandbox solve that? All ASF committers singed a CLA that says all work committed has been done by the committer or has gone through incubator IP clearance. If you get a patch on github, that is not your work, when you then commit that, you break the CLA. If you do sole development on github, no problem, but github encourages the code-collaboration. I don't quite understand. To me the solution is: Then you shouldn't commit patches through git that are not based on your work? The difference between git / subversion here is that git makes it easier for others to fork. But what goes into your repository is still under your control. What am I missing? Stephan Hi Stephan, I think you've got it. If someone sends me a pull request on GitHub, I can't apply the patch to some feature I'm working on and then commit the result to ASF SVN. I have to ask that the patch be submitted to JIRA (where the submitter explicitly selects an ASF license) instead. I hope that as long as all the committers are clear on the ground rules we can continue to develop on git/github. I'm too enamored of distributed version control to go back to SVN branches willingly. Adam
Re: Website redesign
On Thu, Aug 6, 2009 at 6:59 AM, Damien Katz wrote: > I like it except for the "Time to relax" in the logo. I like the old RELAX > much better. > Agreed, we should avoid changing our logo / word mark. Also, I think I'm partial to the old darker colors. They seem a little more serious... But also this design makes me realize that we should work on bringing the content up to date not just the layout. Chris > > On Aug 6, 2009, at 9:52 AM, Jan Lehnardt wrote: > >> Hi, >> >> I've uploaded the site for you to look at: >> >> http://people.apache.org/~jan/couchdb.org.new/couch-site/htdocs/ >> >> Cheers >> Jan >> -- >> >> On 6 Aug 2009, at 15:35, maddiin wrote: >> >>> I was too lazy to set the site up on my machine and attached it to this >>> mail instead. You'll have to open the index.html in the htdocs folder to >>> start browsing. >>> >>> Since the screenshot I've: >>> >>> * darkened the page background, so your eyes will hopefully be less >>> distracted from the content >>> * added background color to section headers >>> * did something to the navigation bar >>> * and removed the search link from the navigation bar >>> o maybe add a search box to the top right of the header? >>> >>> The logo is still just a placeholder, I hope someone else jumps in to >>> give it some love. >>> >> > > -- Chris Anderson http://jchrisa.net http://couch.io
Re: What's your Erlang VM version?
On Aug 6, 2009, at 3:45 AM, Brian Candler wrote:
- To me the backtrace suggests a problem with re:split, but it
mentions
oauth in the same breath
[Thu, 06 Aug 2009 07:40:27 GMT] [error] [<0.104.0>]
{error_report,<0.22.0>,
{<0.104.0>,crash_report,
[[{pid,<0.104.0>},
{registered_name,[]},
{error_info,
{error,undef,
[{re,split,
["{couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}",
I believe re.erl wasn't stable until at least R12B-5, so that error
makes sense. I don't know about the availability of 12B-5 in various
package management systems, but I'm leaning towards just making that
the minimum required Erlang version.
Best, Adam
[jira] Commented: (COUCHDB-449) Turn off delayed commits by default
[ https://issues.apache.org/jira/browse/COUCHDB-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740093#action_12740093 ] Adam Kocoloski commented on COUCHDB-449: +1 on turning off delayed commits by default +1 for enabling them on a per-DB basis +0 for making the threshold configurable We should add a DB-level configuration facility at some point. It'd be nice to be able to edit this setting (and others, like continuous replication) without server-level admin privileges. > Turn off delayed commits by default > --- > > Key: COUCHDB-449 > URL: https://issues.apache.org/jira/browse/COUCHDB-449 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Affects Versions: 0.9, 0.9.1 >Reporter: Jan Lehnardt >Priority: Blocker > Fix For: 0.10 > > > Delayed commits make CouchDB significantly faster. They also open a one > second window for data loss. In 0.9 and trunk, delayed commits are enabled by > default and can be overridden with HTTP headers and an explicit API call to > flush the write buffer. I suggest to turn off delayed commits by default and > use the same overrides to enable it per request. A per-database option is > possible, too. > One concern is developer workflow speed. The setting affects the test suite > performance significantly. I'd opt to change couch.js to set the appropriate > header to enable delayed commits for tests. > CouchDB should guarantee data safety first and speed second, with sensible > overrides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Missing conditions and disclaimer for ibrowse
Hi Curt, On 6 Aug 2009, at 04:37, Curt Arnold wrote: The source for the ibrowse HTTP client was committed into the SVN in January. Didn't see any evidence of a dev vote and/or Incubator review before the code was committed. The copyright is in the NOTICE, but not the list of conditions or the disclaimer from the apparent license in http://jungerl.cvs.sourceforge.net/viewvc/*checkout*/jungerl/jungerl/lib/ibrowse/BSD_LICENSE?revision=1.1 FYI I'm sorting out a software grant agreement from Chandru and completing all the necessary steps for a third-party module import of ibrowse (expect a vote thread soon). Thanks! -- Jason Davies www.jasondavies.com
[jira] Commented: (COUCHDB-452) couch logs an [error] record if a client disconnects
[
https://issues.apache.org/jira/browse/COUCHDB-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740087#action_12740087
]
Adam Kocoloski commented on COUCHDB-452:
Yes, that's a good point Curt. Just yesterday Jason needed to add some logging
in MochiWeb to find out that a gen_tcp:recv was timing out. The log just said
{exit,normal} there, too.
> couch logs an [error] record if a client disconnects
>
>
> Key: COUCHDB-452
> URL: https://issues.apache.org/jira/browse/COUCHDB-452
> Project: CouchDB
> Issue Type: Improvement
>Reporter: Mark Hammond
> Attachments: dont_log_error_on_disconnect.patch
>
>
> If a client makes a request which returns multiple rows (eg, a query) but
> disconnects before reading the response, couch logs:
> [error] [<0.66.0>] Uncaught error in HTTP request: {exit,normal}
> [info] [<0.66.0>] Stacktrace: [{mochiweb_request,send,2},
> {couch_httpd,send_chunk,2},
> {couch_httpd_view,send_json_view_row,5},
> {couch_httpd_view,'-make_view_fold_fun/6-fun-0-',12},
> {couch_view,fold_fun,4},
> {couch_btree,stream_kv_node2,7},
> {couch_btree,stream_kp_node,7},
> {couch_btree,fold,5}]
> This could lead someone to conclude couch has an error which is not correct.
> A simple [info] record recording the premature normal exit is probably more
> appropriate.
> FYI, the easiest way I found to repro this was to execute:
> % python -c "import urllib;
> urllib.urlopen('http://127.0.0.1:5984/your_db/_design/your_design_doc/_view/your_view?reduce=false').close()"
> which causes Python to open a connection and close it without reading
> anything. I'll attach a patch as suggested generally by jchris.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Dependencies in SVN
On 6 Aug 2009, at 13:54, Curt Arnold wrote: On Aug 6, 2009, at 12:04 AM, Noah Slater wrote: Hey, On Wed, Aug 05, 2009 at 11:45:52PM -0500, Curt Arnold wrote: Having an external code base in the SVN is an invitation to fork which results in the ASF effectively publishing software under a license other the the ASL v2. That is a whole different animal than having a dependency on an non-ASL'd licensed piece of software. Thank you for taking the time to review the project! Your commentary has been very helpful in clearing up a few misunderstandings I had about the ASF, and the way that code needs to be cleared before being added to a project. erlang-oauth was introduced into the SVN yesterday to support the couch_http_oauth authentication handler. It is optional, the recently added oauth authentication handler would fail to load without it but that should be all. There was no mention that the patch included third-party developed software, no dev list discussion or vote or Incubator PMC clearance. I have requested that it be removed from the SVN pending review. Ideally, we should try to import this, and fail if unavailable. Any customisation or patching that we have done to make this CouchDB compatible should be aggressively pushed upstream. I have no first hand experience with CEAN, but it appears that both mochiweb and ibrowse are available through that package manager. FWIW, in my two years with Erlang, I've never came across CEAN in any practical setting. I know it exists, but for all I know, nobody uses it. There are also the Faxien and Sinian[sp?] distribution tools, but they are not widespread either. For all I know, the Erlang community is longing for a release management system. Cheers Jan -- Another complication with having their source in our SVN is that mailing list and JIRA submitted patches are implicitly ASL licensed via paragraph 5 of the ASL or explicitly via a CLA for a contributor. However, that does not give any party the right to include that patch in a non-ASL licensed work with an license grant from the original author of the patch. We can ask the patch author to push something upstream, but the project can't do it for them. ibrowse was added initially added to the SVN in January and is an HTTP client used in replication. I was unable to find any mailing list discussion or Incubator review on the addition of this code base. Likewise. mochiweb was added in March 2008 and provides the http server included in CouchDB. The Incubator PMC was aware of this dependency based on the April 2008 Incubator PMC board report. In addition to the http server, CouchDB also uses mochiweb routines for parsing query strings, url encoding, etc. Likewise. Most of the other dependencies are used in the Futon management client. These are small JavaScript libraries, and where I see that individual Erlang libraries should be satisfied externally to CouchDB, I do not think that the same should apply to JavaScript. This is no way of "importing" a library, and no standard way of packaging shared libraries that I am aware of. My thoughts too, thanks for elaborating. To minimize the amount of effort that a user has to perform to satisfy their license issues, I think we should consider modularizing couchdb so that a user who isn't interested in OAuth does not have to research its license, etc. I'd see the parts as: core: The database and non-network core of CouchDB. I would hope this code have no dependencies other than OTP. http: The http server dependent on MochiWeb's http services and core. replicator: dependent on core and ibrowse futon: HTTP admin console oauth: OAuth authenticator, dependent on erlang-oauth Moving our Erlang dependencies out from the source is one thing, but splitting CouchDB into multiple components is entirely another. It makes little sense to modularise the code when each of the modules would be functionally useless in isolation. But moreover, this is orthogonal to the licensing issue. By all means, some degree of modularisation and abstraction of interface might be a good direction for the project to take, but please, let's discuss that as an architectural issue separate to this one. I think we would do well to concentrate on removing the 3rd party Erlang code, or discussing the most palatable way forward, and leave it at that, for the time being. Best, It has helpful conceptually for me to say that, but that comes from a Java/C++ background where compiling against a dependency results in a binary that is then a derivative of the whatever it was compiled against. In that world, if you were linking against an LGPL library to provide some functionality to an ASF framework, you'd do the plugin outside of ASF and license it as LGPL. My understanding of erlc is that the .beam file includes only the import directives, does not need to
[jira] Closed: (COUCHDB-451) Upgrade to ibrowse 1.5.2
[ https://issues.apache.org/jira/browse/COUCHDB-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski closed COUCHDB-451. -- Resolution: Fixed Assignee: Adam Kocoloski Thanks Jason. I applied the patch and also bumped the ibrowse version number in the build system. > Upgrade to ibrowse 1.5.2 > > > Key: COUCHDB-451 > URL: https://issues.apache.org/jira/browse/COUCHDB-451 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Jason Davies >Assignee: Adam Kocoloski > Fix For: 0.10 > > Attachments: ibrowse.1.5.2.patch > > > From the commit message: > The ETS table created for load balancing of requests was not being deleted > which led to the node not being able to create any more ETS tables if queries > were made to many number of webservers. ibrowse now deletes the ETS table it > creates once the last connection to a webserver is dropped. (Reported by Seth > Falcon.) > Patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Website redesign
To me -- nice too ;) But why quotes around "time to relax"? --- DU
feed=continuous and newline
Raising a minor point here for discussion, rather than on JIRA.
With feed=continuous, the newline after the last record isn't sent until the
*next* record is available. For example:
$ telnet localhost 5984
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test/_changes?feed=continuous HTTP/1.0
Host: localhost
HTTP/1.0 200 OK
Server: CouchDB/0.10.0a (Erlang OTP/R12B)
Date: Thu, 06 Aug 2009 14:11:26 GMT
Content-Type: text/plain;charset=utf-8
Cache-Control: must-revalidate
{"results":[
{"seq":1,"id":"1f9bcccaadf2c3e9508d42532838595f","changes":[{"rev":"1-23202479633c2b380f79507a776743d5"}]},
{"seq":2,"id":"291e49cc084d2e180f3a5d313d255889","changes":[{"rev":"1-3975759ccff3842adf690a5c10caee42"}]},
{"seq":3,"id":"a6bdc0e451df85169178f0d9619b605a","changes":[{"rev":"1-027467bd0efec85f21c822a8eb537073"}]}
->
stops at end of line
When the next record is generated, it adds .
Whilst this makes the feed pretty to read, it doesn't make it easy to parse,
as you basically need a full JSON stream parser to delimit the record. Or
else, you're always one record behind.
Wouldn't it be better to send the record followed by a newline, and then
for the next one? That is,
{"results":[
{"seq":1,"id":"1f9bcccaadf2c3e9508d42532838595f","changes":[{"rev":"1-23202479633c2b380f79507a776743d5"}]}
,{"seq":2,"id":"291e49cc084d2e180f3a5d313d255889","changes":[{"rev":"1-3975759ccff3842adf690a5c10caee42"}]}
,{"seq":3,"id":"a6bdc0e451df85169178f0d9619b605a","changes":[{"rev":"1-027467bd0efec85f21c822a8eb537073"}]}
],
"last_seq":3}
Regards,
Brian.
Re: Website redesign
I like it except for the "Time to relax" in the logo. I like the old RELAX much better. -Damien On Aug 6, 2009, at 9:52 AM, Jan Lehnardt wrote: Hi, I've uploaded the site for you to look at: http://people.apache.org/~jan/couchdb.org.new/couch-site/htdocs/ Cheers Jan -- On 6 Aug 2009, at 15:35, maddiin wrote: I was too lazy to set the site up on my machine and attached it to this mail instead. You'll have to open the index.html in the htdocs folder to start browsing. Since the screenshot I've: * darkened the page background, so your eyes will hopefully be less distracted from the content * added background color to section headers * did something to the navigation bar * and removed the search link from the navigation bar o maybe add a search box to the top right of the header? The logo is still just a placeholder, I hope someone else jumps in to give it some love.
[jira] Closed: (COUCHDB-454) batch=ok buffers indefinitely
[
https://issues.apache.org/jira/browse/COUCHDB-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski closed COUCHDB-454.
--
Resolution: Fixed
Fix Version/s: 0.10
> batch=ok buffers indefinitely
> -
>
> Key: COUCHDB-454
> URL: https://issues.apache.org/jira/browse/COUCHDB-454
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Environment: CouchDB HEAD (commit commit
> aebdb31001126dab6b579b8cc2e605ef7ec499c6)
> Ubuntu Jaunty, Erlang 12B5
>Reporter: Brian Candler
>Assignee: Adam Kocoloski
> Fix For: 0.10
>
>
> It appears that documents written with batch=ok are buffered indefinitely.
> They don't appear in the _changes feed, nor in _all_docs, until you POST to
> _ensure_full_commit. This is despite me running with standard default.ini
> which has batch_save_interval=1000 (milliseconds)
> $ curl -X DELETE http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test
> {"ok":true,"id":"1b1337e31c4d9b41119d51db78ffebe3","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"ba37caf17a24236d243e9ab2c4c6daff"}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"e5d8bb7c74ca3cca4aabea8107620fad"}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"9bb2fb958f9112d79b4f388514c0ba7c"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ sleep 60
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ curl -X POST http://127.0.0.1:5984/test/_ensure_full_commit
> {"ok":true,"instance_start_time":"1249546668867264"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":4,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"9bb2fb958f9112d79b4f388514c0ba7c","key":"9bb2fb958f9112d79b4f388514c0ba7c","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"ba37caf17a24236d243e9ab2c4c6daff","key":"ba37caf17a24236d243e9ab2c4c6daff","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"e5d8bb7c74ca3cca4aabea8107620fad","key":"e5d8bb7c74ca3cca4aabea8107620fad","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Website redesign
Hi, I've uploaded the site for you to look at: http://people.apache.org/~jan/couchdb.org.new/couch-site/htdocs/ Cheers Jan -- On 6 Aug 2009, at 15:35, maddiin wrote: I was too lazy to set the site up on my machine and attached it to this mail instead. You'll have to open the index.html in the htdocs folder to start browsing. Since the screenshot I've: * darkened the page background, so your eyes will hopefully be less distracted from the content * added background color to section headers * did something to the navigation bar * and removed the search link from the navigation bar o maybe add a search box to the top right of the header? The logo is still just a placeholder, I hope someone else jumps in to give it some love.
[jira] Commented: (COUCHDB-454) batch=ok buffers indefinitely
[
https://issues.apache.org/jira/browse/COUCHDB-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740058#action_12740058
]
Adam Kocoloski commented on COUCHDB-454:
Brian, I noticed this yesterday too. Committing a patch shortly.
> batch=ok buffers indefinitely
> -
>
> Key: COUCHDB-454
> URL: https://issues.apache.org/jira/browse/COUCHDB-454
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Environment: CouchDB HEAD (commit commit
> aebdb31001126dab6b579b8cc2e605ef7ec499c6)
> Ubuntu Jaunty, Erlang 12B5
>Reporter: Brian Candler
>Assignee: Adam Kocoloski
>
> It appears that documents written with batch=ok are buffered indefinitely.
> They don't appear in the _changes feed, nor in _all_docs, until you POST to
> _ensure_full_commit. This is despite me running with standard default.ini
> which has batch_save_interval=1000 (milliseconds)
> $ curl -X DELETE http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test
> {"ok":true,"id":"1b1337e31c4d9b41119d51db78ffebe3","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"ba37caf17a24236d243e9ab2c4c6daff"}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"e5d8bb7c74ca3cca4aabea8107620fad"}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"9bb2fb958f9112d79b4f388514c0ba7c"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ sleep 60
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ curl -X POST http://127.0.0.1:5984/test/_ensure_full_commit
> {"ok":true,"instance_start_time":"1249546668867264"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":4,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"9bb2fb958f9112d79b4f388514c0ba7c","key":"9bb2fb958f9112d79b4f388514c0ba7c","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"ba37caf17a24236d243e9ab2c4c6daff","key":"ba37caf17a24236d243e9ab2c4c6daff","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"e5d8bb7c74ca3cca4aabea8107620fad","key":"e5d8bb7c74ca3cca4aabea8107620fad","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COUCHDB-454) batch=ok buffers indefinitely
[
https://issues.apache.org/jira/browse/COUCHDB-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski reassigned COUCHDB-454:
--
Assignee: Adam Kocoloski
> batch=ok buffers indefinitely
> -
>
> Key: COUCHDB-454
> URL: https://issues.apache.org/jira/browse/COUCHDB-454
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Environment: CouchDB HEAD (commit commit
> aebdb31001126dab6b579b8cc2e605ef7ec499c6)
> Ubuntu Jaunty, Erlang 12B5
>Reporter: Brian Candler
>Assignee: Adam Kocoloski
>
> It appears that documents written with batch=ok are buffered indefinitely.
> They don't appear in the _changes feed, nor in _all_docs, until you POST to
> _ensure_full_commit. This is despite me running with standard default.ini
> which has batch_save_interval=1000 (milliseconds)
> $ curl -X DELETE http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test
> {"ok":true,"id":"1b1337e31c4d9b41119d51db78ffebe3","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"ba37caf17a24236d243e9ab2c4c6daff"}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"e5d8bb7c74ca3cca4aabea8107620fad"}
> $ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
> {"ok":true,"id":"9bb2fb958f9112d79b4f388514c0ba7c"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ sleep 60
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":1,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
> $ curl -X POST http://127.0.0.1:5984/test/_ensure_full_commit
> {"ok":true,"instance_start_time":"1249546668867264"}
> $ curl http://127.0.0.1:5984/test/_all_docs
> {"total_rows":4,"offset":0,"rows":[
> {"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"9bb2fb958f9112d79b4f388514c0ba7c","key":"9bb2fb958f9112d79b4f388514c0ba7c","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"ba37caf17a24236d243e9ab2c4c6daff","key":"ba37caf17a24236d243e9ab2c4c6daff","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
> {"id":"e5d8bb7c74ca3cca4aabea8107620fad","key":"e5d8bb7c74ca3cca4aabea8107620fad","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
> ]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Uneasiness with use of github for experimentation
On Thu, Aug 6, 2009 at 6:21 AM, Jan Lehnardt wrote: > > On 6 Aug 2009, at 15:13, Robert Dionne wrote: > >> Git really encourages a more distributed, less centralized approach to >> development, that allows the centers of gravity to move as they evolve. This >> is a good and healthy thing in many contexts, perhaps less so in others. >> >> I'm not sure what the issue is with respect to the CLA. What prevents you >> from representing a contribution as your original work because it originated >> in GitHub? How does playing in an internal Apache sandbox solve that? > > All ASF committers singed a CLA that says all work committed has been done > by the committer or has gone through incubator IP clearance. If you get a > patch on github, that is not your work, when you then commit that, you break > the CLA. If you do sole development on github, no problem, but github > encourages the code-collaboration. I don't quite understand. To me the solution is: Then you shouldn't commit patches through git that are not based on your work? The difference between git / subversion here is that git makes it easier for others to fork. But what goes into your repository is still under your control. What am I missing? Stephan -- Stephan Wehner -> http://stephan.sugarmotor.org (blog and homepage) -> http://www.thrackle.org -> http://www.buckmaster.ca -> http://www.trafficlife.com -> http://stephansmap.org -- http://blog.stephansmap.org
Re: Uneasiness with use of github for experimentation
On 6 Aug 2009, at 15:13, Robert Dionne wrote: Git really encourages a more distributed, less centralized approach to development, that allows the centers of gravity to move as they evolve. This is a good and healthy thing in many contexts, perhaps less so in others. I'm not sure what the issue is with respect to the CLA. What prevents you from representing a contribution as your original work because it originated in GitHub? How does playing in an internal Apache sandbox solve that? All ASF committers singed a CLA that says all work committed has been done by the committer or has gone through incubator IP clearance. If you get a patch on github, that is not your work, when you then commit that, you break the CLA. If you do sole development on github, no problem, but github encourages the code-collaboration. It's important to recognize that not everyone in the CouchDB community is necessarily part of the Apache community. Some are just friendly visitors. Only members of the Apache community (note: note ASF Members), can commit code to ASF SVN. Cheers Jan -- Cheers, Bob On Aug 6, 2009, at 8:24 AM, Curt Arnold wrote: While I'm bringing up contentious issues, use of github for a sandbox for developing significant modifications to CouchDB makes me uneasy. If I start something on github and accept contributions and ideas from other uses, I can't represent the eventual patch as my original work (as required by the CLA). Also, it reduces the visibility (barring an explicit opt-in) of the development from the radar of the PMC and community. Other ASF projects have created "sandboxes" in their SVN for experimental work and the threshold for commit access to the sandbox could be lower than the trunk (still would require CLA and an Apache account). Any Apache committer could use Apache Labs, but since that is not developed with the oversight of the community that still needs a pass through the Incubator. Having a sandbox or labs branch in the CouchDB SVN would provide a location for non-trunk development that is still under the oversight of the PMC and community.
[jira] Commented: (COUCHDB-390) proposed additions to _changes feed
[ https://issues.apache.org/jira/browse/COUCHDB-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740047#action_12740047 ] Rune S. Larsen commented on COUCHDB-390: 2 Custom made "_changed"-functions could be handled like views and kept in design-documents for easy deployment. Idea: //_design//_changed// --- 3 You can already identify creations because _rev will start with "1-" - at least when _rev is assigned automaticly. Still it could be a nice feature to see if the doc was C/U/D. > proposed additions to _changes feed > --- > > Key: COUCHDB-390 > URL: https://issues.apache.org/jira/browse/COUCHDB-390 > Project: CouchDB > Issue Type: New Feature >Reporter: eric casteleijn >Priority: Blocker > > The _changes comet feed as a replacement for the update notifications is a > great step forward, but I'm currently missing these features: > 1. The feeds are now per database, rather than per server, which is nice in > some use cases, but in others it's preferable to have a server wide feed (In > the case of many thousands of databases on a server, and a single process > reacting to updates, by putting messages on a message queue for instance). > Ideally I'd like to have both server wide and per database _changes feeds > available. > 2. I'd like to have a configurable _changes feed that let's me declare what > data will be output in the update rows in the feed, in a similar way to > writing views. > 3. I'd like to (optionally) have information on whether a particular update > was a document creation, update or deletion, so clients would be able to > react to those differently without needing to query into the database to find > out what happened. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Uneasiness with use of github for experimentation
Git really encourages a more distributed, less centralized approach to development, that allows the centers of gravity to move as they evolve. This is a good and healthy thing in many contexts, perhaps less so in others. I'm not sure what the issue is with respect to the CLA. What prevents you from representing a contribution as your original work because it originated in GitHub? How does playing in an internal Apache sandbox solve that? It's important to recognize that not everyone in the CouchDB community is necessarily part of the Apache community. Some are just friendly visitors. Cheers, Bob On Aug 6, 2009, at 8:24 AM, Curt Arnold wrote: While I'm bringing up contentious issues, use of github for a sandbox for developing significant modifications to CouchDB makes me uneasy. If I start something on github and accept contributions and ideas from other uses, I can't represent the eventual patch as my original work (as required by the CLA). Also, it reduces the visibility (barring an explicit opt-in) of the development from the radar of the PMC and community. Other ASF projects have created "sandboxes" in their SVN for experimental work and the threshold for commit access to the sandbox could be lower than the trunk (still would require CLA and an Apache account). Any Apache committer could use Apache Labs, but since that is not developed with the oversight of the community that still needs a pass through the Incubator. Having a sandbox or labs branch in the CouchDB SVN would provide a location for non-trunk development that is still under the oversight of the PMC and community.
Uneasiness with use of github for experimentation
While I'm bringing up contentious issues, use of github for a sandbox for developing significant modifications to CouchDB makes me uneasy. If I start something on github and accept contributions and ideas from other uses, I can't represent the eventual patch as my original work (as required by the CLA). Also, it reduces the visibility (barring an explicit opt-in) of the development from the radar of the PMC and community. Other ASF projects have created "sandboxes" in their SVN for experimental work and the threshold for commit access to the sandbox could be lower than the trunk (still would require CLA and an Apache account). Any Apache committer could use Apache Labs, but since that is not developed with the oversight of the community that still needs a pass through the Incubator. Having a sandbox or labs branch in the CouchDB SVN would provide a location for non-trunk development that is still under the oversight of the PMC and community.
Re: Dependencies in SVN
On Aug 6, 2009, at 12:04 AM, Noah Slater wrote: Hey, On Wed, Aug 05, 2009 at 11:45:52PM -0500, Curt Arnold wrote: Having an external code base in the SVN is an invitation to fork which results in the ASF effectively publishing software under a license other the the ASL v2. That is a whole different animal than having a dependency on an non-ASL'd licensed piece of software. Thank you for taking the time to review the project! Your commentary has been very helpful in clearing up a few misunderstandings I had about the ASF, and the way that code needs to be cleared before being added to a project. erlang-oauth was introduced into the SVN yesterday to support the couch_http_oauth authentication handler. It is optional, the recently added oauth authentication handler would fail to load without it but that should be all. There was no mention that the patch included third-party developed software, no dev list discussion or vote or Incubator PMC clearance. I have requested that it be removed from the SVN pending review. Ideally, we should try to import this, and fail if unavailable. Any customisation or patching that we have done to make this CouchDB compatible should be aggressively pushed upstream. I have no first hand experience with CEAN, but it appears that both mochiweb and ibrowse are available through that package manager. Another complication with having their source in our SVN is that mailing list and JIRA submitted patches are implicitly ASL licensed via paragraph 5 of the ASL or explicitly via a CLA for a contributor. However, that does not give any party the right to include that patch in a non-ASL licensed work with an license grant from the original author of the patch. We can ask the patch author to push something upstream, but the project can't do it for them. ibrowse was added initially added to the SVN in January and is an HTTP client used in replication. I was unable to find any mailing list discussion or Incubator review on the addition of this code base. Likewise. mochiweb was added in March 2008 and provides the http server included in CouchDB. The Incubator PMC was aware of this dependency based on the April 2008 Incubator PMC board report. In addition to the http server, CouchDB also uses mochiweb routines for parsing query strings, url encoding, etc. Likewise. Most of the other dependencies are used in the Futon management client. These are small JavaScript libraries, and where I see that individual Erlang libraries should be satisfied externally to CouchDB, I do not think that the same should apply to JavaScript. This is no way of "importing" a library, and no standard way of packaging shared libraries that I am aware of. My thoughts too, thanks for elaborating. To minimize the amount of effort that a user has to perform to satisfy their license issues, I think we should consider modularizing couchdb so that a user who isn't interested in OAuth does not have to research its license, etc. I'd see the parts as: core: The database and non-network core of CouchDB. I would hope this code have no dependencies other than OTP. http: The http server dependent on MochiWeb's http services and core. replicator: dependent on core and ibrowse futon: HTTP admin console oauth: OAuth authenticator, dependent on erlang-oauth Moving our Erlang dependencies out from the source is one thing, but splitting CouchDB into multiple components is entirely another. It makes little sense to modularise the code when each of the modules would be functionally useless in isolation. But moreover, this is orthogonal to the licensing issue. By all means, some degree of modularisation and abstraction of interface might be a good direction for the project to take, but please, let's discuss that as an architectural issue separate to this one. I think we would do well to concentrate on removing the 3rd party Erlang code, or discussing the most palatable way forward, and leave it at that, for the time being. Best, It has helpful conceptually for me to say that, but that comes from a Java/C++ background where compiling against a dependency results in a binary that is then a derivative of the whatever it was compiled against. In that world, if you were linking against an LGPL library to provide some functionality to an ASF framework, you'd do the plugin outside of ASF and license it as LGPL. My understanding of erlc is that the .beam file includes only the import directives, does not need to library present and the resulting file is not a derivative work.
[jira] Created: (COUCHDB-455) get_result,infinity error when replicating an empty database
get_result,infinity error when replicating an empty database
Key: COUCHDB-455
URL: https://issues.apache.org/jira/browse/COUCHDB-455
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.9
Reporter: Enda Farrell
We have code that regularly calls for CouchDB nodes to replicate with pairs in
our other datacentre. It ocassionally has the follwing error:
{code}
INFO bbc.forge.engineering.couchdb.replicatr.ReplicateWorker 371 - Bad
replication: [kv103.back.live.telhc.local:5986/tvp_yahoowidgets <-
kv103.back.live.telhc.local:5986 (ACE_METADATA_)
{"source":"http://kv103.back.live.telhc.local:5986/tvp_yahoowidgets","target":"tvp_yahoowidgets"}]:
response:[HTTP/1.1 500 Internal Server Error -
{"error":"noproc","reason":"{gen_server,call,[<0.17199.212>,get_result,infinity]}"}
{code}
The remote database "http://kv103.back.live.telhc.local:5986/tvp_yahoowidgets";
is empty:
{code}curl http://kv103.back.live.telhc.local:5986/tvp_yahoowidgets
{"db_name":"tvp_yahoowidgets","doc_count":0,"doc_del_count":0,"update_seq":0,"purge_seq":0,"compact_running":false,"disk_size":5920,"instance_start_time":"1249559096646177"}
{code}
This same "get_result,infinity", is seen on another empty database:
{code}
curl http://kv103.back.live.telhc.local:5984/avalanche150k
{"db_name":"avalanche150k","doc_count":0,"doc_del_count":0,"update_seq":0,"purge_seq":0,"compact_running":false,"disk_size":250480,"instance_start_time":"1249559230162131"}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Help required with Debian CouchDB package
Hi Noah, On 08/05/2009 10:38 PM, Noah Slater wrote: I've been maintaining the Debian package of CouchDB for a while now: http://packages.debian.org/sid/couchdb Many thanks for your work on Debian and CouchDB so far, it's been a huge help in allowing me and others (including the communities of all Debian derivatives) to make use of CouchDB easily. I don't have the free time to devote to my work with Debian at the moment, and I'm looking to hand my packages over for team maintenance in the interim. For CouchDB, that means giving it to the Erlang team. I was wondering if there were any folk on our lists who would be interested in helping out? I see Jim and Sam have responded also, wonderful! I saw that the Debian Erlang packagers team was just you and one other persion, so I have just joined the Erlang team mailing list and volunteered to help with Erlang packages generally. I'm not yet a Debian Developer, but would like to earn that role. CouchDB 0.9.1 has not been package yet, so that would be the first task. I will have time to work on this specific task tomorrow while I am in the airport. Sam, Jim, have you already started on this? If so I would be happy to review any work you have done. If not, I'm happy to prepare the package or to help test the package if you prefer to create it. Noah, I know that in Ubuntu we had made some permissions changes in the packaging for couchdb to enable per-user couchdb instances to be started in Ubuntu. Are there other changes that you know are pending for the package? Does preparing the 0.9.1 release involve anything else other than the normal process for generating a source package for a new upstream release? Once I have a source package that I have been able to build in a pbuilder and test, what is the process for getting a sponsor to upload to debian? I really really appreciate you handing over package maintenance in such an organized way, and I hope that this allows you more time to focus on your other valuable work. cheers, -elliot
[jira] Commented: (COUCHDB-449) Turn off delayed commits by default
[
https://issues.apache.org/jira/browse/COUCHDB-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739942#action_12739942
]
Brian Candler commented on COUCHDB-449:
---
Just to be clear: _changes is supposed only to update after a commit has
taken place, not after a write?
If so, I cannot demonstrate it. If I write a document and then immediately
read _changes, it always appears. See below at (*).
Furthermore, the same is true if I run
$ curl http://127.0.0.1:5984/test/_changes?feed=continuous
in another window. As soon as I add a document in the first window, it
appears in the _changes feed.
My very rough scan of the source suggests that a delayed commit should take
place after 1 second:
Delay and (Db#db.waiting_delayed_commit == nil) ->
Db#db{waiting_delayed_commit=
erlang:send_after(1000, self(), delayed_commit)};
So if that's right, and what you say is true, then I would expect not to see
the document in _changes for this long.
OTOH, with batch=ok the commit is delayed indefinitely. I have raised this
as a separate ticket COUCHDB-454)
All tested with HEAD (git commit aebdb31001126dab6b579b8cc2e605ef7ec499c6)
and 12b5 under Jaunty.
Regards,
Brian.
(*)
$ curl -X DELETE http://127.0.0.1:5984/test
{"ok":true}
$ curl -X PUT http://127.0.0.1:5984/test
{"ok":true}
$ curl http://127.0.0.1:5984/test/_changes
{"results":[
],
"last_seq":0}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"70708dcbc2977b759365f9731f27","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":1}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"1d4596c1cb715c0da9f99980fea0a3a2","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":2}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"a2feeaaca391446bb7a0f24c359ff79e","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":3,"id":"a2feeaaca391446bb7a0f24c359ff79e","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":3}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl -X POST -d'{}'
http://127.0.0.1:5984/test; curl -X POST -d'{}' http://127.0.0.1:5984/test;
curl http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"a2262a5904690aec5c64bb61f44903ed","rev":"1-967a00dff5e02add41819138abb3284d"}
{"ok":true,"id":"26fdac7e139531e0f4352a089d4db7f4","rev":"1-967a00dff5e02add41819138abb3284d"}
{"ok":true,"id":"f6bb36540484788becd54391dbc6189b","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":3,"id":"a2feeaaca391446bb7a0f24c359ff79e","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":4,"id":"a2262a5904690aec5c64bb61f44903ed","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":5,"id":"26fdac7e139531e0f4352a089d4db7f4","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":6,"id":"f6bb36540484788becd54391dbc6189b","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":6}
> Turn off delayed commits by default
> ---
>
> Key: COUCHDB-449
> URL: https://issues.apache.org/jira/browse/COUCHDB-449
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.9, 0.9.1
>Reporter: Jan Lehnardt
>Priority: Blocker
> Fix For: 0.10
>
>
> Delayed commits make CouchDB significantly faster. They also open a one
> second window for data loss. In 0.9 and trunk, delayed commits are enabled by
> default and can be overridden with HTTP headers and an explicit API call to
> flush the write buffer. I suggest to turn off delayed commits by default and
> use the same overrides to enable it per request. A per-database option is
> possible, too.
> One concern is developer workflow speed. The setting affects the test suite
> performance significantly. I'd opt to change couch.js to set the appropriate
> header to enable delayed commits for tests.
> CouchDB should guarantee data s
Re: [jira] Commented: (COUCHDB-449) Turn off delayed commits by default
On Wed, Aug 05, 2009 at 05:38:15AM -0700, Jan Lehnardt (JIRA) wrote:
> The "just write and let me know when things have been committed" can be done
> with the _changes feed already. No need for a separate sequence id.
Just to be clear: _changes is supposed only to update after a commit has
taken place, not after a write?
If so, I cannot demonstrate it. If I write a document and then immediately
read _changes, it always appears. See below at (*).
Furthermore, the same is true if I run
$ curl http://127.0.0.1:5984/test/_changes?feed=continuous
in another window. As soon as I add a document in the first window, it
appears in the _changes feed.
My very rough scan of the source suggests that a delayed commit should take
place after 1 second:
Delay and (Db#db.waiting_delayed_commit == nil) ->
Db#db{waiting_delayed_commit=
erlang:send_after(1000, self(), delayed_commit)};
So if that's right, and what you say is true, then I would expect not to see
the document in _changes for this long.
OTOH, with batch=ok the commit is delayed indefinitely. I have raised this
as a separate ticket COUCHDB-454)
All tested with HEAD (git commit aebdb31001126dab6b579b8cc2e605ef7ec499c6)
and 12b5 under Jaunty.
Regards,
Brian.
(*)
$ curl -X DELETE http://127.0.0.1:5984/test
{"ok":true}
$ curl -X PUT http://127.0.0.1:5984/test
{"ok":true}
$ curl http://127.0.0.1:5984/test/_changes
{"results":[
],
"last_seq":0}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"70708dcbc2977b759365f9731f27","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":1}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"1d4596c1cb715c0da9f99980fea0a3a2","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":2}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl
http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"a2feeaaca391446bb7a0f24c359ff79e","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":3,"id":"a2feeaaca391446bb7a0f24c359ff79e","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":3}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test; curl -X POST -d'{}'
http://127.0.0.1:5984/test; curl -X POST -d'{}' http://127.0.0.1:5984/test;
curl http://127.0.0.1:5984/test/_changes
{"ok":true,"id":"a2262a5904690aec5c64bb61f44903ed","rev":"1-967a00dff5e02add41819138abb3284d"}
{"ok":true,"id":"26fdac7e139531e0f4352a089d4db7f4","rev":"1-967a00dff5e02add41819138abb3284d"}
{"ok":true,"id":"f6bb36540484788becd54391dbc6189b","rev":"1-967a00dff5e02add41819138abb3284d"}
{"results":[
{"seq":1,"id":"70708dcbc2977b759365f9731f27","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":2,"id":"1d4596c1cb715c0da9f99980fea0a3a2","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":3,"id":"a2feeaaca391446bb7a0f24c359ff79e","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":4,"id":"a2262a5904690aec5c64bb61f44903ed","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":5,"id":"26fdac7e139531e0f4352a089d4db7f4","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]},
{"seq":6,"id":"f6bb36540484788becd54391dbc6189b","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":6}
[jira] Created: (COUCHDB-454) batch=ok buffers indefinitely
batch=ok buffers indefinitely
-
Key: COUCHDB-454
URL: https://issues.apache.org/jira/browse/COUCHDB-454
Project: CouchDB
Issue Type: Bug
Components: Database Core
Environment: CouchDB HEAD (commit commit
aebdb31001126dab6b579b8cc2e605ef7ec499c6)
Ubuntu Jaunty, Erlang 12B5
Reporter: Brian Candler
It appears that documents written with batch=ok are buffered indefinitely. They
don't appear in the _changes feed, nor in _all_docs, until you POST to
_ensure_full_commit. This is despite me running with standard default.ini which
has batch_save_interval=1000 (milliseconds)
$ curl -X DELETE http://127.0.0.1:5984/test
{"ok":true}
$ curl -X PUT http://127.0.0.1:5984/test
{"ok":true}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test
{"ok":true,"id":"1b1337e31c4d9b41119d51db78ffebe3","rev":"1-967a00dff5e02add41819138abb3284d"}
$ curl http://127.0.0.1:5984/test/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
]}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
{"ok":true,"id":"ba37caf17a24236d243e9ab2c4c6daff"}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
{"ok":true,"id":"e5d8bb7c74ca3cca4aabea8107620fad"}
$ curl -X POST -d'{}' http://127.0.0.1:5984/test?batch=ok
{"ok":true,"id":"9bb2fb958f9112d79b4f388514c0ba7c"}
$ curl http://127.0.0.1:5984/test/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
]}
$ sleep 60
$ curl http://127.0.0.1:5984/test/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
]}
$ curl -X POST http://127.0.0.1:5984/test/_ensure_full_commit
{"ok":true,"instance_start_time":"1249546668867264"}
$ curl http://127.0.0.1:5984/test/_all_docs
{"total_rows":4,"offset":0,"rows":[
{"id":"1b1337e31c4d9b41119d51db78ffebe3","key":"1b1337e31c4d9b41119d51db78ffebe3","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
{"id":"9bb2fb958f9112d79b4f388514c0ba7c","key":"9bb2fb958f9112d79b4f388514c0ba7c","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
{"id":"ba37caf17a24236d243e9ab2c4c6daff","key":"ba37caf17a24236d243e9ab2c4c6daff","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}},
{"id":"e5d8bb7c74ca3cca4aabea8107620fad","key":"e5d8bb7c74ca3cca4aabea8107620fad","value":{"rev":"1-967a00dff5e02add41819138abb3284d"}}
]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: What's your Erlang VM version?
On Thu, Aug 6, 2009 at 09:56, Brian Candler 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: What's your Erlang VM version?
FYI, winding back to c0777a52d73ff0c604937a3608dcef3b9862ecd5 and eveything works again, test suite included. My other boxes run Jaunty which has 12b5, so I wouldn't actually object if that were made the minimum. Regards, Brian.
Re: What's your Erlang VM version?
On Wed, Aug 05, 2009 at 07:16:42PM -0400, Paul Davis wrote:
> Anyone care to svn up and
> try building CouchDB on an Erlang VM that before R12B5?
- Ubuntu Hardy with erlang 12b3 from Intrepid (1:12.b.3-dfsg-1ubuntu1) (*)
- git HEAD aebdb31001126dab6b579b8cc2e605ef7ec499c6 (**)
- Builds and installs without errors
- But drops HTTP connections on the floor :-(
$ telnet localhost 5984
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
Connection closed by foreign host.
$
- To me the backtrace suggests a problem with re:split, but it mentions
oauth in the same breath
[Thu, 06 Aug 2009 07:40:27 GMT] [error] [<0.104.0>] {error_report,<0.22.0>,
{<0.104.0>,crash_report,
[[{pid,<0.104.0>},
{registered_name,[]},
{error_info,
{error,undef,
[{re,split,
["{couch_httpd_oauth, oauth_authentication_handler},
{couch_httpd_auth, default_authentication_handler}",
"(?<=})\\s*,\\s*(?={)",
[{return,list}]]},
{couch_httpd,make_arity_1_fun_list,1},
{couch_httpd,handle_request,5},
{mochiweb_http,headers,5},
{proc_lib,init_p,5}]}},
{initial_call,
{mochiweb_socket_server,acceptor_loop,
[{<0.56.0>,#Port<0.155>,#Fun}]}},
{ancestors,
[couch_httpd,couch_secondary_services,couch_server_sup,
<0.1.0>]},
{messages,[]},
{links,[<0.56.0>,#Port<0.170>]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,2584},
{stack_size,23},
{reductions,572}],
[]]}}
[Thu, 06 Aug 2009 07:40:27 GMT] [error] [<0.56.0>] {error_report,<0.22.0>,
{<0.56.0>,std_error,
{mochiweb_socket_server,235,{child_error,undef
Regards,
Brian.
(*)
$ dpkg --status erlang
Package: erlang
Status: install ok installed
Priority: optional
Section: interpreters
Installed-Size: 80
Maintainer: Ubuntu MOTU Developers
Architecture: all
Version: 1:12.b.3-dfsg-1ubuntu1
Depends: erlang-base | erlang-base-hipe, erlang-nox, erlang-x11, erlang-dev
Recommends: erlang-src, erlang-examples, erlang-mode
Suggests: erlang-manpages, erlang-doc-html
Description: Concurrent, real-time, distributed functional language
Open Source Erlang is a functional programming language designed at
the Ericsson Computer Science Laboratory.
.
Some of Erlang main features are:
Clear declarative syntax and is largely free from side-effects;
Builtin support for real-time, concurrent and distributed programming;
Designed for development of robust and continously operated programs;
Dynamic code replacement at runtime.
.
This package will install erlang runtime, librarires, sources, code
examples and the Erlang editing mode for Emacs.
Homepage: http://www.erlang.org/
Original-Maintainer: Erlang Packagers
(**)
commit aebdb31001126dab6b579b8cc2e605ef7ec499c6
Author: davisp
Date: Wed Aug 5 23:08:25 2009 +
The RSA SHA1 Oauth module was breaking trunk for older versions of the
Erlang
VM. Since we don't actually use it, I'm removing it from the build until
we add a ./conifgure option or we update our Erlang version requirement.
git-svn-id: http://svn.apache.org/repos/asf/couchdb/tr...@801456
13f79535-47bb-0310-9956-ffa450edef68
