I wouldn't quite go so far as to call it rude but it is at least annoying that we're not part of the usptream network on GitHub. Unfortunately, between ASF rules and regulations and the GitHub integration there's not a whole lot we can do. Granted given that we're not developing downstream in those repos I'm not sure its a big deal to worry about. Any ASF committer that wants to make an upstream change can fork the upstream repo, patch and PR, and then our downstream mirrors can be updated.
On Wed, Apr 13, 2016 at 12:39 PM, Robert Newson <[email protected]> wrote: > 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 <[email protected]> wrote: >> >> >>> 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 >> >
