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 webpack which allows us to manage
our dependencies via npm (in case you are wondering, we don't depend on
leftpad directly). So some of them are in our repo but the majority ar
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, April 13, 2016 2:08:2
> 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 think, with
>> the best intentions of
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 couchdb can be
> traced ba
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
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 reviewin
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
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
wrote
> 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. Otherwise I may work up a lengthier and more thoro
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 this
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 consolidating all of these repositories
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 i
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 dev
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 introduced, so there is
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 lear
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, Ap
16 matches
Mail list logo
