On Tue, Mar 11, 2014 at 1:37 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote:
> > 1) Who does and how do they do regression testing between the database > server and the client? I.E. are the bugs "on the client" or "in the server" > hard to say when there is no official client. > The native protocol spec is the source of truth. If Cassandra's behavior doesn't match the spec, it's a bug. Likewise for any drivers. I'm not sure how this makes it unclear whether a bug is server-side or client-side. Maybe an example scenario would be useful? > 2) How can an open source apache project depend on a non apache managed > resource to accomplish basic development? IE if there is a cassandra > committer that does not have commit on the driver source code get work > done? > Cassandra itself already depends on external projects for basic development (ant, libraries, etc). The drivers are no different (and most are Apache licensed themselves). > 3) Who has the "final word" on how a feature is implemented in the native > protocol? Imagine there are two implementations of CQL native-cql-ruby and > native-cql-java. Let's say these libraries have both interpreted the > transport spec differently. One of them has to be broken to fix the > problem. Who resolves this issue and how? This means the spec is ambiguous. In that case, I imagine the proper solution would be to create a jira ticket and decide how to resolve the ambiguity in the spec. Basically, I think you're looking for a reference implementation instead of a spec. Perhaps a reference implementation would be useful, but that's a separate debate. -- Tyler Hobbs DataStax <http://datastax.com/>
