Re: On dependency management and CI issues associated with it

On Tue, Apr 19, 2016 at 11:26 PM, Ilya Khlopotov wrote: > > Thank you for you feedback and great discussion. It looks like I am the only > one who prefer multi-repo model (with tools assistance). You're not alone, actually, but it's hard to fight with reality now. I think we

Re: On dependency management and CI issues associated with it

ndency management and CI issues associated with it 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 up

Re: On dependency management and CI issues associated with it

gt;>> Because of the deep dependency tree, we should be very diligent about >>> not accidentally including category-x licensed modules. I’m sure we >>> can automate this into a npm postinstall script, so we know as soon >>> as possible. >>> >>> At the

Re: On dependency management and CI issues associated with it

og.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy >> >> Best >> Jan >> -- >> >> >>> >>> -Joan >>> >>> - Original Message - >>>> From: "Garren Smith" <gar...@apache.org>

Re: On dependency management and CI issues associated with it

- Original Message - >>> From: "Garren Smith" <gar...@apache.org> >>> To: dev@couchdb.apache.org, "Joan Touzet" <woh...@apache.org> >>> Sent: Thursday, April 14, 2016 2:43:10 AM >>> Subject: Re: On dependency management a

Re: On dependency management and CI issues associated with it

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

Re: On dependency management and CI issues associated with it

t; >> To: dev@couchdb.apache.org, "Joan Touzet" <woh...@apache.org> >> Sent: Thursday, April 14, 2016 2:43:10 AM >> Subject: Re: On dependency management and CI issues associated with it >> >> Hi Joan, >> >> Good point. Until about a week a

Re: On dependency management and CI issues associated with it

woh...@apache.org> > Sent: Thursday, April 14, 2016 2:43:10 AM > Subject: Re: On dependency management and CI issues associated with it > > Hi Joan, > > Good point. Until about a week ago we use to keep all our > dependencies in > our repo. But we have just switched to

Re: On dependency management and CI issues associated with it

e build process? > > -Joan > > - Original Message - > > From: "Alexander Shorin" <kxe...@gmail.com> > > To: dev@couchdb.apache.org > > Sent: Wednesday, April 13, 2016 2:08:20 PM > > Subject: Re: On dependency management and CI issues associated w

Re: On dependency management and CI issues associated with it

.org > Sent: Wednesday, April 13, 2016 2:08:20 PM > Subject: Re: On dependency management and CI issues associated with it > > On Wed, Apr 13, 2016 at 8:39 PM, Robert Newson <rnew...@apache.org> > wrote: > > It's a thread derail but this notion that we're being "fairly

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

rge in my local deps I use in development. But this is a different topic probably. Best regards, ILYA From: Alexander Shorin <kxe...@gmail.com> To: "dev@couchdb.apache.org" <dev@couchdb.apache.org> Date: 2016/04/12 11:35 PM Subject: Re: On dependency mana

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

Re: On dependency management and CI issues associated with it

I'd like us to instead consider flattening to a single repository. I've found no value and only pain from the multiple repositories approach (43 in total!). The contention is that multiple repositories enforces application boundaries (low coupling / high cohesion) but I've not felt that in

On dependency management and CI issues associated with it

Dear community, There is a problem with contributors workflow which renders our CI system useless. As you might know couchdb project consists of multiple repositories. Most of the time changes cross the repositories boundaries. When this happens the push to any of the repositories causes CI