couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: A quick status about the merge of rcouch
Date Fri, 10 Jan 2014 13:20:08 GMT
On Fri, Jan 10, 2014 at 1:59 PM, Robert Samuel Newson <rnewson@apache.org>wrote:

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

This is why I am keeping them on a separate repository and advising to do
the same fr apache-couchdb. Also we have the same concern with the npm
dependencies for fauxton. Nothing stop npm or the lib in to disappear.



>
> 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 the security, see above. Having them in a place we mirror would work.
Anyway if we really are concerning about the security then we should work
more with upstream than we do.

I am personally find it more damageable for upstream and us the way we are
currently working. We don't have latest patches since a while in most
sources and we fork without giving back neither trying or checking what is
already existing (like the socks5 patch).



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

This is what make distdir is for you generate a source for the release.

Having everything in our sources until we have so little dependencies what
should we do with npm? Should we have all the modules in the repository?
Should we track any change? Should we always backport, merge ... A source
should only concern about its own features and trust the upstream
maintainers for the code it depends on. If something happen then it always
time to take the source back . In other cases we should work more with
upstream and propose patches to make sure we din't miss a thing. Also by
working with upstream we give a chance to the project to continue and
improve. Improvements that will improve our own product because the author
of the upstream lib is generally more concerned about it than we are. A
fair ecosystem in short.



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

Why is this not enough? Anyway better to discuss that in a separate mail.
Since it's a concern that goes further than the rcouch merge.

- benoit

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