couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <>
Subject Re: A quick status about the merge of rcouch
Date Fri, 10 Jan 2014 12:59:06 GMT

My concern with external dependencies is that our release tarballs become unusable when github
is down (which is often) or if those projects mutate. The Maven approach is different to the
rebar deps one, an non-SNAPSHOT dependency on a Maven repo is immutable and permanent by design.
Nothing stops the jiffy/mochiweb/etc maintainer from deleting the repository or removing a

However, the most immediate issue is the ability to maintain patches against them, so let’s
focus there. I certainly don’t think it would be wise for us to require upstream maintainers
to take our patches before we can make them. The SOCKS5 patch is particularly interesting.
The upstream project has added it independently but in ways that break the intention behind
ours. Given the security aspects of the differences (DNS leaks), pointing to an external repository
feels far too risk for me. 

For these reasons, I’d rather we include the source we use, and git makes it straightforward
to import upstream release on our own schedule (which I freely admit we don’t do very often),
and with our explicit action and ability to review them.

lock-rebar-deps appears only to convert the tag or branch we’re pointing at to an explicit
commit id. That’s a help, but not enough imo.


On 10 Jan 2014, at 12:39, Benoit Chesneau <> wrote:

> On Fri, Jan 10, 2014 at 1:36 PM, Robert Samuel Newson <>wrote:
>> "all externals dependencies (mochiweb, jiffy, erlang-oauth, ibrowse,
>> snappy) has been removed from our source"
>> CouchDB has patches against some of these, how are you preserving them?
> mochiweb has already most of them in latest upstream. Some better from ours.
> ibrowse yes. I didn't port yet the socks5 one.
> snappy . yes from the start.
> erlang-oauth - yes
> jiffy : well this is the latest
>> I think the topic of whether our dependencies should be included, as they
>> have been to date, or pulled from external sources is one we should have a
>> group.
> agree. Note that there is a rebar plugin that allows that:
> - benoit

View raw message