Go to file
2019-01-09 10:46:49 +01:00
.github Include instructions to load fixtures 2018-04-17 17:50:27 +02:00
doc Merge pull request #317 from CartoDB/316-docs_schema 2017-11-07 15:11:40 +01:00
docs Remove broken links issue 348 devcenter 2018-05-28 17:42:39 +02:00
release Remove new fields not used to simplify deploy process 2018-04-19 19:52:19 +02:00
scripts Include tiger non-clipped county for the fixtures 2018-04-16 12:56:32 +02:00
src Canada columns with 0 denominator 2019-01-09 10:46:49 +01:00
.gitignore first-pass automatic testing 2016-05-12 14:21:31 -04:00
.travis.yml Improve Travis testing 2018-04-04 15:42:25 +02:00
carto-package.json Changes in PostGIS version to use 4 numbers 2018-08-17 11:07:25 +02:00
CONTRIBUTING.md Refactor OBS_GetAvailableTimespans 2018-04-11 10:36:57 +02:00
LICENSE Initial commit with what I think we need 2016-04-06 20:09:19 +02:00
Makefile Release 1.0.6 2016-09-08 10:37:37 +02:00
Makefile.global Initial commit with what I think we need 2016-04-06 20:09:19 +02:00
NEWS.md Update NEWS.md 2018-04-20 10:34:26 +02:00
README.md Fix relative links in markdown 2016-04-13 17:20:46 +02:00
RELEASE.md Remove paragraph from RELEASE.md doc 2016-06-28 17:27:35 +02:00

Observatory extension

CartoDB extension that implements the row-level functions needed by the Observatory Service.

Code organization

.
├── doc     # documentation
├── release # released versions
└── src     # source code
    └── pg
        ├── sql
        └── test
            ├── expected
            ├── fixtures
            └── sql

Development workflow

We distinguish two roles regarding the development cycle:

  • developers will implement new functionality and bugfixes into the codebase and will request for new releases of the extension.
  • A release manager will attend these requests and will handle the release process. The release process is sequential: no concurrent releases will ever be in the works.

We use the default develop branch as the basis for development. The master branch is used to merge and tag releases to be deployed in production.

Developers shall create a new topic branch from develop for any new feature or bugfix and commit their changes to it and eventually merge back into the develop branch. When a new release is required a Pull Request will be open against the develop branch.

The develop pull requests will be handled by the release manage, who will merge into master where new releases are prepared and tagged. The master branch is the sole responsibility of the release masters and developers must not commit or merge into it.

Development Guidelines

For a detailed description of the development process please see the CONTRIBUTING.md guide.

Any modification to the source code shall always be done in a topic branch created from the develop branch.

Tests, documentation and peer code reviews are required for all modifications.

The tests are executed by running this from the top directory:

sudo make install
make test

Release

The release and deployment process is described in the RELEASE.md guide and it is the responsibility of the designated release manager.