Thank you for your answer, however I am pretty sure that's not it. I have
a small-two node cluster for development testing, and I have loaded it
with data in a way that responses to my queries usually have about 5
short rows (which I think is not very much).
First of all, if I do it like this,
On Thu, Jan 13, 2011 at 1:46 PM, Ryan King wrote:
> I'm a -1 on naming the next release 1.0 because I don't think it has
> the quality that 1.0 implies, but to be honest I don't really care
> that much. The version numbers don't really effect those that of use
> that are running production cluster
On Tue, Jan 11, 2011 at 8:29 PM, Eric Evans wrote:
> On Tue, 2011-01-11 at 19:35 -0600, Jonathan Ellis wrote:
>> Way back in Nov 09, we did a users survey and asked what features
>> people wanted to see. Here was my summary of the responses:
>> http://www.mail-archive.com/cassandra-user@incubator
On Thu, Jan 13, 2011 at 4:04 PM, Jonathan Ellis wrote:
> On Thu, Jan 13, 2011 at 2:32 PM, Ryan King wrote:
>> # Fixed schedule
>>
>> We should set a fixed schedule and stick to it. Anything features not
>> ready at branch time won't make it and will be disabled in the stable
>> branch.
>
> I like
I would guess that sending a bunch of range requests simultaneously
overwhelms the targets (range scans are expensive), so you're timing
out simply because it couldn't finish all of them within rpc_timeout.
Solution: don't do that, or increase rpc_timeout.
On Wed, Jan 12, 2011 at 3:03 AM, wrote
On Thu, Jan 13, 2011 at 2:32 PM, Ryan King wrote:
> # Fixed schedule
>
> We should set a fixed schedule and stick to it. Anything features not
> ready at branch time won't make it and will be disabled in the stable
> branch.
I like this idea, as long as we're willing to be flexible when
warranted
To be more clear, here's what I think is broken in the current release planning:
1. The dates are wildly unpredictable
2. People aren't allowed to work against trunk on features for
multiple iterations (see #1072)
3. Stable branches diverge too much, causing duplicated effort. (we
essentially impl
I think many believe that shipping 0.7 took longer than it should.
Rather than going into why that happened, I'd like to propose a better
way to move forward that will hopefully allow us to ship on a more
predictable schedule. This proposal is heavily influenced by the
google chrome release process
I'm a -1 on naming the next release 1.0 because I don't think it has
the quality that 1.0 implies, but to be honest I don't really care
that much. The version numbers don't really effect those that of use
that are running production clusters. Calling it 1.0 won't make it any
more stable or faster.
> In that environment, I think the production grade validation is important.
A bump in version number does not give you production grade validation: in
fact, it is the other way around.
I'm -1 on going to 1.0 for the next release.
On Thu, Jan 13, 2011 at 9:06 AM, Eric Evans wrote:
> On Thu, 201
Three cheers!
On Thu, Jan 13, 2011 at 1:45 PM, Jake Luciani wrote:
> Thanks Jonathan and Cassandra PMC!
> Happy to help Cassandra take over the world!
> -Jake
>
> On Thu, Jan 13, 2011 at 1:41 PM, Jonathan Ellis wrote:
>>
>> The Cassandra PMC has voted to add Jake as a committer. (Jake is also
>
Thanks Jonathan and Cassandra PMC!
Happy to help Cassandra take over the world!
-Jake
On Thu, Jan 13, 2011 at 1:41 PM, Jonathan Ellis wrote:
> The Cassandra PMC has voted to add Jake as a committer. (Jake is also
> a committer on Thrift.)
>
> Welcome, Jake, and thanks for the hard work!
>
> -
The Cassandra PMC has voted to add Jake as a committer. (Jake is also
a committer on Thrift.)
Welcome, Jake, and thanks for the hard work!
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
On Thu, 2011-01-13 at 16:34 +, Nick Telford wrote:
> ...or the Ubuntu route and call it Apache Cassandra 11.08 (or whatever
> month the release occurs in). The number itself is relatively
> unimportant.
And while we're at it, how about a codename in adjective-animal form?
Some suggestions:
*
We could go the Microsoft route and call it Apache Cassandra 2011, or the
Ubuntu route and call it Apache Cassandra 11.08 (or whatever month the
release occurs in). The number itself is relatively unimportant.
I believe what Jonathan is proposing is a change to something that implies a
level of st
Speaking more for an organization that works with a lot of external parties
using Cassandra (that don't necessarily develop on it), I think the pivot to
1.0 makes better sense. A lot of the world is still coming to know Cassandra
vs. any other NoSQL type solution. In that environment, I think th
On Wed, Jan 12, 2011 at 5:29 AM, Eric Evans wrote:
> I'd rather drop the leading the 0 and continue to number releases
> sequentially the way we have. If our < 1 versioning is signaling a lack
> of readiness, and if >= 1 is a necessary gate, then 8.0 should work
> equally as well. Better in fact
17 matches
Mail list logo
