couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: [PLEASE READ] CouchDB 3.0 Update - Jan 30
Date Fri, 31 Jan 2020 16:42:03 GMT
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 <wohali@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
> 

Mime
View raw message