I'm not a stakeholder here- I don't know Russell, I don't work for
Datastax, and I'm not a member of the ASF.
For what little it's probably worth since I haven't "been elected to have a
binding voice within the project", Russell's is exactly how I read the
message from Chris Mattmann. Whether or
I can't usefully speak to your other questions, but the answers to the
technical questions are below.
On Mon, Feb 18, 2013 at 1:16 PM, Michael Alan Dorman
mdor...@ironicdesign.com wrote:
* 4.1.2. CREDENTIALS
My quick clarification is from this bit of text:
The body is a list of
On Tue, Sep 25, 2012 at 11:16 AM, Jonathan Ellis jbel...@gmail.com wrote:
2) The binary protocol only really has a Java implementation so far.
Having the time to flesh out the Python implementation would be a good
sanity check before we commit to protocol stability.
Just to clarify, the
On Wed, Aug 22, 2012 at 4:53 PM, Christoph Hack christ...@tux21b.orgwrote:
Hi,
I am currently developing a client for Cassandra's new native protocol
in Go. Everything is working fine so far and I am quite happy with the
new protocol. Good work! Here a just a couple of questions and notes:
On Mon, Jan 9, 2012 at 10:02 AM, Peter Schuller peter.schul...@infidyne.com
wrote:
[speaking obviously as non-committer, just offering a perspective]
A potential factor to consider: If one knows that all work in topic
branches end up merged without anyone first rebasing to clean up, you
now
On Thu, Jan 5, 2012 at 10:58 AM, Sylvain Lebresne sylv...@datastax.comwrote:
Again, I was more talking about the only reasonable solution I saw.
Because to be clear, if the history for some issue 666 in say trunk looks
like:
commit : last nits from reviewer
commit : oops, typo that
On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis jbel...@gmail.com wrote:
So, can I summarize our policy as git pull --rebase?
I'd rather have the normal case be to use topic branches for work, so
--rebase doesn't come in to the picture, but yeah, pull --rebase is a
better default.
A more
On Wed, Jan 4, 2012 at 3:19 PM, Jonathan Ellis jbel...@gmail.com wrote:
On Wed, Jan 4, 2012 at 11:48 AM, paul cannon p...@datastax.com wrote:
On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis jbel...@gmail.com
wrote:
So, can I summarize our policy as git pull --rebase?
I'd rather have
On Mon, Jul 25, 2011 at 4:42 PM, Brandon Williams dri...@gmail.com wrote:
On Mon, Jul 25, 2011 at 3:45 PM, Jeremy Hanna
jeremy.hanna1...@gmail.com wrote:
Basically the trade-off is, if we add ACLs such that we can easily add new
contributors really easily, we can ditch the textchas and
I definitely vote for reserving words that are expected to be needed in the
future. It seems we have a pretty good chance of predicting most of the
syntactical needs for the next couple years (especially with suggestions
from common SQL variants), and the (hopefully) rare exceptions could get
Tested. Unsubscribe works fine.
p
2011/7/5 Jesse Melton jzmel...@gmail.com
Ha ha. Good luck with that. Just spam them out. The unsubscribe system
doesn't work even the list admins can't get you off the list.
On Jul 5, 2011 9:41 PM, 김준영 juneng...@naver.com wrote:
unsubscribe
On Thu, Jun 3, 2010 at 2:11 PM, Eric Evans eev...@rackspace.com wrote:
On Thu, 2010-06-03 at 07:55 -0700, Clint Byrum wrote:
* We will most likely conflict with the Cassandra published debian packages.
Is this acceptable? Suggested solutions?
Ultimately, I think packages in Ubuntu/Debian can
12 matches
Mail list logo