+1 On making unit tests & distributed tests robust (with & without ec2)
Sri On Thu, Jan 13, 2011 at 1:46 PM, Ryan King <r...@twitter.com> 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 clusters. Calling it 1.0 won't make it any > more stable or faster. > > Also, before we say that "everything people want in 1.0 is done", > perhaps we need to do that survey again. A lot of people have joined > the community since 0.5 days and their needs should probably be > considered in this situation. Also, those of use who've been around > have new things we care about. Of course this will always be true and > at some point we need to draw a line in the sand and put the 1.0 stamp > on it– I just feel that that time has not come yet (but, like I said I > don't really care that much because it won't affect me). > > Regardless of what we call the next major release there's at least 2 > things I'd like to see happen: > > 1. make the distributed test suite more reliable (its admittedly flaky > on ec2) and flesh it out to include all distributed functionality. We > shouldn't run a distributed system without distributed tests. We'll > work on the flakiness, but we need people to write tests (and > reviewers to require tests). > 2. I think we should change how we plan releases. I'll send another > email about this soon. > > -ryan > > On Tue, Jan 11, 2011 at 5:35 PM, Jonathan Ellis <jbel...@gmail.com> 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.apache.org/msg01446.html > > > > Looking at that, we've done essentially all of them. I think we can > > make a strong case that our next release should be 1.0; it's > > production ready, it's reasonably feature-complete, it's documented, > > and we know what our upgrade path story is. > > > > The list-- > > > > Load balancing: basics done; > > https://issues.apache.org/jira/browse/CASSANDRA-1427 is open to > > improve it > > > > Decommission: done > > > > Map/reduce support: done > > > > ColumnFamily / Keyspace definitions w/o restart: done > > > > Design documentation: started at > > http://wiki.apache.org/cassandra/ArchitectureInternals > > > > Insert multiple rows at once: done > > > > Remove_slice_range / remove_key_range: turned out to be a *lot* harder > > than it looks at first. Postponed indefinitely. > > > > Secondary indexing: done > > > > Caching: done (with some enhancements possible such as > > https://issues.apache.org/jira/browse/CASSANDRA-1969 and > > https://issues.apache.org/jira/browse/CASSANDRA-1956) > > > > Bulk delete (truncate): done > > > > I would add, > > > > User documentation: done (http://www.riptano.com/docs) > > > > Large row support: done > > > > Improved replication strategies and more sophisticated ConsistencyLevels: > done > > > > Efficient bootstrap/streaming: done > > > > Flow control: done > > > > Network-level compatibility between releases: scheduled > > (https://issues.apache.org/jira/browse/CASSANDRA-1015) > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder of Riptano, the source for professional Cassandra support > > http://riptano.com > > >
