Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
I wish we could do something about the spam. I don't like playing whackamole.
Re: svn commit: r1133561 - /couchdb/trunk/src/couchdb/couch_replicator.erl
Randall, I disagree with this change.
While it's ok for local databases, it causes noise for remote
databases, as the httpc pool is linked to the main replication
gen_server and it starts receiving EXIT messages from the later when
it finishes normally (without errors).
Look at the following gist, provided by Robert Dionne:
https://gist.github.com/1022516
This is making the replication.js test failing for a few folks at
least (Robert, Jan for e.g.)
I would suggest instead this patch:
http://friendpaste.com/2VZvViEvWugHt4TmHFep0M
On Wed, Jun 8, 2011 at 10:30 PM, rand...@apache.org wrote:
Author: randall
Date: Wed Jun 8 21:30:03 2011
New Revision: 1133561
URL: http://svn.apache.org/viewvc?rev=1133561view=rev
Log:
let dbs be closed implicitly when replication dies
We have the supervision tree and monitoring set up with ref counter.
There's really no need to call close here and it generates log noise
when a user DELETEs a local DB involved in replication unless we track
what happened and doing some nil-ing or special casing. Just letting it
all be implicit seems easiest. Closes COUCHDB-863.
Modified:
couchdb/trunk/src/couchdb/couch_replicator.erl
Modified: couchdb/trunk/src/couchdb/couch_replicator.erl
URL:
http://svn.apache.org/viewvc/couchdb/trunk/src/couchdb/couch_replicator.erl?rev=1133561r1=1133560r2=1133561view=diff
==
--- couchdb/trunk/src/couchdb/couch_replicator.erl (original)
+++ couchdb/trunk/src/couchdb/couch_replicator.erl Wed Jun 8 21:30:03 2011
@@ -478,9 +478,7 @@ terminate(Reason, State) -
terminate_cleanup(State) -
couch_task_status:update(Finishing),
stop_db_compaction_notifier(State#rep_state.source_db_compaction_notifier),
-
stop_db_compaction_notifier(State#rep_state.target_db_compaction_notifier),
- couch_api_wrap:db_close(State#rep_state.source),
- couch_api_wrap:db_close(State#rep_state.target).
+
stop_db_compaction_notifier(State#rep_state.target_db_compaction_notifier).
do_last_checkpoint(#rep_state{seqs_in_progress = [],
--
Filipe David Manana,
fdman...@gmail.com, fdman...@apache.org
Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 5:23 AM, Noah Slater nsla...@apache.org wrote: I wish we could do something about the spam. I don't like playing whackamole. We could delete the wiki and create real docs.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 5:34 AM, Paul Davis paul.joseph.da...@gmail.com wrote: On Mon, Jun 13, 2011 at 5:23 AM, Noah Slater nsla...@apache.org wrote: I wish we could do something about the spam. I don't like playing whackamole. We could delete the wiki and create real docs. +1 . something available on the versioning. Maybe right after the git call ? - benoît
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
What percentage of useful wiki edits were made by committers vs non-committers? On 13 Jun 2011, at 13:41, Benoit Chesneau wrote: On Mon, Jun 13, 2011 at 5:34 AM, Paul Davis paul.joseph.da...@gmail.com wrote: On Mon, Jun 13, 2011 at 5:23 AM, Noah Slater nsla...@apache.org wrote: I wish we could do something about the spam. I don't like playing whackamole. We could delete the wiki and create real docs. +1 . something available on the versioning. Maybe right after the git call ? - benoît
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
+1 to deleting the wiki and +1 to real docs. B. On 13 June 2011 13:49, Noah Slater nsla...@apache.org wrote: What percentage of useful wiki edits were made by committers vs non-committers? On 13 Jun 2011, at 13:41, Benoit Chesneau wrote: On Mon, Jun 13, 2011 at 5:34 AM, Paul Davis paul.joseph.da...@gmail.com wrote: On Mon, Jun 13, 2011 at 5:23 AM, Noah Slater nsla...@apache.org wrote: I wish we could do something about the spam. I don't like playing whackamole. We could delete the wiki and create real docs. +1 . something available on the versioning. Maybe right after the git call ? - benoît
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 5:49 AM, Noah Slater nsla...@apache.org wrote: What percentage of useful wiki edits were made by committers vs non-committers? We could have edit from users too or just mails on non wiki systems. For example on gunicorn, The users open a ticket with a correction. Or maybe we could have a wiki also available on the revision system. The good point of having static doc is that we could distribute it with the sources, so I don't rely on any connections to read them or whatever. - benoît
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote: What percentage of useful wiki edits were made by committers vs non-committers? http://en.wikipedia.org/wiki/Toilet_paper_orientation On 13 Jun 2011, at 13:41, Benoit Chesneau wrote: On Mon, Jun 13, 2011 at 5:34 AM, Paul Davis paul.joseph.da...@gmail.com wrote: On Mon, Jun 13, 2011 at 5:23 AM, Noah Slater nsla...@apache.org wrote: I wish we could do something about the spam. I don't like playing whackamole. We could delete the wiki and create real docs. +1 . something available on the versioning. Maybe right after the git call ? - benoît
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On 13 Jun 2011, at 13:55, Paul Davis wrote: On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote: What percentage of useful wiki edits were made by committers vs non-committers? http://en.wikipedia.org/wiki/Toilet_paper_orientation Not sure how this is relevant. If we decommission the wiki we are putting up barriers to contribution from non-committers. So it is arguably worth while understanding exactly what that means for us. How many people have contributed in the past who could not have contributed if this had been the case?
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Jun 13, 2011, at 9:13 AM, Noah Slater wrote: On 13 Jun 2011, at 13:55, Paul Davis wrote: On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote: What percentage of useful wiki edits were made by committers vs non-committers? http://en.wikipedia.org/wiki/Toilet_paper_orientation Not sure how this is relevant. If we decommission the wiki we are putting up barriers to contribution from non-committers. So it is arguably worth while understanding exactly what that means for us. How many people have contributed in the past who could not have contributed if this had been the case? I think the WIKI is useful. The APi docs are pretty good, everything is there, though it takes a while to get used to how to find it all.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 6:18 AM, Robert Dionne dio...@dionne-associates.com wrote: On Jun 13, 2011, at 9:13 AM, Noah Slater wrote: On 13 Jun 2011, at 13:55, Paul Davis wrote: On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote: What percentage of useful wiki edits were made by committers vs non-committers? http://en.wikipedia.org/wiki/Toilet_paper_orientation Not sure how this is relevant. If we decommission the wiki we are putting up barriers to contribution from non-committers. So it is arguably worth while understanding exactly what that means for us. How many people have contributed in the past who could not have contributed if this had been the case? I think the WIKI is useful. The APi docs are pretty good, everything is there, though it takes a while to get used to how to find it all. useful for sure, but it can't be put in in the archive doc folder though. (I know... we don't have even a doc folder in the archive...) - benoît
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 9:13 AM, Noah Slater nsla...@apache.org wrote: On 13 Jun 2011, at 13:55, Paul Davis wrote: On Mon, Jun 13, 2011 at 8:49 AM, Noah Slater nsla...@apache.org wrote: What percentage of useful wiki edits were made by committers vs non-committers? http://en.wikipedia.org/wiki/Toilet_paper_orientation Not sure how this is relevant. If we decommission the wiki we are putting up barriers to contribution from non-committers. So it is arguably worth while understanding exactly what that means for us. How many people have contributed in the past who could not have contributed if this had been the case? The mode of contribution changes. There is nothing that will suddenly prevent people from contributing. Its just that making a contribution becomes a JIRA issue instead of a wiki update. Under that light your question becomes, How many people contributed to the wiki that couldn't manage to fill out a JIRA issue? The only way to truly understand what it'd be like to use the new system would be to build it and start using it in preference to the wiki. If it dies a gruesome death, then the wiki won. If not then eventually we'll say Oh look, the wiki still sucks and we have all of this glorious, glorious documentation. How fabulous! And then we will drink tea from small cups on saucers with an appropriately extended pinky finger and a monocle. http://en.wikipedia.org/wiki/Talk:Barack_Obama#Mention_of_conspiracy_theories_in_the_article.3F
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 15:31, Paul Davis paul.joseph.da...@gmail.com wrote: The mode of contribution changes. There is nothing that will suddenly prevent people from contributing. Its just that making a contribution becomes a JIRA issue instead of a wiki update. Under that light your question becomes, How many people contributed to the wiki that couldn't manage to fill out a JIRA issue? Wouldn't or couldn't? Cheers, Dirkjan
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
How many people didn't edit the wiki because it's a scary prospect to edit the only form of documentation that there seems to be? +1 to pinky fingers and monocles Thanks Clare On 13/06/11 15:15, Dirkjan Ochtman wrote: On Mon, Jun 13, 2011 at 15:31, Paul Davispaul.joseph.da...@gmail.com wrote: The mode of contribution changes. There is nothing that will suddenly prevent people from contributing. Its just that making a contribution becomes a JIRA issue instead of a wiki update. Under that light your question becomes, How many people contributed to the wiki that couldn't manage to fill out a JIRA issue? Wouldn't or couldn't? Cheers, Dirkjan
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
It's not the wiki per se that bothers me, it's that it's the primary, often only, source of documentation. I propose that future releases of CouchDB include at least a full description of all public API's. Improvements above that base level would be a manual and/or simple tutorials. This documentation would be maintained in the same source tree as the code and it would be a release requirement for this documentation to be updated to include all new features. This documentation is then the primary source, the wiki can serve as a supplement. b. On 13 June 2011 18:16, Peter Nolan peterwno...@gmail.com wrote: Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson robert.new...@gmail.com wrote: It's not the wiki per se that bothers me, it's that it's the primary, often only, source of documentation. I propose that future releases of CouchDB include at least a full description of all public API's. Improvements above that base level would be a manual and/or simple tutorials. This documentation would be maintained in the same source tree as the code and it would be a release requirement for this documentation to be updated to include all new features. You had me until you said release requirement. I would upgrade that to commit requirement if we're seriously about having such documentation. If we don't force people to make sure docs reflect changes at commit time then its probably going to be a lost cause. This documentation is then the primary source, the wiki can serve as a supplement. b. On 13 June 2011 18:16, Peter Nolan peterwno...@gmail.com wrote: Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On 13 Jun 2011, at 18:16, Peter Nolan wrote: What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) Because we nuke it as it arrives. That's what prompted my original email. But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. I am one, and I'm sick of doing it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. They are. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. Not gonna happen. It's MoinMoin or Confluence. :)
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On 13 Jun 2011, at 19:08, Paul Davis wrote: You had me until you said release requirement. I would upgrade that to commit requirement if we're seriously about having such documentation. If we don't force people to make sure docs reflect changes at commit time then its probably going to be a lost cause. Paul is right on the money here. The release team already has enough work to do without rounding up documentation. ;)
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
++1 On Jun 13, 2011, at 2:05 PM, Robert Newson wrote: It's not the wiki per se that bothers me, it's that it's the primary, often only, source of documentation. I propose that future releases of CouchDB include at least a full description of all public API's. Improvements above that base level would be a manual and/or simple tutorials. This documentation would be maintained in the same source tree as the code and it would be a release requirement for this documentation to be updated to include all new features. This documentation is then the primary source, the wiki can serve as a supplement. b. On 13 June 2011 18:16, Peter Nolan peterwno...@gmail.com wrote: Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
++1++ On Jun 13, 2011, at 2:08 PM, Paul Davis wrote: On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson robert.new...@gmail.com wrote: It's not the wiki per se that bothers me, it's that it's the primary, often only, source of documentation. I propose that future releases of CouchDB include at least a full description of all public API's. Improvements above that base level would be a manual and/or simple tutorials. This documentation would be maintained in the same source tree as the code and it would be a release requirement for this documentation to be updated to include all new features. You had me until you said release requirement. I would upgrade that to commit requirement if we're seriously about having such documentation. If we don't force people to make sure docs reflect changes at commit time then its probably going to be a lost cause. This documentation is then the primary source, the wiki can serve as a supplement. b. On 13 June 2011 18:16, Peter Nolan peterwno...@gmail.com wrote: Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
+1 for commit requirement in addition to being a release requirement. At the very least, we get the docs fixed during the release process, but it ought to be done with the commit itself. In practice, we'll forget sometimes, and then be reminded by others on the team. B. On 13 June 2011 19:17, Robert Dionne dio...@dionne-associates.com wrote: ++1++ On Jun 13, 2011, at 2:08 PM, Paul Davis wrote: On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson robert.new...@gmail.com wrote: It's not the wiki per se that bothers me, it's that it's the primary, often only, source of documentation. I propose that future releases of CouchDB include at least a full description of all public API's. Improvements above that base level would be a manual and/or simple tutorials. This documentation would be maintained in the same source tree as the code and it would be a release requirement for this documentation to be updated to include all new features. You had me until you said release requirement. I would upgrade that to commit requirement if we're seriously about having such documentation. If we don't force people to make sure docs reflect changes at commit time then its probably going to be a lost cause. This documentation is then the primary source, the wiki can serve as a supplement. b. On 13 June 2011 18:16, Peter Nolan peterwno...@gmail.com wrote: Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
Didn't couch/couchone/couchbase/whateveritscalledthisweek hire a writer? If you need a writer for documentation I'm more than willing to contribute. Eye dun rite gud.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
On Mon, Jun 13, 2011 at 2:27 PM, Robert Newson robert.new...@gmail.com wrote: +1 for commit requirement in addition to being a release requirement. At the very least, we get the docs fixed during the release process, but it ought to be done with the commit itself. In practice, we'll forget sometimes, and then be reminded by others on the team. Right. I'm saying reminded by others should be commit vetoed. B. On 13 June 2011 19:17, Robert Dionne dio...@dionne-associates.com wrote: ++1++ On Jun 13, 2011, at 2:08 PM, Paul Davis wrote: On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson robert.new...@gmail.com wrote: It's not the wiki per se that bothers me, it's that it's the primary, often only, source of documentation. I propose that future releases of CouchDB include at least a full description of all public API's. Improvements above that base level would be a manual and/or simple tutorials. This documentation would be maintained in the same source tree as the code and it would be a release requirement for this documentation to be updated to include all new features. You had me until you said release requirement. I would upgrade that to commit requirement if we're seriously about having such documentation. If we don't force people to make sure docs reflect changes at commit time then its probably going to be a lost cause. This documentation is then the primary source, the wiki can serve as a supplement. b. On 13 June 2011 18:16, Peter Nolan peterwno...@gmail.com wrote: Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
Also we should jab them with forks. On 13 June 2011 19:28, Paul Davis paul.joseph.da...@gmail.com wrote: On Mon, Jun 13, 2011 at 2:27 PM, Robert Newson robert.new...@gmail.com wrote: +1 for commit requirement in addition to being a release requirement. At the very least, we get the docs fixed during the release process, but it ought to be done with the commit itself. In practice, we'll forget sometimes, and then be reminded by others on the team. Right. I'm saying reminded by others should be commit vetoed. B. On 13 June 2011 19:17, Robert Dionne dio...@dionne-associates.com wrote: ++1++ On Jun 13, 2011, at 2:08 PM, Paul Davis wrote: On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson robert.new...@gmail.com wrote: It's not the wiki per se that bothers me, it's that it's the primary, often only, source of documentation. I propose that future releases of CouchDB include at least a full description of all public API's. Improvements above that base level would be a manual and/or simple tutorials. This documentation would be maintained in the same source tree as the code and it would be a release requirement for this documentation to be updated to include all new features. You had me until you said release requirement. I would upgrade that to commit requirement if we're seriously about having such documentation. If we don't force people to make sure docs reflect changes at commit time then its probably going to be a lost cause. This documentation is then the primary source, the wiki can serve as a supplement. b. On 13 June 2011 18:16, Peter Nolan peterwno...@gmail.com wrote: Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
Yes, Peter, there is better documentation available for couchdb outside of our the projects official site. That's part of the problem we're addressing. The best place for couchdb documentation should be couchdb.apache.org, like it is for most other Apache projects. B. On 13 June 2011 19:30, Robert Newson robert.new...@gmail.com wrote: Also we should jab them with forks. On 13 June 2011 19:28, Paul Davis paul.joseph.da...@gmail.com wrote: On Mon, Jun 13, 2011 at 2:27 PM, Robert Newson robert.new...@gmail.com wrote: +1 for commit requirement in addition to being a release requirement. At the very least, we get the docs fixed during the release process, but it ought to be done with the commit itself. In practice, we'll forget sometimes, and then be reminded by others on the team. Right. I'm saying reminded by others should be commit vetoed. B. On 13 June 2011 19:17, Robert Dionne dio...@dionne-associates.com wrote: ++1++ On Jun 13, 2011, at 2:08 PM, Paul Davis wrote: On Mon, Jun 13, 2011 at 2:05 PM, Robert Newson robert.new...@gmail.com wrote: It's not the wiki per se that bothers me, it's that it's the primary, often only, source of documentation. I propose that future releases of CouchDB include at least a full description of all public API's. Improvements above that base level would be a manual and/or simple tutorials. This documentation would be maintained in the same source tree as the code and it would be a release requirement for this documentation to be updated to include all new features. You had me until you said release requirement. I would upgrade that to commit requirement if we're seriously about having such documentation. If we don't force people to make sure docs reflect changes at commit time then its probably going to be a lost cause. This documentation is then the primary source, the wiki can serve as a supplement. b. On 13 June 2011 18:16, Peter Nolan peterwno...@gmail.com wrote: Any documentation is good. What is this 'spam'? Haven't personally encountered anything on the wiki that would be 'considered' spam (perhaps not stumbled upon that portion?) But it's inevitable that the wiki will be attacked by unscrupulous people and as such, the wiki should prepare for this. The wiki is going to need gatekeepers/admins to maintain it. It would be nice, that any edits be archived so users can see previous states of the page if they so choose so. If a noted jerk keeps editing the wiki, we should have a system that only applies his edits to his account. The common user would not see his edits, only he would, which would hopefully convince him that his edit has gone through. +1 top hats.
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
It doesn't matter where the 'centralized' information is located, it just needs to be centralized. There are a bunch of great little bits of information scattered throughout the internet, from blogs, to stackoverflow etc. Out of curiosity, how hard is it to create plugins for firefox? If one wanted to create a plugin that allowed users to upload urls of useful information to the couchdb wiki, how long would it take them? Assuming they know js, couch, html and css only. That'd be a nice little project to put on the back burner. -Pete
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
I'd argue that it matters a great deal. Our project should include good documentation. B. On 13 June 2011 19:46, Peter Nolan peterwno...@gmail.com wrote: It doesn't matter where the 'centralized' information is located, it just needs to be centralized. There are a bunch of great little bits of information scattered throughout the internet, from blogs, to stackoverflow etc. Out of curiosity, how hard is it to create plugins for firefox? If one wanted to create a plugin that allowed users to upload urls of useful information to the couchdb wiki, how long would it take them? Assuming they know js, couch, html and css only. That'd be a nice little project to put on the back burner. -Pete
Re: [Couchdb Wiki] Trivial Update of CouchDB_in_the_wild by wentforgold
The point that was trying to be made was that a database system that allows such an extreme degree of decentralization (with replication and whatnot) is that information is incredibly decentralized. Having a location that contains all necessary documentation is incredibly important.
[jira] [Updated] (COUCHDB-994) Crash after compacting large views
[ https://issues.apache.org/jira/browse/COUCHDB-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Kögl updated COUCHDB-994: Attachment: 2011-06-13-couchdb.log I've applied the patch from http://svn.apache.org/viewvc?view=revisionrevision=1104168 onto CouchDB 1.1.0 and tried to compact again. The result was that the compaction finnishes, an error is reported in the log (2011-06-13-couchdb.log) and the .view files are not replaced with their corresponding .compact.view files. Crash after compacting large views -- Key: COUCHDB-994 URL: https://issues.apache.org/jira/browse/COUCHDB-994 Project: CouchDB Issue Type: Bug Affects Versions: 1.0.2 Environment: Centos5 64bit vm with 2CPU and 4G RAM running Erlang R14B and configured to use the 64bit js-devel libraries. URL: http://svn.apache.org/repos/asf/couchdb/branches/1.0.x Repository Root: http://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1050680 Reporter: Bob Clary Fix For: 1.2 Attachments: 2011-06-11-couchdb.log, 2011-06-13-couchdb.log, couch_errors.txt, couch_errors_2.txt The database has over 9 million records. Several of the views are relatively dense in that they emit a key for most documents. The views are successfully created initially but with relatively large sizes from 20 to 95G. When attempting to compact them, the server will crash upon completion of the compaction. This does not occur with the released 1.0.1 version but does with the 1.0.x svn version. I'll attach example logs. Unfortunately they are level error and may not have enough information. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: make error with latest trunk (ICU related autotools config)
On Mon, Jun 13, 2011 at 06:27, Filipe David Manana fdman...@apache.org wrote:
On Sun, Jun 12, 2011 at 9:46 PM, Randall Leeds randall.le...@gmail.com
wrote:
Looks like /usr/local/include and /usr/include are absent from the new
stuff. Can you confirm that those headers are in one of those places?
Yep:
$ sudo find / -name 'ucol.h'
Password:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory
/opt/local/include/unicode/ucol.h
/opt/local/var/macports/software/icu/4.3.4_0/opt/local/include/unicode/ucol.h
I bet it's a difference in default search paths, else I can't explain why
this works on linux :).
Anyone know what best practices are? Should we toss /usr/include,
${PREFIX}/include others?? .. into CPPFLAGS always?
Next time I make big autotools changes ill solicit more feedback on the
branch before I put it on trunk.
I restored the default include paths we used to run with in r1135302.
But I'm glad to endure this pain. It's really uncovered a lot of
places where corners were cut on getting the minimal set of correct
flags to each build step by just slapping everything everywhere.
I still need confirmation from dch on the openssl linking for windows,
but otherwise everything seem straightened out to people?
Any more build failures please let me know asap.
Agreed.
On Jun 12, 2011 4:07 PM, Filipe David Manana fdman...@apache.org wrote:
Hi all,
After all the recent changes in the autotools config, I'm able to
build trunk on Linux, however I'm no longer able to do it on a 32bits
Mac OS X (snow leopard). It seems the include path is not what it used
to be. The relevant `make`/`make dev` output:
/bin/sh ../../../libtool --tag=CC --mode=compile gcc
-DHAVE_CONFIG_H -I. -I../../../../src/couchdb/priv -I../../..
-I../../../src/snappy/google-snappy -O2 -O2 -Wall -ansi -pedantic
-Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings
-Wno-long-long \c
-I/Users/fdmanana/tmp/couchdb/apache-couchdb-1.2.0a-0d27a97-git/_inst/lib/erlang/usr/include
-I/usr/lib/erlang/usr/include -I/usr/local/lib/erlang/usr/include
-I/opt/local/lib/erlang/usr/include -MT
couch_icu_driver_la-couch_icu_driver.lo -MD -MP -MF
.deps/couch_icu_driver_la-couch_icu_driver.Tpo -c -o
couch_icu_driver_la-couch_icu_driver.lo `test -f
'icu_driver/couch_icu_driver.c' || echo
'../../../../src/couchdb/priv/'`icu_driver/couch_icu_driver.c
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I../../../../src/couchdb/priv -I../../..
-I../../../src/snappy/google-snappy -O2 -O2 -Wall -ansi -pedantic
-Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings
-Wno-long-long c
-I/Users/fdmanana/tmp/couchdb/apache-couchdb-1.2.0a-0d27a97-git/_inst/lib/erlang/usr/include
-I/usr/lib/erlang/usr/include -I/usr/local/lib/erlang/usr/include
-I/opt/local/lib/erlang/usr/include -MT
couch_icu_driver_la-couch_icu_driver.lo -MD -MP -MF
.deps/couch_icu_driver_la-couch_icu_driver.Tpo -c
../../../../src/couchdb/priv/icu_driver/couch_icu_driver.c
-fno-common -DPIC -o .libs/couch_icu_driver_la-couch_icu_driver.o
i686-apple-darwin10-gcc-4.2.1: c: No such file or directory
../../../../src/couchdb/priv/icu_driver/couch_icu_driver.c:27:26:
error: unicode/ucol.h: No such file or directory
../../../../src/couchdb/priv/icu_driver/couch_icu_driver.c:28:30:
error: unicode/ucasemap.h: No such file or directory
With trunk revision 1132947 (and before), on this same machine,
couch_icu_driver compiles just fine. Relevant make output:
/bin/sh ../../../libtool --tag=CC --mode=compile gcc
-DHAVE_CONFIG_H -I. -I../../.. -I../../../src/snappy/google-snappy
-L/usr/local/lib -L/opt/local/lib -I/opt/otp14/lib/erlang/usr/include
-I/usr/include -I/usr/include/js -I/usr/include/mozjs
-I/usr/local/include -I/opt/local/include -I/usr/local/include/js
-I/opt/local/include/js -DXP_UNIX -I/opt/local/include\c
-L/opt/local/lib\c -g -O2 -MT couch_icu_driver_la-couch_icu_driver.lo
-MD -MP -MF .deps/couch_icu_driver_la-couch_icu_driver.Tpo -c -o
couch_icu_driver_la-couch_icu_driver.lo `test -f
'icu_driver/couch_icu_driver.c' || echo
'./'`icu_driver/couch_icu_driver.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../..
-I../../../src/snappy/google-snappy -L/usr/local/lib -L/opt/local/lib
-I/opt/otp14/lib/erlang/usr/include -I/usr/include -I/usr/include/js
-I/usr/include/mozjs -I/usr/local/include -I/opt/local/include
-I/usr/local/include/js -I/opt/local/include/js -DXP_UNIX
-I/opt/local/includec -L/opt/local/libc -g -O2 -MT
couch_icu_driver_la-couch_icu_driver.lo -MD -MP -MF
.deps/couch_icu_driver_la-couch_icu_driver.Tpo -c
icu_driver/couch_icu_driver.c -fno-common -DPIC -o
.libs/couch_icu_driver_la-couch_icu_driver.o
mv -f .deps/couch_icu_driver_la-couch_icu_driver.Tpo
.deps/couch_icu_driver_la-couch_icu_driver.Plo
/bin/sh ../../../libtool --tag=CC --mode=link gcc
-I/opt/local/include\c -L/opt/local/lib\c -g -O2 -module
-avoid-version -I/opt/local/include\c -L/opt/local/lib\c
-L/usr/local/lib
Re: make error with latest trunk (ICU related autotools config)
On Sun, Jun 12, 2011 at 4:46 PM, Randall Leeds randall.le...@gmail.com wrote:
Looks like /usr/local/include and /usr/include are absent from the new
stuff. Can you confirm that those headers are in one of those places?
I bet it's a difference in default search paths, else I can't explain why
this works on linux :).
Anyone know what best practices are? Should we toss /usr/include,
${PREFIX}/include others?? .. into CPPFLAGS always?
Next time I make big autotools changes ill solicit more feedback on the
branch before I put it on trunk.
I would actually argue that you shouldn't bother. The build system is
always a little peculiar because no one has access to the large number
of configuration combinations that users have. As long as you don't
make a habit of continually breaking it I don't think its a huge deal.
On Jun 12, 2011 4:07 PM, Filipe David Manana fdman...@apache.org wrote:
Hi all,
After all the recent changes in the autotools config, I'm able to
build trunk on Linux, however I'm no longer able to do it on a 32bits
Mac OS X (snow leopard). It seems the include path is not what it used
to be. The relevant `make`/`make dev` output:
/bin/sh ../../../libtool --tag=CC --mode=compile gcc
-DHAVE_CONFIG_H -I. -I../../../../src/couchdb/priv -I../../..
-I../../../src/snappy/google-snappy -O2 -O2 -Wall -ansi -pedantic
-Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings
-Wno-long-long \c
-I/Users/fdmanana/tmp/couchdb/apache-couchdb-1.2.0a-0d27a97-git/_inst/lib/erlang/usr/include
-I/usr/lib/erlang/usr/include -I/usr/local/lib/erlang/usr/include
-I/opt/local/lib/erlang/usr/include -MT
couch_icu_driver_la-couch_icu_driver.lo -MD -MP -MF
.deps/couch_icu_driver_la-couch_icu_driver.Tpo -c -o
couch_icu_driver_la-couch_icu_driver.lo `test -f
'icu_driver/couch_icu_driver.c' || echo
'../../../../src/couchdb/priv/'`icu_driver/couch_icu_driver.c
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I../../../../src/couchdb/priv -I../../..
-I../../../src/snappy/google-snappy -O2 -O2 -Wall -ansi -pedantic
-Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings
-Wno-long-long c
-I/Users/fdmanana/tmp/couchdb/apache-couchdb-1.2.0a-0d27a97-git/_inst/lib/erlang/usr/include
-I/usr/lib/erlang/usr/include -I/usr/local/lib/erlang/usr/include
-I/opt/local/lib/erlang/usr/include -MT
couch_icu_driver_la-couch_icu_driver.lo -MD -MP -MF
.deps/couch_icu_driver_la-couch_icu_driver.Tpo -c
../../../../src/couchdb/priv/icu_driver/couch_icu_driver.c
-fno-common -DPIC -o .libs/couch_icu_driver_la-couch_icu_driver.o
i686-apple-darwin10-gcc-4.2.1: c: No such file or directory
../../../../src/couchdb/priv/icu_driver/couch_icu_driver.c:27:26:
error: unicode/ucol.h: No such file or directory
../../../../src/couchdb/priv/icu_driver/couch_icu_driver.c:28:30:
error: unicode/ucasemap.h: No such file or directory
With trunk revision 1132947 (and before), on this same machine,
couch_icu_driver compiles just fine. Relevant make output:
/bin/sh ../../../libtool --tag=CC --mode=compile gcc
-DHAVE_CONFIG_H -I. -I../../.. -I../../../src/snappy/google-snappy
-L/usr/local/lib -L/opt/local/lib -I/opt/otp14/lib/erlang/usr/include
-I/usr/include -I/usr/include/js -I/usr/include/mozjs
-I/usr/local/include -I/opt/local/include -I/usr/local/include/js
-I/opt/local/include/js -DXP_UNIX -I/opt/local/include\c
-L/opt/local/lib\c -g -O2 -MT couch_icu_driver_la-couch_icu_driver.lo
-MD -MP -MF .deps/couch_icu_driver_la-couch_icu_driver.Tpo -c -o
couch_icu_driver_la-couch_icu_driver.lo `test -f
'icu_driver/couch_icu_driver.c' || echo
'./'`icu_driver/couch_icu_driver.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../..
-I../../../src/snappy/google-snappy -L/usr/local/lib -L/opt/local/lib
-I/opt/otp14/lib/erlang/usr/include -I/usr/include -I/usr/include/js
-I/usr/include/mozjs -I/usr/local/include -I/opt/local/include
-I/usr/local/include/js -I/opt/local/include/js -DXP_UNIX
-I/opt/local/includec -L/opt/local/libc -g -O2 -MT
couch_icu_driver_la-couch_icu_driver.lo -MD -MP -MF
.deps/couch_icu_driver_la-couch_icu_driver.Tpo -c
icu_driver/couch_icu_driver.c -fno-common -DPIC -o
.libs/couch_icu_driver_la-couch_icu_driver.o
mv -f .deps/couch_icu_driver_la-couch_icu_driver.Tpo
.deps/couch_icu_driver_la-couch_icu_driver.Plo
/bin/sh ../../../libtool --tag=CC --mode=link gcc
-I/opt/local/include\c -L/opt/local/lib\c -g -O2 -module
-avoid-version -I/opt/local/include\c -L/opt/local/lib\c
-L/usr/local/lib -L/opt/local/lib -I/opt/otp14/lib/erlang/usr/include
-I/usr/include -I/usr/include/js -I/usr/include/mozjs
-I/usr/local/include -I/opt/local/include -I/usr/local/include/js
-I/opt/local/include/js -DXP_UNIX -lm -o couch_icu_driver.la -rpath
/opt/couchdb/lib/couchdb/erlang/lib/couch-1.2.0a-99a4982-git/priv/lib
couch_icu_driver_la-couch_icu_driver.lo -licuuc -licudata -licui18n
-L/usr/local/lib -L/opt/local/lib
libtool: link: gcc -Wl,-undefined -Wl,dynamic_lookup -o
Commits to 1.1.x not in 1.0.x
I was just going through what we back ported to 1.1.x to make sure that all the relevant commits are also on 1.0.x before rolling a release. There are a few that are mostly trivial but I've come across two that I'm a bit stumped on. The first is this one: * https://github.com/davisp/couchdb/commit/a0563ab7ce204cf82feb56259d7a52c0b84077b7 Large contiguous conflict in share/www/script/test/design_docs.js that I'm not sure if I can just choose this patched version or not. The patch to util.js applies cleanly, but the diff to design_docs.js results in a fairly large conflict. It may be a simple code move with indentation difference but if someone could eyeball that closer that'd help. The second is: * https://github.com/davisp/couchdb/commit/d952ac01cb4cd4ae5ceb0c8cc079acf595ff9747 Appears to rely on mochiweb_request:accepts_content_type which does not appear to exist in 1.0.x I'm not even sure if this is relevant to the 1.0.x branch or was a fix for something introduced in the 1.1.x branch with the various content-type changes and what not. Again, if someone would eyeball this that is more familiar with the interaction with jquery/futon that'd be a help. Thanks
Re: make error with latest trunk (ICU related autotools config)
On 13 Jun 2011, at 22:57, Paul Davis wrote: Next time I make big autotools changes ill solicit more feedback on the branch before I put it on trunk. I would actually argue that you shouldn't bother. The build system is always a little peculiar because no one has access to the large number of configuration combinations that users have. As long as you don't make a habit of continually breaking it I don't think its a huge deal. I wouldn't worry about it too much. Paul always goes on about how I'm some Autotools guru. But the real truth of the matter is that I just broke the damn thing so many times that eventually it worked for most people, most of the time. It's almost impossible to know that any particular change is going to work for everybody. There are some pretty unique systems out there. I always took a very organic approach to the build system. Check in what you think looks right, and then wait for people to tell you how you managed to screw things up this time.
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13048969#comment-13048969 ] Jason Smith commented on COUCHDB-431: - I agree, Jacques. CORS will be the microwave oven, or the television. Once it is out and available, people will wonder how they lived without it. The patches apply against 1.1.0 (and applied against trunk when I made them). Apply them all in numeric order. I am planning to make a new patch set called B_0001, B_0002, etc. but for now there is just the As. Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec --- Key: COUCHDB-431 URL: https://issues.apache.org/jira/browse/COUCHDB-431 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Affects Versions: 0.9 Reporter: James Burke Assignee: Randall Leeds Priority: Minor Fix For: 1.2 Attachments: A_0001-Generalize-computing-the-appropriate-headers-for-any.patch, A_0002-Send-server-headers-for-externals-responses.patch, A_0003-Usably-correct-w3c-CORS-headers-for-valid-requests.patch, A_0004-Respond-to-CORS-preflight-checks-HTTP-OPTIONS.patch, cors.html Historically, browsers have been restricted to making XMLHttpRequests (XHRs) to the same origin (domain) as the web page making the request. However, the latest browsers now support cross-domain requests by implementing the Access Control spec from the W3C: http://dev.w3.org/2006/waf/access-control/ In order to keep older servers safe that assume browsers only do same-domain requests, the Access Control spec requires the server to opt-in to allow cross domain requests by the use of special HTTP headers and supporting some pre-flight HTTP calls. Why should CouchDB support this: in larger, high traffic site, it is common to serve the static UI files from a separate, differently scaled server complex than the data access/API server layer. Also, there are some API services that are meant to be centrally hosted, but allow API consumers to use the API from different domains. In these cases, the UI in the browser would need to do cross domain requests to access CouchDB servers that act as the API/data access server layer. JSONP is not enough in these cases since it is limited to GET requests, so no POSTing or PUTing of documents. Some information from Firefox's perspective (functionality available as of Firefox 3.5): https://developer.mozilla.org/en/HTTP_access_control And information on Safari/Webkit (functionality in latest WebKit and Safari 4): http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html IE 8 also uses the Access Control spec, but the requests have to go through their XDomainRequest object (XDR): http://msdn.microsoft.com/en-us/library/cc288060%28VS.85%29.aspx and I thought IE8 only allowed GET or POST requests through their XDR. But as far as CouchDB is concerned, implementing the Access Control headers should be enough, and hopefully IE 9 will allow normal xdomain requests via XHR. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13048972#comment-13048972 ] Benjamin Eidelman commented on COUCHDB-431: --- I'm writing a small js lib that loads from REST services, I wanted to run it against my couchdb hosted on a VM, or even if it's local the test (QUnit) page can run locally (file://), just to be able to run the tests I made a a (lame) workaround, created a small js and html page that I load in CouchDB, then from my test page I load this CouchDB-hosted page in a hidden iframe, and proxy all ajax calls thru that iframe (using window.postMessage). ust for testing purposes, it anyone is interested: https://github.com/benjamine/FrameProxy But I'll love to see CORS implemented in CouchDB and throw that script+page away! Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec --- Key: COUCHDB-431 URL: https://issues.apache.org/jira/browse/COUCHDB-431 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Affects Versions: 0.9 Reporter: James Burke Assignee: Randall Leeds Priority: Minor Fix For: 1.2 Attachments: A_0001-Generalize-computing-the-appropriate-headers-for-any.patch, A_0002-Send-server-headers-for-externals-responses.patch, A_0003-Usably-correct-w3c-CORS-headers-for-valid-requests.patch, A_0004-Respond-to-CORS-preflight-checks-HTTP-OPTIONS.patch, cors.html Historically, browsers have been restricted to making XMLHttpRequests (XHRs) to the same origin (domain) as the web page making the request. However, the latest browsers now support cross-domain requests by implementing the Access Control spec from the W3C: http://dev.w3.org/2006/waf/access-control/ In order to keep older servers safe that assume browsers only do same-domain requests, the Access Control spec requires the server to opt-in to allow cross domain requests by the use of special HTTP headers and supporting some pre-flight HTTP calls. Why should CouchDB support this: in larger, high traffic site, it is common to serve the static UI files from a separate, differently scaled server complex than the data access/API server layer. Also, there are some API services that are meant to be centrally hosted, but allow API consumers to use the API from different domains. In these cases, the UI in the browser would need to do cross domain requests to access CouchDB servers that act as the API/data access server layer. JSONP is not enough in these cases since it is limited to GET requests, so no POSTing or PUTing of documents. Some information from Firefox's perspective (functionality available as of Firefox 3.5): https://developer.mozilla.org/en/HTTP_access_control And information on Safari/Webkit (functionality in latest WebKit and Safari 4): http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html IE 8 also uses the Access Control spec, but the requests have to go through their XDomainRequest object (XDR): http://msdn.microsoft.com/en-us/library/cc288060%28VS.85%29.aspx and I thought IE8 only allowed GET or POST requests through their XDR. But as far as CouchDB is concerned, implementing the Access Control headers should be enough, and hopefully IE 9 will allow normal xdomain requests via XHR. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
