Skip to content

Commit 974fa12

Browse files
Donation to Apache Cassandra and ASF
Reassignment of copyright, where approved, and relicensing. Change phrases of "gocql team" to "the Cassandra project". New repository will be github.com/apache/cassandra-gocql-driver
1 parent 34fdeeb commit 974fa12

File tree

100 files changed

+2681
-271
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

100 files changed

+2681
-271
lines changed

AUTHORS

Lines changed: 0 additions & 143 deletions
This file was deleted.

CONTRIBUTING.md

Lines changed: 4 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
# Contributing to gocql
1+
# Contributing to the Apache Cassandra GoCQL Driver
22

33
**TL;DR** - this manifesto sets out the bare minimum requirements for submitting a patch to gocql.
44

@@ -30,34 +30,21 @@ In addition to stating the hard requirements, there are a bunch of things that w
3030

3131
### General QA Approach
3232

33-
The gocql team needs to consider the ongoing maintainability of the library at all times. Patches that look like they will introduce maintenance issues for the team will not be accepted.
33+
The Cassandra project needs to consider the ongoing maintainability of the library at all times. Patches that look like they will introduce maintenance issues for the team will not be accepted.
3434

3535
Your patch will get merged quicker if you have decent test cases that provide test coverage for the new behavior you wish to introduce.
3636

3737
Unit tests are good, integration tests are even better. An example of a unit test is `marshal_test.go` - this tests the serialization code in isolation. `cassandra_test.go` is an integration test suite that is executed against every version of Cassandra that gocql supports as part of the CI process on Travis.
3838

3939
That said, the point of writing tests is to provide a safety net to catch regressions, so there is no need to go overboard with tests. Remember that the more tests you write, the more code we will have to maintain. So there's a balance to strike there.
4040

41-
### When It's Too Difficult To Automate Testing
42-
43-
There are legitimate examples of where it is infeasible to write a regression test for a change. Never fear, we will still consider the patch and quite possibly accept the change without a test. The gocql team takes a pragmatic approach to testing. At the end of the day, you could be addressing an issue that is too difficult to reproduce in a test suite, but still occurs in a real production app. In this case, your production app is the test case, and we will have to trust that your change is good.
44-
45-
Examples of pull requests that have been accepted without tests include:
46-
47-
* https://github.com/gocql/gocql/pull/181 - this patch would otherwise require a multi-node cluster to be booted as part of the CI build
48-
* https://github.com/gocql/gocql/pull/179 - this bug can only be reproduced under heavy load in certain circumstances
49-
5041
### Sign Off Procedure
5142

52-
Generally speaking, a pull request can get merged by any one of the core gocql team. If your change is minor, chances are that one team member will just go ahead and merge it there and then. As stated earlier, suitable test coverage will increase the likelihood that a single reviewer will assess and merge your change. If your change has no test coverage, or looks like it may have wider implications for the health and stability of the library, the reviewer may elect to refer the change to another team member to achieve consensus before proceeding. Therefore, the tighter and cleaner your patch is, the quicker it will go through the review process.
43+
Generally speaking, a pull request can get merged by any one of the project's committers. If your change is minor, chances are that one team member will just go ahead and merge it there and then. As stated earlier, suitable test coverage will increase the likelihood that a single reviewer will assess and merge your change. If your change has no test coverage, or looks like it may have wider implications for the health and stability of the library, the reviewer may elect to refer the change to another team member to achieve consensus before proceeding. Therefore, the tighter and cleaner your patch is, the quicker it will go through the review process.
5344

5445
### Supported Features
5546

56-
gocql is a low level wire driver for Cassandra CQL. By and large, we would like to keep the functional scope of the library as narrow as possible. We think that gocql should be tight and focused, and we will be naturally skeptical of things that could just as easily be implemented in a higher layer. Inevitably you will come across something that could be implemented in a higher layer, save for a minor change to the core API. In this instance, please strike up a conversation with the gocql team. Chances are we will understand what you are trying to achieve and will try to accommodate this in a maintainable way.
57-
58-
### Longer Term Evolution
59-
60-
There are some long term plans for gocql that have to be taken into account when assessing changes. That said, gocql is ultimately a community driven project and we don't have a massive development budget, so sometimes the long term view might need to be de-prioritized ahead of short term changes.
47+
gocql is a low level wire driver for Cassandra CQL. By and large, we would like to keep the functional scope of the library as narrow as possible. We think that gocql should be tight and focused, and we will be naturally skeptical of things that could just as easily be implemented in a higher layer. Inevitably you will come across something that could be implemented in a higher layer, save for a minor change to the core API. In this instance, please strike up a conversation in the Cassandra community. Chances are we will understand what you are trying to achieve and will try to accommodate this in a maintainable way.
6148

6249
## Officially Supported Server Versions
6350

@@ -67,12 +54,3 @@ Currently, the officially supported versions of the Cassandra server include:
6754
* 2.0.9
6855

6956
Chances are that gocql will work with many other versions. If you would like us to support a particular version of Cassandra, please start a conversation about what version you'd like us to consider. We are more likely to accept a new version if you help out by extending the regression suite to cover the new version to be supported.
70-
71-
## The Core Dev Team
72-
73-
The core development team includes:
74-
75-
* tux21b
76-
* phillipCouto
77-
* Zariel
78-
* 0x6e6562

0 commit comments

Comments
 (0)