Maintainig two codebases

[Ilya Khlopotov <ii...@apache.org>]

There are ongoing discussions about rebasing CouchDB on top of FoundationDB. It seems like the community is in agreement that it is worth it to try. This would mean that we would be supporting and extending two quite separate codebases. How are we going to do it? 

Possible options are:
- brand new repository
- separate branch which we would treat as master for FDB rebase project

I think that separate branch approach has a number of disadvantages:
- CI might require different dependencies
- It would be awkward to open GH issues since we would have to always refer to the project we are talking about
- There would be little friction when we open PR since the correct base branch would need to be selected

Best regards,
iilyak

Re: Maintainig two codebases

[Jan Lehnardt <ja...@apache.org>]

> On 1. Mar 2019, at 15:26, Robert Newson <rn...@apache.org> wrote:
> 
> Hi,
> 
> The first decision is to what extent we are supporting the "old" version (once the new one exists, of course). I think it would be limited to security fixes.

Eventually yes, but I can imagine a grace period for bugfix release before go to security-only. Reality might not require it, but I don’t want to close the door on this just yet. Either way tho, this doesn’t change the discussion at hand.

> If so, this is exactly the same as when we released 1.2, 1.3, and so on. Master is always latest (FDB, in this case) and there are branches like 1.2.x or 2.0.x if we need to backport security fixes to make a release there.

One special case is that we are now effectively doing 3.0 and 4.0 in parallel for a bit until 3.0 is out. We just need to decide which version stays in-branch until 3.x is out. I don’t think there is a clear winner either way.

To deal with the PR awkwardness, we could fork current master into a new repo, make that FDB CouchDB, and when 3.x ships and gets its 3.x.x branch we merge the other repo back as master, maybe via a special case where FDB CouchDB master straight out replaces then current couchdb.git master, and that master is moved to 3.x.x. Will need some ASF Infra help obvs. I would want to avoid having to merge things back and forth for anything that isn’t kept around (chttpd, replicator, etc), as nice as Nebraska is, I wouldn’t want to put anyone through a big merge bonanza again.

Best
Jan
—

> 
> B.
> 
> -- 
>  Robert Samuel Newson
>  rnewson@apache.org
> 
> On Fri, 1 Mar 2019, at 13:49, Ilya Khlopotov wrote:
>> There are ongoing discussions about rebasing CouchDB on top of 
>> FoundationDB. It seems like the community is in agreement that it is 
>> worth it to try. This would mean that we would be supporting and 
>> extending two quite separate codebases. How are we going to do it? 
>> 
>> Possible options are:
>> - brand new repository
>> - separate branch which we would treat as master for FDB rebase project
>> 
>> I think that separate branch approach has a number of disadvantages:
>> - CI might require different dependencies
>> - It would be awkward to open GH issues since we would have to always 
>> refer to the project we are talking about
>> - There would be little friction when we open PR since the correct base 
>> branch would need to be selected
>> 
>> Best regards,
>> iilyak
>> 

-- 
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/

Re: Maintainig two codebases

[Robert Newson <rn...@apache.org>]

Hi,

The first decision is to what extent we are supporting the "old" version (once the new one exists, of course). I think it would be limited to security fixes. If so, this is exactly the same as when we released 1.2, 1.3, and so on. Master is always latest (FDB, in this case) and there are branches like 1.2.x or 2.0.x if we need to backport security fixes to make a release there.

B.

-- 
  Robert Samuel Newson
  rnewson@apache.org

On Fri, 1 Mar 2019, at 13:49, Ilya Khlopotov wrote:
> There are ongoing discussions about rebasing CouchDB on top of 
> FoundationDB. It seems like the community is in agreement that it is 
> worth it to try. This would mean that we would be supporting and 
> extending two quite separate codebases. How are we going to do it? 
> 
> Possible options are:
> - brand new repository
> - separate branch which we would treat as master for FDB rebase project
> 
> I think that separate branch approach has a number of disadvantages:
> - CI might require different dependencies
> - It would be awkward to open GH issues since we would have to always 
> refer to the project we are talking about
> - There would be little friction when we open PR since the correct base 
> branch would need to be selected
> 
> Best regards,
> iilyak
>