OK Adam, just remember that CI needs to be rejiggered to work for this
scenario, as `master` is protected. A minimum is a functional
Jenkinsfile.pr that runs FDB during `make check`, I presume. Ideally,
we'd get Jenkinsfile.full working, too, but that's probably a larger
task. (I need a break ;) )
-Joan
On 2020-01-30 21:23, Adam Kocoloski wrote:
Hi Joan,
I think moving the FDB work to master and having a 3.x branch is a good idea.
Cheers,
Adam
On Jan 30, 2020, at 5:58 PM, Joan Touzet <woh...@apache.org> wrote:
Hi everyone,
We are finally past our blockers for 3.0.0. The beam hang in Erlang 21 and 22
seems to be worked around by not raising the priority of the couch_server
process to high. An upstream bug has been filed with Erlang to resolve this;
until that get patched and merged, and we blacklist the bad Erlang releases,
we're disabling the priority raise.
There are only minor documentation, packaging and build changes left to make. I
predict RC1 will be cut next week.
I intend to fork a 3.0.x branch off of master very soon - possibly *tomorrow*.
If anyone has any reason why this shouldn't happen, please speak now.
This means if you want anything to end up in CouchDB 3.0.0, this is the final
call to clean up and merge your PRs ASAP.
If you have patches that affect CouchDB, this means that patches may have to be
PR'ed *twice*, once for the 3.0.x branch and once for master.
Remember, once FDB work hits master, we'll be in a situation where patches may
be landing on multiple branches (if they affect both FDB and non-FDB CouchDB)
or may only end up on a 3.* branch.
Because of this, do we want to fork now as "3.x", and then fork 3.0.x off of
that? Basically, we'd treat 3.x as our new 'master' for merging anything non-FDB, and
open up master for FDB releases. If FDB landing on master isn't a priority, we can
continue with our traditional forking of 3.1.x, 3.2.x, etc. off of master until FDB is
ready to land there.
-Joan
