[jira] [Created] (COUCHDB-2029) Consolidate CSS/LESS class name usage to minimize custom-ness
Benjamin Young created COUCHDB-2029: --- Summary: Consolidate CSS/LESS class name usage to minimize custom-ness Key: COUCHDB-2029 URL: https://issues.apache.org/jira/browse/COUCHDB-2029 Project: CouchDB Issue Type: Improvement Components: Fauxton Reporter: Benjamin Young Right now Fauxton has loads of non-Bootstrap class names and styles for things that Bootstrap has a name for (ex: .button vs. .btn). Often those class names and styles compete and sometimes are even used together causing a pretty tangled mess. Focusing our use of class names on the Bootstrap defined ones gives new comers to the code documentation on what classes mean what--and we don't even have to maintain it! :D If you know Bootstrap, you should be able to know how to add buttons, etc to Fauxton without getting tripped up by .button .red .outlineGray, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2029) Consolidate CSS/LESS class name usage to minimize custom-ness
[ https://issues.apache.org/jira/browse/COUCHDB-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870734#comment-13870734 ] Benjamin Young commented on COUCHDB-2029: - This is already in progress on this branch on Github: https://github.com/bigbluehat/couchdb/tree/style-tests-and-class-cleanups I'm working to keep it up to date with the latest from Fauxton. I'll ping for review once it's ready (or at least at the next merge-able point...as it'll be an ongoing effort). Thanks! Consolidate CSS/LESS class name usage to minimize custom-ness - Key: COUCHDB-2029 URL: https://issues.apache.org/jira/browse/COUCHDB-2029 Project: CouchDB Issue Type: Improvement Components: Fauxton Reporter: Benjamin Young Right now Fauxton has loads of non-Bootstrap class names and styles for things that Bootstrap has a name for (ex: .button vs. .btn). Often those class names and styles compete and sometimes are even used together causing a pretty tangled mess. Focusing our use of class names on the Bootstrap defined ones gives new comers to the code documentation on what classes mean what--and we don't even have to maintain it! :D If you know Bootstrap, you should be able to know how to add buttons, etc to Fauxton without getting tripped up by .button .red .outlineGray, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2029) Consolidate CSS/LESS class name usage to minimize custom-ness
[ https://issues.apache.org/jira/browse/COUCHDB-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garren Smith reassigned COUCHDB-2029: - Assignee: Garren Smith Consolidate CSS/LESS class name usage to minimize custom-ness - Key: COUCHDB-2029 URL: https://issues.apache.org/jira/browse/COUCHDB-2029 Project: CouchDB Issue Type: Improvement Components: Fauxton Reporter: Benjamin Young Assignee: Garren Smith Right now Fauxton has loads of non-Bootstrap class names and styles for things that Bootstrap has a name for (ex: .button vs. .btn). Often those class names and styles compete and sometimes are even used together causing a pretty tangled mess. Focusing our use of class names on the Bootstrap defined ones gives new comers to the code documentation on what classes mean what--and we don't even have to maintain it! :D If you know Bootstrap, you should be able to know how to add buttons, etc to Fauxton without getting tripped up by .button .red .outlineGray, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COUCHDB-2030) Duplicate doc button fails when form is submitted via enter
Simon Metson created COUCHDB-2030: - Summary: Duplicate doc button fails when form is submitted via enter Key: COUCHDB-2030 URL: https://issues.apache.org/jira/browse/COUCHDB-2030 Project: CouchDB Issue Type: Bug Reporter: Simon Metson In the document edit screen I can duplicate the current doc. This works fine when the forms button is clicked but fails if the form is submitted by pressing enter on the keyboard. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COUCHDB-2030) Duplicate doc button fails when form is submitted via enter
[ https://issues.apache.org/jira/browse/COUCHDB-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Metson updated COUCHDB-2030: -- Priority: Minor (was: Major) Skill Level: New Contributors Level (Easy) Duplicate doc button fails when form is submitted via enter --- Key: COUCHDB-2030 URL: https://issues.apache.org/jira/browse/COUCHDB-2030 Project: CouchDB Issue Type: Bug Reporter: Simon Metson Priority: Minor In the document edit screen I can duplicate the current doc. This works fine when the forms button is clicked but fails if the form is submitted by pressing enter on the keyboard. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COUCHDB-2030) Duplicate doc button fails when form is submitted via enter
[ https://issues.apache.org/jira/browse/COUCHDB-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870739#comment-13870739 ] Simon Metson commented on COUCHDB-2030: --- Fix for this up in https://github.com/drsm79/couchdb/tree/COUCHDB-2030 Duplicate doc button fails when form is submitted via enter --- Key: COUCHDB-2030 URL: https://issues.apache.org/jira/browse/COUCHDB-2030 Project: CouchDB Issue Type: Bug Reporter: Simon Metson Priority: Minor In the document edit screen I can duplicate the current doc. This works fine when the forms button is clicked but fails if the form is submitted by pressing enter on the keyboard. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (COUCHDB-2030) Duplicate doc button fails when form is submitted via enter
[ https://issues.apache.org/jira/browse/COUCHDB-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garren Smith resolved COUCHDB-2030. --- Resolution: Fixed Duplicate doc button fails when form is submitted via enter --- Key: COUCHDB-2030 URL: https://issues.apache.org/jira/browse/COUCHDB-2030 Project: CouchDB Issue Type: Bug Reporter: Simon Metson Assignee: Garren Smith Priority: Minor In the document edit screen I can duplicate the current doc. This works fine when the forms button is clicked but fails if the form is submitted by pressing enter on the keyboard. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (COUCHDB-2030) Duplicate doc button fails when form is submitted via enter
[ https://issues.apache.org/jira/browse/COUCHDB-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garren Smith reassigned COUCHDB-2030: - Assignee: Garren Smith Duplicate doc button fails when form is submitted via enter --- Key: COUCHDB-2030 URL: https://issues.apache.org/jira/browse/COUCHDB-2030 Project: CouchDB Issue Type: Bug Reporter: Simon Metson Assignee: Garren Smith Priority: Minor In the document edit screen I can duplicate the current doc. This works fine when the forms button is clicked but fails if the form is submitted by pressing enter on the keyboard. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
couchdb pull request: made couchserver configurable via settings.json
GitHub user BigBlueHat opened a pull request: https://github.com/apache/couchdb/pull/132 made couchserver configurable via settings.json Making couchserver configurable via settings.json means you can have Fauxton work against a proxy of a CouchDB-compatible server hosted elsewhere (i.e. Cloudant, IrisCouch, pouchdb-server). You can merge this pull request into a Git repository by running: $ git pull https://github.com/BigBlueHat/couchdb grunt-proxy-config-in-settings Alternatively you can review and apply these changes as the patch at: https://github.com/apache/couchdb/pull/132.patch commit 81a11c7ca159384dacd9bb7189576ca2ad435b56 Author: BigBlueHat byo...@bigbluehat.com Date: 2014-01-14T19:27:27Z made couchserver configurable via settings.json
couchdb pull request: added release to test task list
GitHub user BigBlueHat opened a pull request: https://github.com/apache/couchdb/pull/133 added release to test task list Simplest possible fix. :grin: You can merge this pull request into a Git repository by running: $ git pull https://github.com/BigBlueHat/couchdb make-tests-runable Alternatively you can review and apply these changes as the patch at: https://github.com/apache/couchdb/pull/133.patch commit 861ac6926660500122cbc3c31064f56436e74140 Author: BigBlueHat byo...@bigbluehat.com Date: 2014-01-14T19:43:26Z added release to test task list Simplest possible fix. :grin:
[jira] [Updated] (COUCHDB-2002) Implement a hard cap on OS process count in couch_proc_manager
[ https://issues.apache.org/jira/browse/COUCHDB-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski updated COUCHDB-2002: Summary: Implement a hard cap on OS process count in couch_proc_manager (was: Implement couch_proc_manager) Implement a hard cap on OS process count in couch_proc_manager -- Key: COUCHDB-2002 URL: https://issues.apache.org/jira/browse/COUCHDB-2002 Project: CouchDB Issue Type: Improvement Components: BigCouch Reporter: Volker Mische We need to implement the hard ceiling for capping the number of OS processes. We’ve started seeing a need for this at Cloudant with some work loads so motivation to fix this is high. The only failing etap is the assertion of this ceiling. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
couchdb pull request: Fauxton tests on travis
GitHub user BigBlueHat opened a pull request: https://github.com/apache/couchdb/pull/134 Fauxton tests on travis @Kxepal this hopefully gets Travis running working Fauxton tests. It's branched off of my other branch that's pending in #133, so merging this obviates the need of the other. I need to sort out getting Travis to run my branches, so I can test this properly. Hopefully pushing it to a branch in the apache/couchdb repo would let you know quickly if it works. :smile: It should of course. :smile_cat: You can merge this pull request into a Git repository by running: $ git pull https://github.com/BigBlueHat/couchdb fauxton-tests-on-travis Alternatively you can review and apply these changes as the patch at: https://github.com/apache/couchdb/pull/134.patch commit 861ac6926660500122cbc3c31064f56436e74140 Author: BigBlueHat byo...@bigbluehat.com Date: 2014-01-14T19:43:26Z added release to test task list Simplest possible fix. :grin: commit 72cb4879686dd2c008219dd550309102ab0bb92b Author: BigBlueHat byo...@bigbluehat.com Date: 2014-01-14T21:01:32Z added fauxton grunt test stuff to .travis.yml
[jira] [Resolved] (COUCHDB-2004) Remove references to missing modules and functions
[ https://issues.apache.org/jira/browse/COUCHDB-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson resolved COUCHDB-2004. Resolution: Fixed fixed on 1843-feature-bigcouch. Remove references to missing modules and functions -- Key: COUCHDB-2004 URL: https://issues.apache.org/jira/browse/COUCHDB-2004 Project: CouchDB Issue Type: Improvement Components: BigCouch Reporter: Volker Mische -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[REMINDER] Weekly IRC meeting, Wednesday 2013-01-15 at 20:00 UTC
Dear community, Please join our weekly IRC meeting, Wednesday 2013-01-15 at 20:00 UTC. Everyone is welcome to attend this meeting. If you have anything to put on the agenda, please reply to this email or mention it at the start of the meeting. The meeting will take place in: irc://irc.freenode.net/couchdb-meeting You can access the meeting via the web: http://webchat.freenode.net/?channels=#couchdb-meeting For your local time, see: http://arewemeetingyet.com/UTC/2014-01-15/20:00/CouchDB%20IRC%20Meeting A+ dch
[DISCUSS] Multiple Repositories for Erlang Apps and Dependencies
I've recently been having discussions about how to handle the repository configuration for various bits of CouchDB post-merge. The work that Benoit has been doing on the rcouch merge branch have also touched on this topic as well. The background for those unfamiliar is that the standard operating procedure for Erlang is to have a single Erlang application per repository and then rely on rebar to fetch each dependency. Traditionally in CouchDB land we've always just included the source to all applications in a single monolithic repository and periodically reimport changes from upstream dependencies. Recently rcouch changed from the monolithic repository to use external repositories for some dependencies. Originally the BigCouch used an even more federated scheme that had each Erlang application in an external repository (and the core couch Erlang application was in the root repository). When Bob Newson and I did the initial hacking on the BigCouch merge we pulled those external dependencies into the root repository reverting back to the large monolithic approach. After trying to deal with the merge and contemplating how various Erlang release things might work it's become fairly apparent that the monolithic approach is a bit constrictive. For instance, part of rebar's versioning abilities lets you tag repositories to generate versions rather than manually updating versions in source files. Another thing I've found on other projects is that having each application in a separate repository requires developers to think a bit more detailed about the public internal interfaces used through out the system. We've done some work to this extent already with separating source directories but forcing commits to multiple repositories shoots up a big red flag that maybe there's a high level of coupling between two bits of code. Other benefits of having the multiple repository setup is that its possible that this lends itself to being integrated with the proposed plugin system. It'd be fairly trivial to have a script that went and fetched plugins that aren't developed at Apache (as a ./configure time switch type of thing). Having a system like this would also allow us to have groups focused on particular bits of development not have to concern themselves with the unrelated parts of the system. Given all that, I'd like to propose that we move to having a repository for each application/dependency that we use to build CouchDB. Each repository would be hosted on ASF infra and mirrored to GitHub as expected. This means that we could have the root repository be a simple repo that contains packaging/release/build stuff that would enable lots of the ideas offered on configurable types of release generation. I've included an initial list of repositories at the end of this email. Its basically just the apps that have been split out in either rcouch or bigcouch plus a few other bits from CouchDB master. I would also point out that even though our main repo would need to fetch other dependencies from the internet to build the final output, we fully intend that our release tarballs would *not* have this requirement. Ie, when we go to cut a release part of the process the RM would run would be to pull all of those dependencies before creating a tarball that would be wholly self contained. Given an apache-couchdb-x.y.z.tar.gz release file, there won't be a requirement to have access to the ASF git repos. I'm not entirely sure how controversial this is for anyone. For the most part the reactions I remember hearing were more concerned on whether the infrastructure team would allow us to use this sort of configuration. I looked yesterday and asked and apparently its something we can request but as always we'll want to verify again if we have consensus to move in this direction. Anyone have comments or flames? Right now I'm just interested in feeling out what sort of (lack of?) consensus there is on such a change. If there's general consensus I'd think we'd do a vote in a couple weeks and if that passes then start on down this road for the two merge projects and then it would become part of master once those land (as opposed to doing this to master and then attempting to merge rcouch/bigcouch onto that somehow). This is a quick pass at listing what extra repositories I'd have created. Some of these applications only exist in the bigcouch and/or rcouch branches so that's where the unfamiliar application names are from. I'd also point out that the documentation and fauxton things are just on a whim in that we could decouple that development from the erlang development. I can see arguments for an against those. I'm much less concerned on that aspect than the Erlang parts that are directly affected by rebar/Erlang conventions. chttpd config couch couch_collate couch_dbupdates couch_httpd couch_index couch_mrview couch_plugins couch_replicator documentation ddoc_cache ets_lru
Re: [DISCUSS] Multiple Repositories for Erlang Apps and Dependencies
On Jan 14, 2014, at 3:22 PM, Paul Davis paul.joseph.da...@gmail.com wrote: I'd like to propose that we move to having a repository for each application/dependency that we use to build CouchDB. Each repository would be hosted on ASF infra and mirrored to GitHub as expected. Good idea. It's going to be an annoyance on occasion but it sets us up for success. Adam
Re: [DISCUSS] Multiple Repositories for Erlang Apps and Dependencies
+1. The monolithic design makes development and pull requests easier, one vs many for some features, but I think this is generally outweighed by the pros outlined. I think a broken-out design makes it easier to add alternate functionality in places, or swap in/out things to test with. I agree releases should stay flat. /JamesM On 1/14/14 3:22 PM, Paul Davis paul.joseph.da...@gmail.com wrote: I've recently been having discussions about how to handle the repository configuration for various bits of CouchDB post-merge. The work that Benoit has been doing on the rcouch merge branch have also touched on this topic as well. The background for those unfamiliar is that the standard operating procedure for Erlang is to have a single Erlang application per repository and then rely on rebar to fetch each dependency. Traditionally in CouchDB land we've always just included the source to all applications in a single monolithic repository and periodically reimport changes from upstream dependencies. Recently rcouch changed from the monolithic repository to use external repositories for some dependencies. Originally the BigCouch used an even more federated scheme that had each Erlang application in an external repository (and the core couch Erlang application was in the root repository). When Bob Newson and I did the initial hacking on the BigCouch merge we pulled those external dependencies into the root repository reverting back to the large monolithic approach. After trying to deal with the merge and contemplating how various Erlang release things might work it's become fairly apparent that the monolithic approach is a bit constrictive. For instance, part of rebar's versioning abilities lets you tag repositories to generate versions rather than manually updating versions in source files. Another thing I've found on other projects is that having each application in a separate repository requires developers to think a bit more detailed about the public internal interfaces used through out the system. We've done some work to this extent already with separating source directories but forcing commits to multiple repositories shoots up a big red flag that maybe there's a high level of coupling between two bits of code. Other benefits of having the multiple repository setup is that its possible that this lends itself to being integrated with the proposed plugin system. It'd be fairly trivial to have a script that went and fetched plugins that aren't developed at Apache (as a ./configure time switch type of thing). Having a system like this would also allow us to have groups focused on particular bits of development not have to concern themselves with the unrelated parts of the system. Given all that, I'd like to propose that we move to having a repository for each application/dependency that we use to build CouchDB. Each repository would be hosted on ASF infra and mirrored to GitHub as expected. This means that we could have the root repository be a simple repo that contains packaging/release/build stuff that would enable lots of the ideas offered on configurable types of release generation. I've included an initial list of repositories at the end of this email. Its basically just the apps that have been split out in either rcouch or bigcouch plus a few other bits from CouchDB master. I would also point out that even though our main repo would need to fetch other dependencies from the internet to build the final output, we fully intend that our release tarballs would *not* have this requirement. Ie, when we go to cut a release part of the process the RM would run would be to pull all of those dependencies before creating a tarball that would be wholly self contained. Given an apache-couchdb-x.y.z.tar.gz release file, there won't be a requirement to have access to the ASF git repos. I'm not entirely sure how controversial this is for anyone. For the most part the reactions I remember hearing were more concerned on whether the infrastructure team would allow us to use this sort of configuration. I looked yesterday and asked and apparently its something we can request but as always we'll want to verify again if we have consensus to move in this direction. Anyone have comments or flames? Right now I'm just interested in feeling out what sort of (lack of?) consensus there is on such a change. If there's general consensus I'd think we'd do a vote in a couple weeks and if that passes then start on down this road for the two merge projects and then it would become part of master once those land (as opposed to doing this to master and then attempting to merge rcouch/bigcouch onto that somehow). This is a quick pass at listing what extra repositories I'd have created. Some of these applications only exist in the bigcouch and/or rcouch branches so that's where the unfamiliar application names are from. I'd also point out that the documentation and fauxton things are just on a whim in that we could decouple that
Re: [DISCUSS] Multiple Repositories for Erlang Apps and Dependencies
On Wed, Jan 15, 2014 at 12:22 AM, Paul Davis paul.joseph.da...@gmail.comwrote: I've recently been having discussions about how to handle the repository configuration for various bits of CouchDB post-merge. The work that Benoit has been doing on the rcouch merge branch have also touched on this topic as well. The background for those unfamiliar is that the standard operating procedure for Erlang is to have a single Erlang application per repository and then rely on rebar to fetch each dependency. Traditionally in CouchDB land we've always just included the source to all applications in a single monolithic repository and periodically reimport changes from upstream dependencies. Recently rcouch changed from the monolithic repository to use external repositories for some dependencies. Originally the BigCouch used an even more federated scheme that had each Erlang application in an external repository (and the core couch Erlang application was in the root repository). When Bob Newson and I did the initial hacking on the BigCouch merge we pulled those external dependencies into the root repository reverting back to the large monolithic approach. After trying to deal with the merge and contemplating how various Erlang release things might work it's become fairly apparent that the monolithic approach is a bit constrictive. For instance, part of rebar's versioning abilities lets you tag repositories to generate versions rather than manually updating versions in source files. Another thing I've found on other projects is that having each application in a separate repository requires developers to think a bit more detailed about the public internal interfaces used through out the system. We've done some work to this extent already with separating source directories but forcing commits to multiple repositories shoots up a big red flag that maybe there's a high level of coupling between two bits of code. Other benefits of having the multiple repository setup is that its possible that this lends itself to being integrated with the proposed plugin system. It'd be fairly trivial to have a script that went and fetched plugins that aren't developed at Apache (as a ./configure time switch type of thing). Having a system like this would also allow us to have groups focused on particular bits of development not have to concern themselves with the unrelated parts of the system. Given all that, I'd like to propose that we move to having a repository for each application/dependency that we use to build CouchDB. Each repository would be hosted on ASF infra and mirrored to GitHub as expected. This means that we could have the root repository be a simple repo that contains packaging/release/build stuff that would enable lots of the ideas offered on configurable types of release generation. I've included an initial list of repositories at the end of this email. Its basically just the apps that have been split out in either rcouch or bigcouch plus a few other bits from CouchDB master. I would also point out that even though our main repo would need to fetch other dependencies from the internet to build the final output, we fully intend that our release tarballs would *not* have this requirement. Ie, when we go to cut a release part of the process the RM would run would be to pull all of those dependencies before creating a tarball that would be wholly self contained. Given an apache-couchdb-x.y.z.tar.gz release file, there won't be a requirement to have access to the ASF git repos. I'm not entirely sure how controversial this is for anyone. For the most part the reactions I remember hearing were more concerned on whether the infrastructure team would allow us to use this sort of configuration. I looked yesterday and asked and apparently its something we can request but as always we'll want to verify again if we have consensus to move in this direction. Anyone have comments or flames? Right now I'm just interested in feeling out what sort of (lack of?) consensus there is on such a change. If there's general consensus I'd think we'd do a vote in a couple weeks and if that passes then start on down this road for the two merge projects and then it would become part of master once those land (as opposed to doing this to master and then attempting to merge rcouch/bigcouch onto that somehow). This is a quick pass at listing what extra repositories I'd have created. Some of these applications only exist in the bigcouch and/or rcouch branches so that's where the unfamiliar application names are from. I'd also point out that the documentation and fauxton things are just on a whim in that we could decouple that development from the erlang development. I can see arguments for an against those. I'm much less concerned on that aspect than the Erlang parts that are directly affected by rebar/Erlang conventions. chttpd config couch
Re: [DISCUSS] Multiple Repositories for Erlang Apps and Dependencies
On Wed, Jan 15, 2014 at 12:22 AM, Paul Davis paul.joseph.da...@gmail.comwrote: I would also point out that even though our main repo would need to fetch other dependencies from the internet to build the final output, we fully intend that our release tarballs would *not* have this requirement. Ie, when we go to cut a release part of the process the RM would run would be to pull all of those dependencies before creating a tarball that would be wholly self contained. Given an apache-couchdb-x.y.z.tar.gz release file, there won't be a requirement to have access to the ASF git repos. Just to be clear, the idea would be creating only a release tarrball from all the git repositories or do you also think to create a full repository from all the dependencies? Something done by Cloudi for example which build the main repository [1] from the other repositories [2]. rcouch is only creating a tarball containing all erlang deps [3] . Also what about the npm modules that are fetched for futon and couchjs-node? Do you think we need to import them as well? At least maybe should we provide a mirror? - benoit [1] https://github.com/CloudI/CloudI [2] https://github.com/Cloudi and [3] https://github.com/refuge/rcouch/blob/master/Makefile#L120
rcouch merge - new intermediate status
Just a quick status about the work has been done since the last status. I had to pause the merge during the last 2 days, but it should be finished tomorrow now. Since the last status I made the following changes: - After toying with the sources and looked/discussed around, I put back everything in src/ to the source root. Mainly to ease the integration with other applications and follow the general pattern in the Erlang world. - couch_httpd is a full Erlang application. In the process I fixed its supervision to make it upgradable. Also a change in the config don't crash anything but just relaunch smoothly the accepting processes - JS tests are more debuggable from the console. I did that so I can test the couch_httpd change easily. - Improved the test suite in view of using more standalone applications late. - fixed a couple of things around Currently missing from rcouch are: - the view changes - couch_index as a standalone application - validate_doc_read From couchdb we also miss the `make distcheck` . My idea about that would be automatize it a little more ala openbsd: 1. On release have a `make plist` creating a PLIST file containing all the sources files with their hash signature (SHA256) that need to be shipped. This PLIST can be fixed manually. 2. make distcheck that check each files and its signatures from the generated PLIST. But it can be probably put for later, depending on the result of the Multiple Repositories for Erlang Apps and Dependencies discussion. I think it would be good at some point to see how we can start the integration with bigcouch Having 2 merges running separately is quite unproductive. If we can do that over the ml that would be perfect. Also having more tests from others in the team would be really helpful. Waiting that having rcouch `make test` in the CI would allows me to figure what is not working on the platforms I don't test regularly. - benoit
Re: [DISCUSS] Multiple Repositories for Erlang Apps and Dependencies
On Jan 14, 2014, at 8:47 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Wed, Jan 15, 2014 at 12:22 AM, Paul Davis paul.joseph.da...@gmail.comwrote: I would also point out that even though our main repo would need to fetch other dependencies from the internet to build the final output, we fully intend that our release tarballs would *not* have this requirement. Ie, when we go to cut a release part of the process the RM would run would be to pull all of those dependencies before creating a tarball that would be wholly self contained. Given an apache-couchdb-x.y.z.tar.gz release file, there won't be a requirement to have access to the ASF git repos. Just to be clear, the idea would be creating only a release tarrball from all the git repositories or do you also think to create a full repository from all the dependencies? Something done by Cloudi for example which build the main repository [1] from the other repositories [2]. rcouch is only creating a tarball containing all erlang deps [3] . I hadn't contemplated a synthetic repository until you mentioned it but my initial reaction is ick. Not sure I see a point but it's also not something I see as overly detrimental. Regardless of that I'd expect the release tarball would be able to be generated from just the federated repositories. Also what about the npm modules that are fetched for futon and couchjs-node? Do you think we need to import them as well? At least maybe should we provide a mirror? - benoit I don't know enough about the state of these modules to have an opinion. I've talked to a few people about the fauxton build in general but I don't have a clear picture on what's a build time vs configure time dependency as well as how fauxton configure/build steps map to the corresponding configure/build steps. For instance, if as part of a release we build a completed fauxton and include that as a static thing then id not pull the npm dependencies directly and instead consider them external dependencies. But it's also completely possible I have no idea what I'm talking about and that makes no sense. [1] https://github.com/CloudI/CloudI [2] https://github.com/Cloudi and [3] https://github.com/refuge/rcouch/blob/master/Makefile#L120
[jira] [Commented] (COUCHDB-1946) Trying to replicate NPM grinds to a halt after 40GB
[ https://issues.apache.org/jira/browse/COUCHDB-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871736#comment-13871736 ] Nathan Caza commented on COUCHDB-1946: -- So, I've been experiencing this, I've had a script replicating 1-by-1 (no bulk api). I haven't had any issues, EXCEPT as replication goes on, small documents wiz by and now towards the end, all that is left is a large number of bigger documents. I skipped large documents the first pass, but I presume had I not, I would have ran out of sockets/workers as they slowly filled up with the large transfers/documents. Also to note that one of these, as an example, is about ~40MB (a unicode document/package I believe) , when simply gzipped becomes ~1.3MB. Are there plans to support gzip compression? Trying to replicate NPM grinds to a halt after 40GB --- Key: COUCHDB-1946 URL: https://issues.apache.org/jira/browse/COUCHDB-1946 Project: CouchDB Issue Type: Bug Components: Database Core Reporter: Marc Trudel Attachments: couch.log I have been able to replicate the Node.js NPM database until 40G or so, then I get this: https://gist.github.com/stelcheck/7723362 I one case I have gotten a flat-out OOM error, but I didn't take a dump of the log output at the time. CentOS6.4 with CouchDB 1.5 (also tried 1.3.1, but to no avail). Also tried to restart replication from scratch - twice - bot cases stalling at 40GB. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [DISCUSS] Multiple Repositories for Erlang Apps and Dependencies
On Jan 14, 2014, at 8:37 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Wed, Jan 15, 2014 at 12:22 AM, Paul Davis paul.joseph.da...@gmail.comwrote: I've recently been having discussions about how to handle the repository configuration for various bits of CouchDB post-merge. The work that Benoit has been doing on the rcouch merge branch have also touched on this topic as well. The background for those unfamiliar is that the standard operating procedure for Erlang is to have a single Erlang application per repository and then rely on rebar to fetch each dependency. Traditionally in CouchDB land we've always just included the source to all applications in a single monolithic repository and periodically reimport changes from upstream dependencies. Recently rcouch changed from the monolithic repository to use external repositories for some dependencies. Originally the BigCouch used an even more federated scheme that had each Erlang application in an external repository (and the core couch Erlang application was in the root repository). When Bob Newson and I did the initial hacking on the BigCouch merge we pulled those external dependencies into the root repository reverting back to the large monolithic approach. After trying to deal with the merge and contemplating how various Erlang release things might work it's become fairly apparent that the monolithic approach is a bit constrictive. For instance, part of rebar's versioning abilities lets you tag repositories to generate versions rather than manually updating versions in source files. Another thing I've found on other projects is that having each application in a separate repository requires developers to think a bit more detailed about the public internal interfaces used through out the system. We've done some work to this extent already with separating source directories but forcing commits to multiple repositories shoots up a big red flag that maybe there's a high level of coupling between two bits of code. Other benefits of having the multiple repository setup is that its possible that this lends itself to being integrated with the proposed plugin system. It'd be fairly trivial to have a script that went and fetched plugins that aren't developed at Apache (as a ./configure time switch type of thing). Having a system like this would also allow us to have groups focused on particular bits of development not have to concern themselves with the unrelated parts of the system. Given all that, I'd like to propose that we move to having a repository for each application/dependency that we use to build CouchDB. Each repository would be hosted on ASF infra and mirrored to GitHub as expected. This means that we could have the root repository be a simple repo that contains packaging/release/build stuff that would enable lots of the ideas offered on configurable types of release generation. I've included an initial list of repositories at the end of this email. Its basically just the apps that have been split out in either rcouch or bigcouch plus a few other bits from CouchDB master. I would also point out that even though our main repo would need to fetch other dependencies from the internet to build the final output, we fully intend that our release tarballs would *not* have this requirement. Ie, when we go to cut a release part of the process the RM would run would be to pull all of those dependencies before creating a tarball that would be wholly self contained. Given an apache-couchdb-x.y.z.tar.gz release file, there won't be a requirement to have access to the ASF git repos. I'm not entirely sure how controversial this is for anyone. For the most part the reactions I remember hearing were more concerned on whether the infrastructure team would allow us to use this sort of configuration. I looked yesterday and asked and apparently its something we can request but as always we'll want to verify again if we have consensus to move in this direction. Anyone have comments or flames? Right now I'm just interested in feeling out what sort of (lack of?) consensus there is on such a change. If there's general consensus I'd think we'd do a vote in a couple weeks and if that passes then start on down this road for the two merge projects and then it would become part of master once those land (as opposed to doing this to master and then attempting to merge rcouch/bigcouch onto that somehow). This is a quick pass at listing what extra repositories I'd have created. Some of these applications only exist in the bigcouch and/or rcouch branches so that's where the unfamiliar application names are from. I'd also point out that the documentation and fauxton things are just on a whim in that we could decouple that development from the erlang development. I can see arguments for an against those. I'm much less concerned on that aspect than the Erlang parts that are directly
