Re: On dependency management and CI issues associated with it

Garren, correct me if I'm wrong but Fauxton depends on a large number of JS dependencies that we don't keep copies of, correct? Or is it just for the build process? -Joan - Original Message - > From: "Alexander Shorin" > To: dev@couchdb.apache.org > Sent: Wednesday,

Re: On dependency management and CI issues associated with it

> On Apr 13, 2016, at 2:08 PM, Alexander Shorin wrote: > > On Wed, Apr 13, 2016 at 8:39 PM, Robert Newson wrote: >> 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

Re: On dependency management and CI issues associated with it

On Wed, Apr 13, 2016 at 8:39 PM, Robert Newson wrote: > 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

Re: On dependency management and CI issues associated with it

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

Re: On dependency management and CI issues associated with it

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

Re: On dependency management and CI issues associated with it

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

Re: On dependency management and CI issues associated with it

No experience using subtrees, but remember Rust switched to use those: https://github.com/rust-lang/rust/tree/master/src jemalloc, llvm and few others are subtrees. PR with some discussion: https://github.com/rust-lang/rust/pull/26042 -Nick On Wed, Apr 13, 2016 at 12:38 PM, Paul Davis

Re: On dependency management and CI issues associated with it

> On Apr 13, 2016, at 12:30 PM, Alexander Shorin wrote: > > Hi Paul! > > Thanks for great input! > > On Wed, Apr 13, 2016 at 7:11 PM, Paul Davis > wrote: >> If anyone has a strong objection to a monolithic Erlang repo I'd like >> to hear it.

Re: On dependency management and CI issues associated with it

Does anyone have any experience with git subtree on this list? I was under the impression that as long as you ensured that it was a strict copy of upstream it was fairly simple. For your list of repos to keep separate, those sound fine to me regardless of subtree. They're all fairly stable at

Re: On dependency management and CI issues associated with it

Hi Paul! Thanks for great input! On Wed, Apr 13, 2016 at 7:11 PM, Paul Davis 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

Re: On dependency management and CI issues associated with it

Keeping fauxton in a separate repo makes sense. It has a different release cycle. It's genuinely decoupled. Getting all the Erlang into one repo is really the goal. With couch_epi as a core application, anyone can extend and customise couchdb by adding another dependency. At most, we might

Re: On dependency management and CI issues associated with it

Hello everybody! Wow, 56 repos! Hopefully we get an award somewhere for that. I've listed the repositories below in some crude groups to try and give an idea of what we're working with. I have to agree that this is getting a bit on the ridiculous side. Of all of the repos that the ASF actually

Re: On dependency management and CI issues associated with it

On Wed, Apr 13, 2016 at 6:46 PM, Ilya Khlopotov wrote: > > > - If you rebase/update any of your subcomponent PRs you must update > commit hash on apache/couchdb one; > > Above is an error prune step which actually makes the following false > > - No new new steps/files/work

Re: On dependency management and CI issues associated with it

Hi Alex, Thank you for your feedback. > - If you rebase/update any of your subcomponent PRs you must update commit hash on apache/couchdb one; Above is an error prune step which actually makes the following false > - No new new steps/files/work introduced, so there is no need to care about

Re: On dependency management and CI issues associated with it

I like the idea of going back to a single repo for core db features. I would like Fauxton to still be in its own repo. As someone who wrote some very basic erlang code for CouchDB recently. I found the multiple repos quite tricky to manage and I couldn't see how it made anything easier. On Wed,

Re: On dependency management and CI issues associated with it

Hi Robert, Point about flattening to a single repository is valid: in the end, we have our apps repos in broken state all the time as they are not declare their decencies. So noone can pick fabric@master and run it - he'll spend quite a lot of time to figure the deps of the right versions. But