Re: [VOTE] Release Apache CouchDB 3.1.1
All - this vote is CANCELLED due to a late-breaking bug found by Paul and fixed by Robert: Fix buffer_response=true (#3145) #3147 I will cut a new RC tomorrow. On 2020-09-10 1:25 p.m., Joan Touzet wrote: Dear community, I would like to propose that we release Apache CouchDB 3.1.1. Candidate release notes: https://docs.couchdb.org/en/latest/whatsnew/3.1.html We encourage the whole community to download and test these release artefacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so dig right in! (Only PMC members have binding votes, but they depend on community feedback to gauge if an official release is ready to be made.) The release artefacts we are voting on are available here: https://dist.apache.org/repos/dist/dev/couchdb/source/3.1.1/rc.1/ There, you will find a tarball, a GPG signature, and SHA256/SHA512 checksums. Please follow the test procedure here: https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release Please remember that "RC1" is an annotation. If the vote passes, these artefacts will be released as Apache CouchDB 3.1.1. Please cast your votes now. Thanks,
Re: Notification of analysis on publicly available project data
Hello Miss Cuevas: please be more specific about what project? On Thu, 10 Sep 2020, 11:49 Griselda Cuevas, wrote: > Dear PMC, > > > I’m contacting you because your project has been selected by the ASF D > committee which is leading a research project to evaluate and understand > the current state of diversity in our community [1]. As part of this > research, we will analyze publicly available data about your project such > as Git logs, Jira boards and mailing lists, to better understand the state > of diversity in Apache projects and to complement the findings we obtained > from the Community Survey that was run this year [2]. > > > This analysis will be performed by Bitegia [3], a vendor specializing in > researching open source projects and foundations. The results will be > published in a report similar to the OpenStack Foundation Analysis > published in 2018 [4]. > > > The analysis will be done only on aggregated data at the project level > during > and after processing, ensuring we do not report anything that could > identify a single individual. The data we analyze will be deleted right > after the research is done and won’t be retained by either the researcher > or the ASF. > > > If you have any concerns or questions, please raise them to the diversity > committee (d...@diversity.apache.org) and/or to the data privacy committee > ( > priv...@apache.org). > > > Regards, > > Griselda Cuevas > > V.P. of Diversity and Inclusion > > Apache Software Foundation > > > [1] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405614 > > [2] https://youtu.be/4Mr1CRtKqUI > > [3] https://bitergia.com/bitergia-analytics/ > > [4] https://superuser.openstack.org/articles/2018-gender-diversity-report/ >
Re: Is it time to merge prototype/fdb-layer to master?
Cool. I'm certain we're overlooking something but I'm too tired to think of it today. FYI once the copy is done you can tell Infra to change the default branch for each repo on those and they will do so quickly, with no fuss. -Joan On 2020-09-10 4:13 p.m., Paul Davis wrote: I should have noted, for each of the `apache/couchdb-$repo` repositories my plan is to do a straight up copy of master -> main with zero other changes. Once that's done we'll need to update rebar.config.script but that should be all we need there. On Thu, Sep 10, 2020 at 3:11 PM Paul Davis wrote: So I've gotten `make check` passing against a merge of master into the `prototype/fdb-layer` branch. I ended up finding a flaky test and a bug in a recent commit to master. I've just merged a fix for the flaky test and Bob is working on a patch for the buffered_response feature. Once those are both merged I'll re-run the merge and name that branch `main`. Once that happens we'll need to work through a to-do list. Things I know that are on that list: 1. File infra ticket to have them change our GitHub setting for the default branch to `main`. 2. Copy branch protection rules from `master` to `main` 3. Steps 1 and 2 for all our `apache/couchdb-$repo` repositories 4. Update Jenkins config 5. Figure out FreeBSD builder situation 6. Probably other stuff 7. Eventually rename current `master` to something else so as to avoid confusion Assuming no one objects beforehand, I'll start the ball rolling with Infra on Monday. Paul On Wed, Sep 9, 2020 at 1:11 PM Joan Touzet wrote: 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: Is it time to merge prototype/fdb-layer to master?
I should have noted, for each of the `apache/couchdb-$repo` repositories my plan is to do a straight up copy of master -> main with zero other changes. Once that's done we'll need to update rebar.config.script but that should be all we need there. On Thu, Sep 10, 2020 at 3:11 PM Paul Davis wrote: > > So I've gotten `make check` passing against a merge of master into the > `prototype/fdb-layer` branch. I ended up finding a flaky test and a > bug in a recent commit to master. I've just merged a fix for the flaky > test and Bob is working on a patch for the buffered_response feature. > > Once those are both merged I'll re-run the merge and name that branch `main`. > > Once that happens we'll need to work through a to-do list. Things I > know that are on that list: > > 1. File infra ticket to have them change our GitHub setting for the > default branch to `main`. > 2. Copy branch protection rules from `master` to `main` > 3. Steps 1 and 2 for all our `apache/couchdb-$repo` repositories > 4. Update Jenkins config > 5. Figure out FreeBSD builder situation > 6. Probably other stuff > 7. Eventually rename current `master` to something else so as to avoid > confusion > > Assuming no one objects beforehand, I'll start the ball rolling with > Infra on Monday. > > Paul > > On Wed, Sep 9, 2020 at 1:11 PM Joan Touzet wrote: > > > > 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: Is it time to merge prototype/fdb-layer to master?
So I've gotten `make check` passing against a merge of master into the `prototype/fdb-layer` branch. I ended up finding a flaky test and a bug in a recent commit to master. I've just merged a fix for the flaky test and Bob is working on a patch for the buffered_response feature. Once those are both merged I'll re-run the merge and name that branch `main`. Once that happens we'll need to work through a to-do list. Things I know that are on that list: 1. File infra ticket to have them change our GitHub setting for the default branch to `main`. 2. Copy branch protection rules from `master` to `main` 3. Steps 1 and 2 for all our `apache/couchdb-$repo` repositories 4. Update Jenkins config 5. Figure out FreeBSD builder situation 6. Probably other stuff 7. Eventually rename current `master` to something else so as to avoid confusion Assuming no one objects beforehand, I'll start the ball rolling with Infra on Monday. Paul On Wed, Sep 9, 2020 at 1:11 PM Joan Touzet wrote: > > 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 > >
[VOTE] Release Apache CouchDB 3.1.1
Dear community, I would like to propose that we release Apache CouchDB 3.1.1. Candidate release notes: https://docs.couchdb.org/en/latest/whatsnew/3.1.html We encourage the whole community to download and test these release artefacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so dig right in! (Only PMC members have binding votes, but they depend on community feedback to gauge if an official release is ready to be made.) The release artefacts we are voting on are available here: https://dist.apache.org/repos/dist/dev/couchdb/source/3.1.1/rc.1/ There, you will find a tarball, a GPG signature, and SHA256/SHA512 checksums. Please follow the test procedure here: https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release Please remember that "RC1" is an annotation. If the vote passes, these artefacts will be released as Apache CouchDB 3.1.1. Please cast your votes now. Thanks,
svn commit: r41408 - in /dev/couchdb/source/3.1.1: ./ rc.1/ rc.1/apache-couchdb-3.1.1-RC1.tar.gz rc.1/apache-couchdb-3.1.1-RC1.tar.gz.asc rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha256 rc.1/apache-couchd
Author: wohali Date: Thu Sep 10 17:22:08 2020 New Revision: 41408 Log: Adding CouchDB 3.1.1-RC1 to dev tree Added: dev/couchdb/source/3.1.1/ dev/couchdb/source/3.1.1/rc.1/ dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz (with props) dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.asc (with props) dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha256 (with props) dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha512 (with props) Added: dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz == Binary file - no diff available. Propchange: dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz -- svn:mime-type = application/octet-stream Added: dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.asc == --- dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.asc (added) +++ dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.asc Thu Sep 10 17:22:08 2020 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEELseIrj8jn6E+gtIVzecRKJOErjcFAl9aX9YACgkQzecRKJOE +rjdTXg/+KtjTb2zAmLR1RW1aXeSZpgwauxi8k+oUlNlXQF/QBFiOgsSzjKoPnrPe +VCQ8clKGg0ou9rhLud63K+j0Q24w16KSypncpQlDAbl0knqeqUiLRXXovD26y72A +NJOdZhir9+BBEIPjXfMvGP744HI6miCDluuXKXTtoe/SDcTionKFJOJTJuPXXXop +gPBSRQbgIzBjaYPduxALJG3xZN0ORKynMwWhgCp7tDdl9QMBWrn0leadMLiZ3NXu +r/6MOKIxP6BhAZjccjXpoqt8O9ZpzG0LNjyZtTz/2XcEvAtk0SWinYZBRdCHocAK +FypRBXs7AlNOXzOfCXEkEQ0sfpeFArBr58ypLE4V3OEUWD3b+4HUy1QnFdpE82Gq +fuX/txq6hQkaxQiyi07Yid5PV6sNVRWTrwSnYqTOvvtZO4uabfh/X08UBhNTN0jt +rHyS8FzEDy4RyDz13cSf+2lKUMm7MvxihMwFA31prGAZXrp7BYeO2ueqZwa4BQ0z +Igtk/M5uk2+rmnPQYj1F7Fp8J/QcCzz+gLtOoZ4P4lNKrAsWAFNUzXDxD07ndVCG +rp58JUPYpEJmrPVj1vSyeRaztsYC7L1nHo+1rnSXGNFjOS+ya84/akih8BZ6lF9O +CDfPtvJlJKrAt1hcLEWVuG3eTtrVQ1fR7VZuSGHMjb/wLkwI/ao= +=RjYg +-END PGP SIGNATURE- Propchange: dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.asc -- svn:mime-type = text/plain Added: dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha256 == --- dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha256 (added) +++ dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha256 Thu Sep 10 17:22:08 2020 @@ -0,0 +1 @@ +afc8603ff0706e40ec39636275dd96a0e90af7b8c512723bd53e596fb1ffa0c5 apache-couchdb-3.1.1-RC1.tar.gz Propchange: dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha256 -- svn:mime-type = text/plain Added: dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha512 == --- dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha512 (added) +++ dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha512 Thu Sep 10 17:22:08 2020 @@ -0,0 +1 @@ +bf274c604faf47dcc8b8490320f4cd1347eca85695ae31ea79280145a7b0c9c7b681461c22778ab918858ea565440cc385761d4e7c55a2c0875462b5b6235019 apache-couchdb-3.1.1-RC1.tar.gz Propchange: dev/couchdb/source/3.1.1/rc.1/apache-couchdb-3.1.1-RC1.tar.gz.sha512 -- svn:mime-type = text/plain
Notification of analysis on publicly available project data
Dear PMC, I’m contacting you because your project has been selected by the ASF D committee which is leading a research project to evaluate and understand the current state of diversity in our community [1]. As part of this research, we will analyze publicly available data about your project such as Git logs, Jira boards and mailing lists, to better understand the state of diversity in Apache projects and to complement the findings we obtained from the Community Survey that was run this year [2]. This analysis will be performed by Bitegia [3], a vendor specializing in researching open source projects and foundations. The results will be published in a report similar to the OpenStack Foundation Analysis published in 2018 [4]. The analysis will be done only on aggregated data at the project level during and after processing, ensuring we do not report anything that could identify a single individual. The data we analyze will be deleted right after the research is done and won’t be retained by either the researcher or the ASF. If you have any concerns or questions, please raise them to the diversity committee (d...@diversity.apache.org) and/or to the data privacy committee ( priv...@apache.org). Regards, Griselda Cuevas V.P. of Diversity and Inclusion Apache Software Foundation [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405614 [2] https://youtu.be/4Mr1CRtKqUI [3] https://bitergia.com/bitergia-analytics/ [4] https://superuser.openstack.org/articles/2018-gender-diversity-report/
Re: Announcing Opservatory: 24/7 CouchDB Observation and Analysis
Hey Jan and folks at Neighbourhoodie. This is awesome. Congratulations All the best Andy -- Andy Wenk Hamburg GPG fingerprint C32E 275F BCF3 9DF6 4E55 21BD 45D3 5653 77F9 3D29 > On 9. Sep 2020, at 20:03, Robert Samuel Newson wrote: > > 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: [DISCUSS] Rename default branch to `main`
strong +1 here at sum.cumo we also change the “master” branches to main Best Andy -- Andy Wenk Hamburg GPG fingerprint C32E 275F BCF3 9DF6 4E55 21BD 45D3 5653 77F9 3D29 > On 9. Sep 2020, at 20:09, Joan Touzet wrote: > > +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`
On Wed, Sep 9, 2020 at 8:09 PM Joan Touzet wrote: > 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 > Wow, that's really history, thanks for bringing back memories :D 'trunk' is very SVN-ish :-))) Alessio
