Re: Is it time to merge prototype/fdb-layer to master?
Have been asking for it for a while ;) obviously +1. Be aware that Jenkinsfile.full post-merge will probably fail because, at the very least, the FreeBSD hosts won't have fdb and can't run docker to containerise it. This will need some exploration to resolve but shouldn't be a blocker. The Jenkins setup will also need slight changes when we rename branches. Also keep in mind other repos need the branch renaming, too. ASF Infra can do the GitHub dance to change the name of the main branch. -Joan "about time" Touzet On 2020-09-09 2:05 p.m., Robert Samuel Newson wrote: Agree that its time to get the fdb-layer work into master, that's where couchdb 4.0 should be being created. thanks for preserving the imported ebtree history. On 9 Sep 2020, at 17:28, Paul Davis wrote: The merge on this turned out to be a lot more straightforward so I think its probably the way to go. I've got a failing test in couch_views_active_tasks_test but it appears to be flaky rather than a merge error. I'll work though getting `make check` to complete and then send another update. https://github.com/apache/couchdb/tree/prototype/fdb-layer-final-merge https://github.com/apache/couchdb/commit/873ccb4882f2e984c25f59ad0fd0a0677b9d4477 On Wed, Sep 9, 2020 at 10:29 AM Paul Davis wrote: Howdy folks! I've just gone through a rebase of `prototype/fdb-layer` against master. Its not quite finished because the ebtree import went wrong during rebase due to a weirdness of the history. I have a PR up for the rebase into master for people to look at [1]. Although the more important comparison is likely with the current `prototype/fdb-layer` that can be found at [2]. Given the ebtree aspect, as well as the fact that I get labeled as the committer for all commits when doing a rebase I'm also wondering if we shouldn't turn this into a merge in this instance. I'll work up a second branch that shows that diff as well that we could then rebase onto master. Regardless, I'd appreciate if we could get some eyeballs on the diff and then finally merge this work to the default branch so its the main line development going forward. Paul [1] https://github.com/apache/couchdb/pull/3137 [2] https://github.com/apache/couchdb/compare/prototype/fdb-layer...prototype/fdb-layer-final-rebase
Re: [DISCUSS] Rename default branch to `main`
+1. Thanks for starting this, Paul. I was actually going to try and drive this a month or two ago, but things got busy for me. I'd also support renaming it to 'trunk' but really don't care what we pick. The first commercial version control system I used to use, called that branch "main": https://i.ibb.co/7bMDt3c/cc-ver-tree2.gif -Joan "yes, that's motif" Touzet On 2020-09-09 11:40 a.m., Paul Davis wrote: Howdy Folks! Words matter. I've just started a thread on merging all of the FoundationDB work into mainline development and thought this would be a good time to bring up a separate discussion on renaming our default branch. Personally, I've got a few projects where I used `main` for the mainline development branch. I find it to be a fairly natural shift because I tab-complete everything on the command line. I'd be open to other suggestions but I'm also hoping this doesn't devolve into a bikeshed on what we end up picking. For mechanics, what I'm thinking is that when we finish up the last rebase of the FoundationDB work that instead of actually pushing the merge/rebase button we just rename the branch and then change the default branch on GitHub and close the PR. Thoughts? Paul
Re: [DISCUSS] Rename default branch to `main`
+1 This conversation kind of spilled into the other thread about merging, so I replied there as well about main vs master and rebasing. Sorry about the confusion. On Wed, Sep 9, 2020 at 2:05 PM Robert Samuel Newson wrote: > > I'm +1 in favour of renaming to 'main'. > > > > > On 9 Sep 2020, at 18:26, Alessio 'Blaster' Biancalana > > wrote: > > > > I'm not against nor in favor :-D > > Words matter but in my opinion git's master was never _that_ master. > > Anyway, if it bothers someone... let's do this! > > > > Concerning open PRs, I don't know, I think original authors can easily > > rebase. Also, the next release will cut some stuff open I think, so maybe > > we'll find a feasible time slot to do so. > > > > Alessio > > > > On Wed, Sep 9, 2020 at 5:40 PM Paul Davis > > wrote: > > > >> Howdy Folks! > >> > >> Words matter. I've just started a thread on merging all of the > >> FoundationDB work into mainline development and thought this would be > >> a good time to bring up a separate discussion on renaming our default > >> branch. > >> > >> Personally, I've got a few projects where I used `main` for the > >> mainline development branch. I find it to be a fairly natural shift > >> because I tab-complete everything on the command line. I'd be open to > >> other suggestions but I'm also hoping this doesn't devolve into a > >> bikeshed on what we end up picking. > >> > >> For mechanics, what I'm thinking is that when we finish up the last > >> rebase of the FoundationDB work that instead of actually pushing the > >> merge/rebase button we just rename the branch and then change the > >> default branch on GitHub and close the PR. > >> > >> Thoughts? > >> > >> Paul > >> >
Re: Is it time to merge prototype/fdb-layer to master?
Agree that its time to get the fdb-layer work into master, that's where couchdb 4.0 should be being created. thanks for preserving the imported ebtree history. > On 9 Sep 2020, at 17:28, Paul Davis wrote: > > The merge on this turned out to be a lot more straightforward so I > think its probably the way to go. I've got a failing test in > couch_views_active_tasks_test but it appears to be flaky rather than a > merge error. I'll work though getting `make check` to complete and > then send another update. > > https://github.com/apache/couchdb/tree/prototype/fdb-layer-final-merge > https://github.com/apache/couchdb/commit/873ccb4882f2e984c25f59ad0fd0a0677b9d4477 > > On Wed, Sep 9, 2020 at 10:29 AM Paul Davis > wrote: >> >> Howdy folks! >> >> I've just gone through a rebase of `prototype/fdb-layer` against >> master. Its not quite finished because the ebtree import went wrong >> during rebase due to a weirdness of the history. >> >> I have a PR up for the rebase into master for people to look at [1]. >> Although the more important comparison is likely with the current >> `prototype/fdb-layer` that can be found at [2]. >> >> Given the ebtree aspect, as well as the fact that I get labeled as the >> committer for all commits when doing a rebase I'm also wondering if we >> shouldn't turn this into a merge in this instance. I'll work up a >> second branch that shows that diff as well that we could then rebase >> onto master. >> >> Regardless, I'd appreciate if we could get some eyeballs on the diff >> and then finally merge this work to the default branch so its the main >> line development going forward. >> >> Paul >> >> [1] https://github.com/apache/couchdb/pull/3137 >> [2] >> https://github.com/apache/couchdb/compare/prototype/fdb-layer...prototype/fdb-layer-final-rebase
Re: [DISCUSS] Rename default branch to `main`
I'm +1 in favour of renaming to 'main'. > On 9 Sep 2020, at 18:26, Alessio 'Blaster' Biancalana > wrote: > > I'm not against nor in favor :-D > Words matter but in my opinion git's master was never _that_ master. > Anyway, if it bothers someone... let's do this! > > Concerning open PRs, I don't know, I think original authors can easily > rebase. Also, the next release will cut some stuff open I think, so maybe > we'll find a feasible time slot to do so. > > Alessio > > On Wed, Sep 9, 2020 at 5:40 PM Paul Davis > wrote: > >> Howdy Folks! >> >> Words matter. I've just started a thread on merging all of the >> FoundationDB work into mainline development and thought this would be >> a good time to bring up a separate discussion on renaming our default >> branch. >> >> Personally, I've got a few projects where I used `main` for the >> mainline development branch. I find it to be a fairly natural shift >> because I tab-complete everything on the command line. I'd be open to >> other suggestions but I'm also hoping this doesn't devolve into a >> bikeshed on what we end up picking. >> >> For mechanics, what I'm thinking is that when we finish up the last >> rebase of the FoundationDB work that instead of actually pushing the >> merge/rebase button we just rename the branch and then change the >> default branch on GitHub and close the PR. >> >> Thoughts? >> >> Paul >>
Re: Is it time to merge prototype/fdb-layer to master?
Agree that its time to get the fdb-layer work into master, that's where couchdb 4.0 should be being created. thanks for preserving the imported ebtree history. > On 9 Sep 2020, at 17:28, Paul Davis wrote: > > The merge on this turned out to be a lot more straightforward so I > think its probably the way to go. I've got a failing test in > couch_views_active_tasks_test but it appears to be flaky rather than a > merge error. I'll work though getting `make check` to complete and > then send another update. > > https://github.com/apache/couchdb/tree/prototype/fdb-layer-final-merge > https://github.com/apache/couchdb/commit/873ccb4882f2e984c25f59ad0fd0a0677b9d4477 > > On Wed, Sep 9, 2020 at 10:29 AM Paul Davis > wrote: >> >> Howdy folks! >> >> I've just gone through a rebase of `prototype/fdb-layer` against >> master. Its not quite finished because the ebtree import went wrong >> during rebase due to a weirdness of the history. >> >> I have a PR up for the rebase into master for people to look at [1]. >> Although the more important comparison is likely with the current >> `prototype/fdb-layer` that can be found at [2]. >> >> Given the ebtree aspect, as well as the fact that I get labeled as the >> committer for all commits when doing a rebase I'm also wondering if we >> shouldn't turn this into a merge in this instance. I'll work up a >> second branch that shows that diff as well that we could then rebase >> onto master. >> >> Regardless, I'd appreciate if we could get some eyeballs on the diff >> and then finally merge this work to the default branch so its the main >> line development going forward. >> >> Paul >> >> [1] https://github.com/apache/couchdb/pull/3137 >> [2] >> https://github.com/apache/couchdb/compare/prototype/fdb-layer...prototype/fdb-layer-final-rebase
Re: Announcing Opservatory: 24/7 CouchDB Observation and Analysis
Nice :) > On 9 Sep 2020, at 18:32, Nick Vatamaniuc wrote: > > That looks really nice, Jan. Thanks for sharing! > > On Wed, Sep 9, 2020 at 1:29 PM Alessio 'Blaster' Biancalana > wrote: >> >> Wow, that's _amazing_. I'm glad seeing this kind of effort in an ecosystem >> like the one of CouchDB, cool stuff! >> >> Alessio >> >> On Wed, Sep 9, 2020 at 6:03 PM Jan Lehnardt wrote: >> >>> Dear CouchDB Community, >>> >>> I’m happy to announce Opservatory https://opservatory.app, my company >>> Neighbourhoodie’s latest product for monitoring your CouchDB instances. >>> >>> Opservatory knows CouchDB better than any single human could. We’ve put >>> our combined multi-decade experience with supporting CouchDB >>> installations of all shapes into one tool that makes sure you are not >>> running into any trouble, ever. >>> >>> It continuously monitors your CouchDB installations and runs a number >>> of checks to ensure your CouchDBs are running correctly, fast and >>> securely. It also checks for conditions and configurations that have >>> the potential to cause production issues in the future. >>> >>> It compares metrics against settings to make real-time recommendations >>> for improving your CouchDB instance or cluster. It evaluates >>> configuration, metrics, and database information to ensure smooth >>> operation. It even evaluates your JavaScript code in design documents >>> for common mistakes and performance pitfalls. >>> >>> Here are just a few examples of the checks that Opservatory runs >>> periodically: >>> >>> - If you are just starting out with CouchDB, Opservatory checks if >>> you’ve got any quirks in your setup and configuration and gives you >>> recommendations for well-established best practices for running CouchDB >>> correctly, fast and securely. >>> >>> - If your production cluster ran into trouble and you don’t know >>> where to start looking for things to fix, Opservatory will give you the >>> top list of issues that you can resolve to make your problem(s) go away. >>> >>> - If your intern uploaded a design doc with an inefficient map >>> function (again), Opservatory will let you know, but it also catches >>> more common patterns used by seasoned CouchDB developers that can be >>> improved. >>> >>> - If you create a new database and forget to set the correct >>> _security object, Opservatory will warn you about publicly accessible >>> data that you might want to make private as soon as you get the >>> notification. >>> >>> Opservatory has over 80 checks that cover the five main areas of every >>> CouchDB installation: setup, configuration, metrics, databases and >>> queries/design docs. We have at least as many more in the backlog, and >>> we are constantly adding more as we find more issues during our >>> professional support service work. >>> >>> You can configure Opservatory to receive alerts via email or Slack, and >>> it covers all CouchDB versions: 1.x, 2.x and 3.x. It even works with >>> Cloudant! >>> >>> And while we are very happy with where we are already, we have big >>> plans to make maintaining CouchDB in production even easier with >>> features round capacity planning and seamless growth as well as helping >>> to automate common maintenance tasks safely. >>> >>> If you have any questions, I’m happy to answer off-list. >>> >>> If you think this is interesting, we welcome you to sign up for a free >>> trial at https://opservatory.app. >>> >>> Best >>> Jan >>> — >>> Professional Support for Apache CouchDB: >>> https://neighbourhood.ie/couchdb-support/ >>> >>> 24/7 Observation for your CouchDB Instances: >>> https://opservatory.app >>> >>> >>>
Re: Announcing Opservatory: 24/7 CouchDB Observation and Analysis
That looks really nice, Jan. Thanks for sharing! On Wed, Sep 9, 2020 at 1:29 PM Alessio 'Blaster' Biancalana wrote: > > Wow, that's _amazing_. I'm glad seeing this kind of effort in an ecosystem > like the one of CouchDB, cool stuff! > > Alessio > > On Wed, Sep 9, 2020 at 6:03 PM Jan Lehnardt wrote: > > > Dear CouchDB Community, > > > > I’m happy to announce Opservatory https://opservatory.app, my company > > Neighbourhoodie’s latest product for monitoring your CouchDB instances. > > > > Opservatory knows CouchDB better than any single human could. We’ve put > > our combined multi-decade experience with supporting CouchDB > > installations of all shapes into one tool that makes sure you are not > > running into any trouble, ever. > > > > It continuously monitors your CouchDB installations and runs a number > > of checks to ensure your CouchDBs are running correctly, fast and > > securely. It also checks for conditions and configurations that have > > the potential to cause production issues in the future. > > > > It compares metrics against settings to make real-time recommendations > > for improving your CouchDB instance or cluster. It evaluates > > configuration, metrics, and database information to ensure smooth > > operation. It even evaluates your JavaScript code in design documents > > for common mistakes and performance pitfalls. > > > > Here are just a few examples of the checks that Opservatory runs > > periodically: > > > > - If you are just starting out with CouchDB, Opservatory checks if > > you’ve got any quirks in your setup and configuration and gives you > > recommendations for well-established best practices for running CouchDB > > correctly, fast and securely. > > > > - If your production cluster ran into trouble and you don’t know > > where to start looking for things to fix, Opservatory will give you the > > top list of issues that you can resolve to make your problem(s) go away. > > > > - If your intern uploaded a design doc with an inefficient map > > function (again), Opservatory will let you know, but it also catches > > more common patterns used by seasoned CouchDB developers that can be > > improved. > > > > - If you create a new database and forget to set the correct > > _security object, Opservatory will warn you about publicly accessible > > data that you might want to make private as soon as you get the > > notification. > > > > Opservatory has over 80 checks that cover the five main areas of every > > CouchDB installation: setup, configuration, metrics, databases and > > queries/design docs. We have at least as many more in the backlog, and > > we are constantly adding more as we find more issues during our > > professional support service work. > > > > You can configure Opservatory to receive alerts via email or Slack, and > > it covers all CouchDB versions: 1.x, 2.x and 3.x. It even works with > > Cloudant! > > > > And while we are very happy with where we are already, we have big > > plans to make maintaining CouchDB in production even easier with > > features round capacity planning and seamless growth as well as helping > > to automate common maintenance tasks safely. > > > > If you have any questions, I’m happy to answer off-list. > > > > If you think this is interesting, we welcome you to sign up for a free > > trial at https://opservatory.app. > > > > Best > > Jan > > — > > Professional Support for Apache CouchDB: > > https://neighbourhood.ie/couchdb-support/ > > > > 24/7 Observation for your CouchDB Instances: > > https://opservatory.app > > > > > >
Re: Announcing Opservatory: 24/7 CouchDB Observation and Analysis
Wow, that's _amazing_. I'm glad seeing this kind of effort in an ecosystem like the one of CouchDB, cool stuff! Alessio On Wed, Sep 9, 2020 at 6:03 PM Jan Lehnardt wrote: > Dear CouchDB Community, > > I’m happy to announce Opservatory https://opservatory.app, my company > Neighbourhoodie’s latest product for monitoring your CouchDB instances. > > Opservatory knows CouchDB better than any single human could. We’ve put > our combined multi-decade experience with supporting CouchDB > installations of all shapes into one tool that makes sure you are not > running into any trouble, ever. > > It continuously monitors your CouchDB installations and runs a number > of checks to ensure your CouchDBs are running correctly, fast and > securely. It also checks for conditions and configurations that have > the potential to cause production issues in the future. > > It compares metrics against settings to make real-time recommendations > for improving your CouchDB instance or cluster. It evaluates > configuration, metrics, and database information to ensure smooth > operation. It even evaluates your JavaScript code in design documents > for common mistakes and performance pitfalls. > > Here are just a few examples of the checks that Opservatory runs > periodically: > > - If you are just starting out with CouchDB, Opservatory checks if > you’ve got any quirks in your setup and configuration and gives you > recommendations for well-established best practices for running CouchDB > correctly, fast and securely. > > - If your production cluster ran into trouble and you don’t know > where to start looking for things to fix, Opservatory will give you the > top list of issues that you can resolve to make your problem(s) go away. > > - If your intern uploaded a design doc with an inefficient map > function (again), Opservatory will let you know, but it also catches > more common patterns used by seasoned CouchDB developers that can be > improved. > > - If you create a new database and forget to set the correct > _security object, Opservatory will warn you about publicly accessible > data that you might want to make private as soon as you get the > notification. > > Opservatory has over 80 checks that cover the five main areas of every > CouchDB installation: setup, configuration, metrics, databases and > queries/design docs. We have at least as many more in the backlog, and > we are constantly adding more as we find more issues during our > professional support service work. > > You can configure Opservatory to receive alerts via email or Slack, and > it covers all CouchDB versions: 1.x, 2.x and 3.x. It even works with > Cloudant! > > And while we are very happy with where we are already, we have big > plans to make maintaining CouchDB in production even easier with > features round capacity planning and seamless growth as well as helping > to automate common maintenance tasks safely. > > If you have any questions, I’m happy to answer off-list. > > If you think this is interesting, we welcome you to sign up for a free > trial at https://opservatory.app. > > Best > Jan > — > Professional Support for Apache CouchDB: > https://neighbourhood.ie/couchdb-support/ > > 24/7 Observation for your CouchDB Instances: > https://opservatory.app > > >
Re: [DISCUSS] Rename default branch to `main`
I'm not against nor in favor :-D Words matter but in my opinion git's master was never _that_ master. Anyway, if it bothers someone... let's do this! Concerning open PRs, I don't know, I think original authors can easily rebase. Also, the next release will cut some stuff open I think, so maybe we'll find a feasible time slot to do so. Alessio On Wed, Sep 9, 2020 at 5:40 PM Paul Davis wrote: > Howdy Folks! > > Words matter. I've just started a thread on merging all of the > FoundationDB work into mainline development and thought this would be > a good time to bring up a separate discussion on renaming our default > branch. > > Personally, I've got a few projects where I used `main` for the > mainline development branch. I find it to be a fairly natural shift > because I tab-complete everything on the command line. I'd be open to > other suggestions but I'm also hoping this doesn't devolve into a > bikeshed on what we end up picking. > > For mechanics, what I'm thinking is that when we finish up the last > rebase of the FoundationDB work that instead of actually pushing the > merge/rebase button we just rename the branch and then change the > default branch on GitHub and close the PR. > > Thoughts? > > Paul >
Re: Announcing Opservatory: 24/7 CouchDB Observation and Analysis
Congratulations on the launch, Jan. On 9 September 2020 9:33:26 pm IST, Jan Lehnardt wrote: >Dear CouchDB Community, > >I’m happy to announce Opservatory https://opservatory.app, my company >Neighbourhoodie’s latest product for monitoring your CouchDB instances. > >Opservatory knows CouchDB better than any single human could. We’ve put >our combined multi-decade experience with supporting CouchDB >installations of all shapes into one tool that makes sure you are not >running into any trouble, ever. > >It continuously monitors your CouchDB installations and runs a number >of checks to ensure your CouchDBs are running correctly, fast and >securely. It also checks for conditions and configurations that have >the potential to cause production issues in the future. > >It compares metrics against settings to make real-time recommendations >for improving your CouchDB instance or cluster. It evaluates >configuration, metrics, and database information to ensure smooth >operation. It even evaluates your JavaScript code in design documents >for common mistakes and performance pitfalls. > >Here are just a few examples of the checks that Opservatory runs >periodically: > > - If you are just starting out with CouchDB, Opservatory checks if >you’ve got any quirks in your setup and configuration and gives you >recommendations for well-established best practices for running CouchDB >correctly, fast and securely. > > - If your production cluster ran into trouble and you don’t know >where to start looking for things to fix, Opservatory will give you the >top list of issues that you can resolve to make your problem(s) go >away. > > - If your intern uploaded a design doc with an inefficient map >function (again), Opservatory will let you know, but it also catches >more common patterns used by seasoned CouchDB developers that can be >improved. > > - If you create a new database and forget to set the correct >_security object, Opservatory will warn you about publicly accessible >data that you might want to make private as soon as you get the >notification. > >Opservatory has over 80 checks that cover the five main areas of every >CouchDB installation: setup, configuration, metrics, databases and >queries/design docs. We have at least as many more in the backlog, and >we are constantly adding more as we find more issues during our >professional support service work. > >You can configure Opservatory to receive alerts via email or Slack, and >it covers all CouchDB versions: 1.x, 2.x and 3.x. It even works with >Cloudant! > >And while we are very happy with where we are already, we have big >plans to make maintaining CouchDB in production even easier with >features round capacity planning and seamless growth as well as helping >to automate common maintenance tasks safely. > >If you have any questions, I’m happy to answer off-list. > >If you think this is interesting, we welcome you to sign up for a free >trial at https://opservatory.app. > >Best >Jan >— >Professional Support for Apache CouchDB: >https://neighbourhood.ie/couchdb-support/ > >24/7 Observation for your CouchDB Instances: >https://opservatory.app -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Is it time to merge prototype/fdb-layer to master?
Could we rename prototype/fdb-layer to main and it will be the base of 4.x? There might be a few things we could bring in from master into main like elixir test improvements, tooling, but it would be a smaller diff than bringing everything from prototype/fdb-layer into master. Then master can be renamed to old-master or something like that and we'd see if there are any commits that were intended to go into 3.x but never made it. Once those are moved over, we can delete it too or leave it around for a few years, with a note saying "use main or 3.x" branches. Nick On Wed, Sep 9, 2020 at 12:28 PM Paul Davis wrote: > > The merge on this turned out to be a lot more straightforward so I > think its probably the way to go. I've got a failing test in > couch_views_active_tasks_test but it appears to be flaky rather than a > merge error. I'll work though getting `make check` to complete and > then send another update. > > https://github.com/apache/couchdb/tree/prototype/fdb-layer-final-merge > https://github.com/apache/couchdb/commit/873ccb4882f2e984c25f59ad0fd0a0677b9d4477 > > On Wed, Sep 9, 2020 at 10:29 AM Paul Davis > wrote: > > > > Howdy folks! > > > > I've just gone through a rebase of `prototype/fdb-layer` against > > master. Its not quite finished because the ebtree import went wrong > > during rebase due to a weirdness of the history. > > > > I have a PR up for the rebase into master for people to look at [1]. > > Although the more important comparison is likely with the current > > `prototype/fdb-layer` that can be found at [2]. > > > > Given the ebtree aspect, as well as the fact that I get labeled as the > > committer for all commits when doing a rebase I'm also wondering if we > > shouldn't turn this into a merge in this instance. I'll work up a > > second branch that shows that diff as well that we could then rebase > > onto master. > > > > Regardless, I'd appreciate if we could get some eyeballs on the diff > > and then finally merge this work to the default branch so its the main > > line development going forward. > > > > Paul > > > > [1] https://github.com/apache/couchdb/pull/3137 > > [2] > > https://github.com/apache/couchdb/compare/prototype/fdb-layer...prototype/fdb-layer-final-rebase
Re: [DISCUSS] Rename default branch to `main`
Alexander, Any PRs that aren't trivially rebased against the current prototype/fdb-layer will by definition break regardless of what we call our default branch moving forward. Paul On Wed, Sep 9, 2020 at 11:11 AM Jan Lehnardt wrote: > > I’m in favour and I think the FDB merge is a nice opportunity to take > the plunge. > > Best > Jan > — > > On 9. Sep 2020, at 17:40, Paul Davis wrote: > > > > Howdy Folks! > > > > Words matter. I've just started a thread on merging all of the > > FoundationDB work into mainline development and thought this would be > > a good time to bring up a separate discussion on renaming our default > > branch. > > > > Personally, I've got a few projects where I used `main` for the > > mainline development branch. I find it to be a fairly natural shift > > because I tab-complete everything on the command line. I'd be open to > > other suggestions but I'm also hoping this doesn't devolve into a > > bikeshed on what we end up picking. > > > > For mechanics, what I'm thinking is that when we finish up the last > > rebase of the FoundationDB work that instead of actually pushing the > > merge/rebase button we just rename the branch and then change the > > default branch on GitHub and close the PR. > > > > Thoughts? > > > > Paul >
Re: Is it time to merge prototype/fdb-layer to master?
The merge on this turned out to be a lot more straightforward so I think its probably the way to go. I've got a failing test in couch_views_active_tasks_test but it appears to be flaky rather than a merge error. I'll work though getting `make check` to complete and then send another update. https://github.com/apache/couchdb/tree/prototype/fdb-layer-final-merge https://github.com/apache/couchdb/commit/873ccb4882f2e984c25f59ad0fd0a0677b9d4477 On Wed, Sep 9, 2020 at 10:29 AM Paul Davis wrote: > > Howdy folks! > > I've just gone through a rebase of `prototype/fdb-layer` against > master. Its not quite finished because the ebtree import went wrong > during rebase due to a weirdness of the history. > > I have a PR up for the rebase into master for people to look at [1]. > Although the more important comparison is likely with the current > `prototype/fdb-layer` that can be found at [2]. > > Given the ebtree aspect, as well as the fact that I get labeled as the > committer for all commits when doing a rebase I'm also wondering if we > shouldn't turn this into a merge in this instance. I'll work up a > second branch that shows that diff as well that we could then rebase > onto master. > > Regardless, I'd appreciate if we could get some eyeballs on the diff > and then finally merge this work to the default branch so its the main > line development going forward. > > Paul > > [1] https://github.com/apache/couchdb/pull/3137 > [2] > https://github.com/apache/couchdb/compare/prototype/fdb-layer...prototype/fdb-layer-final-rebase
Re: [DISCUSS] Rename default branch to `main`
I’m in favour and I think the FDB merge is a nice opportunity to take the plunge. Best Jan — > On 9. Sep 2020, at 17:40, Paul Davis wrote: > > Howdy Folks! > > Words matter. I've just started a thread on merging all of the > FoundationDB work into mainline development and thought this would be > a good time to bring up a separate discussion on renaming our default > branch. > > Personally, I've got a few projects where I used `main` for the > mainline development branch. I find it to be a fairly natural shift > because I tab-complete everything on the command line. I'd be open to > other suggestions but I'm also hoping this doesn't devolve into a > bikeshed on what we end up picking. > > For mechanics, what I'm thinking is that when we finish up the last > rebase of the FoundationDB work that instead of actually pushing the > merge/rebase button we just rename the branch and then change the > default branch on GitHub and close the PR. > > Thoughts? > > Paul
Re: [DISCUSS] Rename default branch to `main`
This obviously will break all the current PR to master branch just because of naming. Is it worth this? What problems renaming will solve? And why does that suddenly become important? -- ,,,^..^,,, On Wed, Sep 9, 2020 at 6:40 PM Paul Davis wrote: > Howdy Folks! > > Words matter. I've just started a thread on merging all of the > FoundationDB work into mainline development and thought this would be > a good time to bring up a separate discussion on renaming our default > branch. > > Personally, I've got a few projects where I used `main` for the > mainline development branch. I find it to be a fairly natural shift > because I tab-complete everything on the command line. I'd be open to > other suggestions but I'm also hoping this doesn't devolve into a > bikeshed on what we end up picking. > > For mechanics, what I'm thinking is that when we finish up the last > rebase of the FoundationDB work that instead of actually pushing the > merge/rebase button we just rename the branch and then change the > default branch on GitHub and close the PR. > > Thoughts? > > Paul >
Announcing Opservatory: 24/7 CouchDB Observation and Analysis
Dear CouchDB Community, I’m happy to announce Opservatory https://opservatory.app, my company Neighbourhoodie’s latest product for monitoring your CouchDB instances. Opservatory knows CouchDB better than any single human could. We’ve put our combined multi-decade experience with supporting CouchDB installations of all shapes into one tool that makes sure you are not running into any trouble, ever. It continuously monitors your CouchDB installations and runs a number of checks to ensure your CouchDBs are running correctly, fast and securely. It also checks for conditions and configurations that have the potential to cause production issues in the future. It compares metrics against settings to make real-time recommendations for improving your CouchDB instance or cluster. It evaluates configuration, metrics, and database information to ensure smooth operation. It even evaluates your JavaScript code in design documents for common mistakes and performance pitfalls. Here are just a few examples of the checks that Opservatory runs periodically: - If you are just starting out with CouchDB, Opservatory checks if you’ve got any quirks in your setup and configuration and gives you recommendations for well-established best practices for running CouchDB correctly, fast and securely. - If your production cluster ran into trouble and you don’t know where to start looking for things to fix, Opservatory will give you the top list of issues that you can resolve to make your problem(s) go away. - If your intern uploaded a design doc with an inefficient map function (again), Opservatory will let you know, but it also catches more common patterns used by seasoned CouchDB developers that can be improved. - If you create a new database and forget to set the correct _security object, Opservatory will warn you about publicly accessible data that you might want to make private as soon as you get the notification. Opservatory has over 80 checks that cover the five main areas of every CouchDB installation: setup, configuration, metrics, databases and queries/design docs. We have at least as many more in the backlog, and we are constantly adding more as we find more issues during our professional support service work. You can configure Opservatory to receive alerts via email or Slack, and it covers all CouchDB versions: 1.x, 2.x and 3.x. It even works with Cloudant! And while we are very happy with where we are already, we have big plans to make maintaining CouchDB in production even easier with features round capacity planning and seamless growth as well as helping to automate common maintenance tasks safely. If you have any questions, I’m happy to answer off-list. If you think this is interesting, we welcome you to sign up for a free trial at https://opservatory.app. Best Jan — Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/ 24/7 Observation for your CouchDB Instances: https://opservatory.app
[DISCUSS] Rename default branch to `main`
Howdy Folks! Words matter. I've just started a thread on merging all of the FoundationDB work into mainline development and thought this would be a good time to bring up a separate discussion on renaming our default branch. Personally, I've got a few projects where I used `main` for the mainline development branch. I find it to be a fairly natural shift because I tab-complete everything on the command line. I'd be open to other suggestions but I'm also hoping this doesn't devolve into a bikeshed on what we end up picking. For mechanics, what I'm thinking is that when we finish up the last rebase of the FoundationDB work that instead of actually pushing the merge/rebase button we just rename the branch and then change the default branch on GitHub and close the PR. Thoughts? Paul
Is it time to merge prototype/fdb-layer to master?
Howdy folks! I've just gone through a rebase of `prototype/fdb-layer` against master. Its not quite finished because the ebtree import went wrong during rebase due to a weirdness of the history. I have a PR up for the rebase into master for people to look at [1]. Although the more important comparison is likely with the current `prototype/fdb-layer` that can be found at [2]. Given the ebtree aspect, as well as the fact that I get labeled as the committer for all commits when doing a rebase I'm also wondering if we shouldn't turn this into a merge in this instance. I'll work up a second branch that shows that diff as well that we could then rebase onto master. Regardless, I'd appreciate if we could get some eyeballs on the diff and then finally merge this work to the default branch so its the main line development going forward. Paul [1] https://github.com/apache/couchdb/pull/3137 [2] https://github.com/apache/couchdb/compare/prototype/fdb-layer...prototype/fdb-layer-final-rebase
