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 <kocol...@apache.org> wrote: > > >> On Apr 13, 2016, at 12:30 PM, Alexander Shorin <kxe...@gmail.com> wrote: >> >> Hi Paul! >> >> Thanks for great input! >> >>> On Wed, Apr 13, 2016 at 7:11 PM, Paul Davis <paul.joseph.da...@gmail.com> >>> 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 >
