> On Apr 13, 2016, at 12:30 PM, Alexander Shorin <[email protected]> wrote: > > Hi Paul! > > Thanks for great input! > > On Wed, Apr 13, 2016 at 7:11 PM, Paul Davis <[email protected]> > 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. Adam
