couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: On dependency management and CI issues associated with it
Date Wed, 13 Apr 2016 17:42:33 GMT
As for the separation we have enforcing good practices, I don't buy it. 

I don't think it will be difficult to prevent the kind of coupling you (and I) would find
troubling.  It might even be easier to see if a single commit touches multiple src/ subdirectories
that might be missed when reviewing separate pr's. At least, I'm not sure I could slide a
credit card between them. 

> On 13 Apr 2016, at 17:44, Adam Kocoloski <> wrote:
>> 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 <>
>>> 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.
> Adam

View raw message