openstack/deb-python-cassandra-driver
Code Issues Proposed changes
c59763815d
deb-python-cassandra-driver/CONTRIBUTING.rst
Adam Holmberg 8288d667c6 another link fixup
2017-01-11 11:17:25 -06:00

2.6 KiB
Raw Blame History

Contributing

Contributions are welcome in the form of bug reports or pull requests.

Bug Reports

Quality bug reports are welcome at the DataStax Python Driver JIRA.

There are plenty of good resources describing how to create good bug reports. They will not be repeated in detail here, but in general, the bug report include where appropriate:

  • relevant software versions (Python runtime, driver version, cython version, server version)
  • details for how to produce (e.g. a test script or written procedure)
    • any effort to isolate the issue in reproduction is much-appreciated
  • stack trace from a crashed runtime

Pull Requests

If you're able to fix a bug yourself, you can fork the repository and submit a Pull Request with the fix. Please include tests demonstrating the issue and fix. For examples of how to run the tests, consult the dev README.

Contribution License Agreement

To protect the community, all contributors are required to sign the DataStax Contribution License Agreement. 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, 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).