couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: On dependency management and CI issues associated with it
Date Wed, 13 Apr 2016 16:44:36 GMT

> On Apr 13, 2016, at 12:30 PM, Alexander Shorin <> wrote:
> Hi Paul!
> Thanks for great input!
> On Wed, Apr 13, 2016 at 7:11 PM, Paul Davis <> wrote:
>> If anyone has a strong objection to a monolithic Erlang repo I'd like
>> to hear it. Otherwise I may work up a lengthier and more thorough
>> proposal for dev@ to consider consolidating all of these repositories
>> for sanity and profit.
> It's hard to object against that since this actually solves a lot of
> problems solution of which will require more work to do and still will
> leave a place for mistakes or require quite specific toolchain to
> work.
> Making our current repos design work right will require even more work to apply.
> So, for point of time/resources/usability there is no much choice.
> I think folding the "Erlang repos developed by ASF" list will solve
> most part of the problems. However, I think it worth to keep these
> apps in own repos:
> - rexi
> - b64url
> - config
> - snappy
> - khash
> - ets-lru
> - twig (why we still need it?)
> As they could be reused outside and they shouldn't involve any
> dependencies with other couch modules by design. Everyone else may
> stand on where they are.
> P.S. I'm not sure if git-subtree will not introduce more new problems
> as it's quite tricky thing to live with it.
> --
> ,,,^..^,,,

+1 Alex. I disagree that “one Erlang repo” is the goal. Erlang is just starting to get
better support for package managers and the like, and it’d be a shame to miss out on opportunities
for adoption of and contribution to general-purpose libraries like config, rexi, khash or
ets-lru by bundling them into a repo that doesn’t look or feel like an idiomatic Erlang
repo. And at any rate I certainly hope no one is proposing to copy/paste other upstream deps
into one repo — the current practice of hosting a fork that doesn’t get recognized as
a fork in GitHub is already fairly rude behavior on our part.

I’ll agree that some of the repo creation has gotten a bit out of control. I believe _some_
of the friction is healthy; I think some of my contributions over the years were better precisely
because the repo structure made bad designs harder to implement. The friction in the CI /
CD pipeline and overall dependency management is not healthy, though.

Moving more code back into one repo puts more responsibility on the devs to architect new
enhancements in the right way without the repo structure there to enforce a few of the best
practices. That’s OK so long as we understand the tradeoff.


View raw message