couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: [PROPOSAL] Improving the quality of CouchDB
Date Thu, 10 Sep 2015 10:18:54 GMT
On Thu, Sep 10, 2015 at 12:40 PM, Dale Harvey <dale@arandomurl.com> wrote:
> I dont think CI is a dream, It should take an afternoon at most to get
> CouchDB setup on travis on a single platform to ensure no major regressions
> come though. If anyone wants help doing that feel free to ping me on
> #pouchdb / #couchdb, we already test couchdb master in travis.

It is a dream for now.

We have travis enabled, but it has practical flaw: it cannot handle
changes that affected multiple repositories at the same time. Also,
for each repository we have to build full CouchDB to test what is a
bit overkill.

> I do think multirepos is an issue and that solution is not so simple, we
> went through the same issues with pouchdb as we attempted to split out our
> repository.

Well, there was a good theory that each of our repository will contain
an app which could be reused outside of CouchDB or being easily
replaced by alternative implementation. Suddenly, for now most of our
apps are heavy coupled

> 1. Dont split out into lots of repositories, if you put those components
> inside the CouchDB repo, then they will get the CouchDB tests run against
> them when changes are made and you wont break the CouchDB repo.

It's good in retrospective, but useless now. We have to decide how our
CI will work: with multirepo layout or first fold all core repos back
to the one. I think we are ready to revise this too and probably this
should be done before CI work.

> 2. Anything that does live outside the CouchDB repo, pin their version
> inside the CouchDB repo, dont have commits to subproject X automatically be
> applied to CouchDB, that means you can commit whatever you want to X but
> CouchDB will still be working, when you come to update the version of X you
> pinned, you can see that it breaks and not update until it is fixed.

It's good strategy for milestones or when you don't have to manage 40+ repos (:

>   2.5 Another strategy that can help with this is to have the full CouchDB
> test suite run inside X, so changes to X will run the full CouchDB suite
> with an updated X

This works, but until changes are belongs to a single repository. See
above about travis issue.


P.S. Jason, you are right again (:

--
,,,^..^,,,

Mime
View raw message