Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 209.85.216.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <etPan.52dfc3ef.19495cff.aa01@akai.jsonified.com>
References: 
 <CAJ_m3YDruu=0P-dQZiQwDAp4ac=zXRrqwA9bMa+nJWW0ZRayWA@mail.gmail.com>
 <CAJNb-9oFctms3MVmsMV6jYdRSc3trWsp-b_Y22PAP0kQ+K_vkg@mail.gmail.com>
 <CAJ_m3YAGOSQ2Pcj4_Eqr_e-sPCQ0CO3RMEgqCG=OM51vimzBAQ@mail.gmail.com>
 <etPan.52de7d64.46e87ccd.15f6@akai.jsonified.com>
 <E1556D94-B196-4DE9-A2D6-30284F80F685@apache.org>
 <06B0A74C-D886-481B-92CC-548B7A05E327@apache.org>
 <CAJNb-9ru4pUwPZV3VjEq1zBAUeHEBrKJo1BjEH752RdpwpkDiA@mail.gmail.com>
 <CAHdjipKzPoEH=J9G0bS5S5-3T9Gh+NcsEB0z9TAWfuN7Fx5Ujg@mail.gmail.com>
 <CAJNb-9rC3URBkcC4yKY4cLE+QgZg_0xb3K7M4V1au9N+JM15XQ@mail.gmail.com>
 <CAHdjip+yZS+hW5OxN_7+AKEv5XfXZpA_x7rj9bmDS6m8X=G5=Q@mail.gmail.com>
 <A62DAF5E-517A-47BB-9679-1BFC25B51042@apache.org>
 <etPan.52dfc3ef.19495cff.aa01@akai.jsonified.com>
From: Benoit Chesneau <bchesneau@gmail.com>
Date: Wed, 22 Jan 2014 14:54:07 +0100
Message-ID: 
 <CAJNb-9ozd=tJRHWN1phbB0hS2tsM-e1xaXLy+86G4uEg41xLAw@mail.gmail.com>
Subject: Re: Migration Strategy [was Re: Git Repository Creation]
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=001a11c137e495e91704f08f7647

--001a11c137e495e91704f08f7647
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I am +1 in the order of priorities. Some comments bellow.


On Wed, Jan 22, 2014 at 2:13 PM, Dave Cottlehuber <dch@jsonified.com> wrote=
:

> On 22. J=E4nner 2014 at 12:42:03, Robert Samuel Newson (rnewson@apache.or=
g)
> wrote:
> >
> > Benoit,
> >
> > Cloudant requires R14 support, it would mean our contribution
> > to couchdb becomes useless to us and we could not contribute further.
> >
> > B.
> > ...
> > >>> wrote:
> > >>>> On Tue, Jan 21, 2014 at 3:25 PM, Robert Samuel Newson <
> > >>> rnewson@apache.org>wrote:
> > >>>>
> > >>>>> Definitely need to preserve R14 compatibility, that=92s
> > still the most
> > >>>>> stable recent series (as long as you don=92t use R14B02)=85
> > >>>>>
> > >>>>
> > >>>>
> > >>>> I disagree. R14 hasn't been updated since more than 2 years,
> > and isn't a
> > >>>> supported version by the Erlang community, R17 will be out
> > sometimes
> > >>> during
> > >>>> the spring. Latest versions added many fixes to SSL, improved
> > the
> > >>>> scheduling and memory usage, the NIF support and added a
> > lot of
> > >>>> improvements to the binary API. Also latest stables version
> > of different
> > >>>> distributions don't have any R14 any more (even RHEL).
> > =85
>
> Hopefully I captured all the key points here;
>
> TL;DR I suggest we:
>
> - finish merges as a priority
> - ship a merged release that still supports R14B*
> - track things that need newer OTP in a JIRA ticket & deal with them afte=
r
> merge release
> - resolve aged distro problems with ESL packages & OTP releases in future
>
> There are alternatives, obviously to this, such as running 2 separate
> branches
> (2.x cluster, and 1.x feature non-clustered) for a while but that feels
> too heavy
> for the project to me.
>
> Have I missed anything, does this work for everybody? Any better
> approaches?
>
> ## Project Priorities
>
> 1. We are in the middle of major merging. Let=92s finish that first. Unle=
ss
> I=92ve missed something, all current code in the tree (rcouch + bigcouch =
+
> couch couch)
> is still R14B* compatible.
>
>
I am unsure about R14 compatibility of anything I wrote recently and it
probably isn't for some stuff, we had to raise the requirements last year
due to incompatibilities issues in rcouch. I will try to check. need to
find an R14 release somewhere first.


> ## OTP Compatibility & support
>
> 2. R14 is going to hold both the project & users like Cloudant back soone=
r
> or later
>         via dependencies e.g. mochiweb
>         via functionality in core OTP e.g. SSL improvements, native JSON
> parsing & maps
>         via bug fixes (lots wrt to Windows in R15+, or unix TCP socket
> support)
>
> Specifically for mochiweb (and websocket support as the interesting
> feature) I suspect
> this could be patchable to work on R14B04.
>

Sure we can patch anything. But that imply to maintain a fork, The question
is not as innocent as it seems and should be answered. I personally dislike
having to maintain a fork. How do we keep updated the fork? How do we
maintain the versioning against upstream?

Also is maintaining a fork the real solution compared to adapt our code to
work with latest releases and keep the stability?


>
> 3. R15* & at least R16B01 and under are still prone to scheduler collapse=
.
> I am not sure if the
> =93+st <msecs> " hack in R16B02+ eases the pain or not, nor how badly thi=
s
> impacts heavy
> CouchDB users. This is the =93wake up all schedulers every <milliseconds>=
 to
> prevent collapse"
> issue. Read Scott Fritchie=92s threads in Erlang-Questions [1] for detail=
s &
> erl man[2].
>
>
Mmm the link you refer say it is still better than in R14. Anyway this is
the right path to follow, we should collect any issues we have in mind in
using latest supported versions of Erlang and see how it impact us.


> 4. Distros range from bleeding (arch, gentoo etc) to decaying (LTS Ubuntu=
,
> Centos etc). I
> think the general feeling (not quite a consensus) is that you can work
> around this by
> installing a current Erlang/OTP for most systems from Erlang Solutions,
> and you=92re done.
> To me this feels like a release notes issue, not one we should be using a=
s
> a reason to
> hold back progress. IMO post merges this will also be resolved as erlang
> releases can
> be generated.
>
> Are there any other points to be considered?
>


How long do we want to support R14? How to decide to stop its support? We
need a check-list.
How to support coming R17? Do we want it?
In a world where we have couchdb spitted in multiple repository and
embeddable in other Erlang applications, do we really want to force users
to use our own forked repository? How to make sure they can eventually
switch to the upstream one?

- benoit

--001a11c137e495e91704f08f7647--