Great to see a target for a release! Personally I think the momentum of the project would benefit more from having a release to refer to, than any (other) new feature or improvement. I understand range queries are a priority for you Jonathan. I still wonder if it would not be better to limit 0.3 to only bug fixes (priority major or above)?
// Per On Thu, Apr 16, 2009 at 12:02 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > I went all Enterprise on our jira and assigned issues to version "0.3" > that I'd like to get done in the relatively near future for our first > official release. > > The list of issues is here: > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310865&fixfor=12313861 > > Note that many issues are marked Patch Available which means we just > need to complete the review process for those. > > If you want to grab one of the unassigned ones that would be awesome. > If you want to grab one of the ones I assigned to myself, that's > awesome too, but give me a heads up first so I don't duplicate your > effort. :) > > Also, if there's other issues that you think should be on the 0.3 list > feel free to add them. (Correctness issues especially.) But IMO we > should not let scope creep too much for our first Apache release. > > -Jonathan > > On Thu, Apr 2, 2009 at 12:51 PM, Jonathan Ellis <jbel...@gmail.com> wrote: >> Someone asked on IRC if there is a roadmap for Cassandra. This is a >> good discussion to have. :) >> >> Personally my priority list looks like this: >> >> High priority: >> 1. range queries [which requires the partitioner changes we've been >> discussing] >> 2. make cassandra not allow itself to run out of memory during >> sustained inserts >> 3. fix distributed remove issues >> 4. Support unicode keys >> >> Medium priority: >> 5. pre-emptive repair (what the dynamo paper calls anti-entropy) >> 6. load balancing >> >> (1) is substantially done but will probably need some tweaking during >> code review. And then the client api will probably need some fleshing >> out (right now you just get a list of keys back, so that's not very >> efficient if you want to get columns for each of those too.) >> >> (2) has workarounds like binarymemtable but I'd really like to get the >> main insert path able to handle large insert volume without falling >> over. My co-worker is just starting to look into this. I'm hoping >> there will be some straightforward improvements to make here. >> >> I outlined an approach to (3) that I think will work here: >> http://mail-archives.apache.org/mod_mbox/incubator-cassandra-dev/200903.mbox/%3ce06563880903301519h922840ds72ef6f9a8d95e...@mail.gmail.com%3e >> >> I'm waiting for Avinash's feedback but as outlined it is not much code. >> >> (4) is a thrift issue, not Cassandra per se. (see >> https://issues.apache.org/jira/browse/THRIFT-395) but it is on my >> plate so I thought I'd throw that out there. >> >> I have not started (5) or (6). There are some stubs for load >> balancing in the code which is why I said in another thread that the >> Facebook developers have probably thought more about this. >> >> I know Avinash is currently finishing up multiget support. Hopefully >> he will chime in about what his and Prashant's plans are next. >> >> -Jonathan >> >
