openstack/deb-python-cassandra-driver
Code Issues Proposed changes

Some design/impl guidelines for contributing

Browse Source
This commit is contained in:
Adam Holmberg 2016-03-03 12:04:49 -06:00
parent fe14a7847a
commit 6f67300d0a
1 changed files with 9 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
CONTRIBUTING.rst
View File

@ -20,7 +20,14 @@ Pull Requests
If you're able to fix a bug yourself, you can [fork the repository](https://help.github.com/articles/fork-a-repo/) and submit a [Pull Request](https://help.github.com/articles/using-pull-requests/) with the fix.
Please include tests demonstrating the issue and fix. For examples of how to run the tests, consult the `dev README <https://github.com/datastax/python-driver/blob/master/README-dev.rst#running-the-tests>`_.
Contribution License Agreement
------------------------------
To protect the community, all contributors are required to [sign the DataStax Contribution License Agreement](http://cla.datastax.com/). The process is completely electronic and should only take a few minutes.
To protect the community, all contributors are required to [sign the DataStax Contribution License Agreement](http://cla.datastax.com/). The process is completely electronic and should only take a few minutes.
Design and Implementation Guidelines
------------------------------------
- We support Python 2.6+, so any changes must work in any of these runtimes (we use ``six``, ``futures``, and some internal backports for compatability)
- We have integrations (notably Cassandra cqlsh) that require pure Python and minimal external dependencies. We try to avoid new external dependencies. Where compiled extensions are concerned, there should always be a pure Python fallback implementation.
- This project follows `semantic versioning <http://semver.org/>`_, so breaking API changes will only be introduced in major versions.
- Legacy ``cqlengine`` has varying degrees of overreaching client-side validation. Going forward, we will avoid client validation where server feedback is adequate and not overly expensive.
- When writing tests, try to achieve maximal coverage in unit tests (where it is faster to run across many runtimes). Integration tests are good for things where we need to test server interaction, or where it is important to test across different server versions (emulating in unit tests would not be effective).