I'd exclude third party repos, sure. It's a thread derail but this notion that we're being "fairly rude" needs resolving. It might be lost to history now but we got here, I think, with the best intentions of ensuring all the code that appears in couchdb can be traced back to code hosted at asf. Is it a concrete requirement? I honestly forget but I thought so.
If it's not a requirement then we could point to non asf hosted repositories, if we accept that things we've used in the past could vanish at any time. A halfway might be a true fork hosted on GitHub? I think even we're not safer as the original project could be pulled and take the forks with it. This has happened. It's obviously unlikely. > 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 >
