couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Git Repository Creation
Date Wed, 22 Jan 2014 10:19:49 GMT
On Tue, Jan 21, 2014 at 3:25 PM, Robert Samuel Newson <rnewson@apache.org>wrote:

> Definitely need to preserve R14 compatibility, that’s still the most
> stable recent series (as long as you don’t use R14B02)…
>


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).

Imo we should upgrade as soon as possible to a version > R15 if we want to
follow the latest changes and be used by others. It is also expected that
all external libraries upgrade to a more recent version and not a surprise
that the latest version of mochiweb increased the requirements too. If
someone still want to use an old Erlang version then it will have to use
the latest version of couchdb that support it that's all. But a new major
version should make sure to use the latest stable and supported version.

 - benoit

>
> On 21 Jan 2014, at 14:12, Adam Kocoloski <kocolosk@apache.org> wrote:
>
> > On Jan 21, 2014, at 9:00 AM, Dave Cottlehuber <dch@jsonified.com> wrote:
> >
> >>> On 21. Jänner 2014 at 10:20:58, Paul Davis (
> paul.joseph.davis@gmail.com) wrote:
> >>> ...
> >>> As to bigcouch/rcouch conflicts its something we'll need to
> >>> figure out
> >>> for sure. I don't really see much point in trying to create
> >>> bigcouch/rcouch specific branches for the initial import though.
> >>> I did
> >>> include bigcouch merge related patches on both of couch and
> >>> couch_replicator cause I was worried about the history extraction.
> >>>
> >>> The "proper" approach I think is to go back and reset each repo
> >>> to the
> >>> equivalent commit pointed at by the merge-rebase-target tag
> >>> and then
> >>> we should create branches 1843-feature-bigcouch and 1994-merge-rcouch
> >>> branches in each repo where we have conflicts. Once that's done
> >>> we can
> >>> focus on the actual conflicts to see where we need to work on merging
> >>> actual code changes. The important part here is to have a common
> >>> history for each sub-repo we agree on that is the initial import
> >>> and
> >>> then we can focus on the merge work at hand.
> >>>
> >>> For the upstream repos I need to add some more work to those to
> >>> reflect changes that we've made since march of this year when
> >>> we
> >>> started the bigcouch merge. I definitely agree that we should
> >>> be
> >>> pushing our changes upstream so that these are as close to raw
> >>> mirrors
> >>> as possible. The ibrowse and mochiweb branches were direct from
> >>> upstream repos and I think I pulled oauth from the rcouch repo.
> >>> The
> >>> mochiweb commit was super old but ibrowse was relatively close.
> >>> I know
> >>> we've changed things here recently and we'll want to get as much
> >>> of
> >>> that upstream as possible.
> >>>
> >>> I'm going to be digging back into this work at the end of the week
> >>> or
> >>> early next week. Let me know if you find anything else that needs
> >>> to
> >>> be addressed.
> >>>
> >>
> >> WRT to Mochiweb, moving to a later upstream requires us to drop < R15B
> compatibility I think. rcouch is ok with current Erlang, what is your
> opinion wrt to bigcouch?
> >>
> >> --
> >> Dave Cottlehuber
> >> Sent from my PDP11
> >
> > We've not run in production using the current Erlang.  I think jiffy
> needs a small update to make sure it yields properly to avoid the issues
> with the scheduler collapse issues that have plagued R15 and R16.
> >
> > It's a bit awkward if there's no release of mochiweb that bridges the
> gap.
> >
> > Adam
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message