Heya Joan,

Barring any substantial extra work to keep CI going on the 3.x branch as it 
would on master, I think branching off 3.x now, cutting 3.0.0 from that and 
continuing with FDB wok on master is a good way forward.

Best
Jan
—

> On 30. Jan 2020, at 23:58, 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

Reply via email to