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 n
On Wed, Aug 22, 2012 at 4:53 PM, Christoph Hack wrote:
> 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:
>
That's great.
On Sun, Aug 26, 2012 at 2:03 PM, Christoph Hack wrote:
> Ticket+Patch: https://issues.apache.org/jira/browse/CASSANDRA-4577
Excellent- I'll take a look at that too.
5) LIMIT
>
> The last query with LIMIT 1 in this example returns a very strange result
> imho.
> Instead of just limiting the rows
On Tue, Sep 25, 2012 at 11:16 AM, Jonathan Ellis 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 Python implementat
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 ke
On Mon, Feb 18, 2013 at 6:48 PM, Michael Alan Dorman <
mdor...@ironicdesign.com> wrote:
> paul cannon writes:
>
> As the doc says, each is a [bytes], which means it's represented
> > on the wire as an [int] x followed by x bytes.
>
> Thank you for pointing out
On Thu, Jun 3, 2010 at 2:11 PM, Eric Evans 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 replace the b
On Thu, Jun 3, 2010 at 3:42 PM, Eric Evans wrote:
> The packages uploaded to the ASF mirrors have thus far been stable
> releases. Those could just as easily be uploaded to backports.org.
backports.org only allows versions of packages which are already in
Debian testing.
--
paul, the
+1 for aggressive curation, and -1 on moving clients in-tree.
p
On Fri, Dec 3, 2010 at 11:43 AM, Jonathan Ellis wrote:
> The status quo is not working. There are way too many questions on
> the user list and on irc about problems with writing Thrift code, even
> when well-maintained clients ex
Tested. Unsubscribe works fine.
p
2011/7/5 Jesse Melton
> 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, "김준영" wrote:
>
> unsubscribe
>
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
their
On Mon, Jul 25, 2011 at 4:42 PM, Brandon Williams wrote:
> On Mon, Jul 25, 2011 at 3:45 PM, Jeremy Hanna
> 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 re-enable images
> on the cassandra wiki.
>
On Wed, Dec 28, 2011 at 1:55 PM, Eric Evans wrote:
> There are also some matters of work-flow or process that we need to
> hashed out. For example, how do we handle reviews now? Do we
> continue to mandate/recommend/allow rebasing?
>
Surely we'd want to follow normal git practices here: rebasi
On Wed, Jan 4, 2012 at 10:57 AM, Eric Evans wrote:
> On Wed, Jan 4, 2012 at 9:59 AM, Jonathan Ellis wrote:
> > On Tue, Jan 3, 2012 at 1:21 PM, paul cannon wrote:
> >> Surely we'd want to follow normal git practices here: rebasing is almost
> >> never appropri
On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis 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 important bit of p
On Wed, Jan 4, 2012 at 3:19 PM, Jonathan Ellis wrote:
> On Wed, Jan 4, 2012 at 11:48 AM, paul cannon wrote:
> > On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis
> wrote:
> >
> >> So, can I summarize our policy as "git pull --rebase"?
> >>
> >
On Thu, Jan 5, 2012 at 10:58 AM, Sylvain Lebresne wrote:
> 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 prevented commi
On Thu, Jan 5, 2012 at 4:50 AM, Sylvain Lebresne wrote:
> Also, if committer !=
> reviewer, there is the slight issue of how the committer make sure
> that he commits what has been reviewer (i.e, that author hasn't made
> some last minute, post-review change). But I suppose we can either say
> "do
On Mon, Jan 9, 2012 at 10:02 AM, Peter Schuller 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 have a constant trade-o
On Jan 12, 2012, at 5:36 AM, Sylvain Lebresne wrote:
> Note that I had to adapt a little bit to the switch to git. In particular,
> instead of using sha1 to mark the tentative commit of a release, I've decided
> to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the
> vote p
20 matches
Mail list logo
