Hey all, love the discussion! :) I’ve identified these issues in this thread:
1. multi-repo vs. mono-repo - with the sub-issues of how mono the repo should be - and how to get tooling and process going specifically 2. keeping safe copies of upstream dependencies to avoid left-padding - with the sub-issue of not being able to do this for every single one because of licensing. Let’s try to keep those separate :) * * * Summary As for 1, I think we have a rough consensus about going back to some form of mono-repo. I don’t think anyone disagrees with keeping fauxton and the docs in separate repos as well, same with nano and nmo, essentially everything “non-core Erlang”. The open question then is do we bundle *everything* else together, including the Erlang apps that are usable standalone as outlined by Paul, or fold them in. I think we have to further separate these by “developed by us” and “forks from upstream“ like mochiweb, ibrowse and jiffy (although, nice overlap here :). 2. we should be discussing. Which deps are we afraid of going away, what should our policy be, etc? But let’s spin this out in a new thread. If you want to reply to this, please choose a new Subject line. * * * Opinion From a “this sounds neat”-perspective, I’d prefer these three tiers: 1. one repo for all ASF-developed CouchDB bits that are not reasonably different Erlang apps (couch-replicator, chttpd, etc)* 2. one repo each for ASF-developed CouchDB bits that are reasonably used in other projects (khash, b64url, snappy, etc) 3. one repo each for upstream forks. * although they should continue to be separated in src/subdirs, and not all in src/couchdb as we did in 1.x. My assumption is that category 2 deps are usually not the ones causing trouble in today’s development flow (please correct me if I’m wrong). And I don’t know if development tooling gets any easier if we keep some things separate and others not, but if at all possible, I think the above is the most sensible. I don’t have too much experience with git subtree, but the docs are surely not beginner friendly, but I’m sure with a nice dev guide, we should be able to follow along. Best Jan -- > On 13 Apr 2016, at 19:42, Robert Newson <rnew...@apache.org> wrote: > > 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 >> > -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
