Re: [VOTE] Release 0.5.1
+1 On Feb 23, 2010, at 6:27 PM, Eric Evans wrote: There have been some important bug fixes[1] in the 0.5 branch since we released. Plus, I thought it would be cool to conduct two separate release votes at the time. :) I propose the following tag and artifacts for 0.5.1: SVN Tag: https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.5.1 0.5.1 artifacts: http://people.apache.org/~eevans +1 from me. [1] https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.5.1/CHANGES.txt -- Eric Evans eev...@rackspace.com -- Ian Holsman i...@holsman.net
Re: [VOTE] Release 0.5.0 (final)
+1 On Jan 19, 2010, at 7:54 AM, Chris Goffinet wrote: +1 On Jan 18, 2010, at 12:28 PM, Eric Evans wrote: There have been a few changes[1] in the 0.5 branch since RC3. In a perfect world, we'd probably push those into another release candidate, but I feel pretty good about this one, and any remaining issues can always be added to 0.5.1. I propose the following tag and artifacts for 0.5.0: SVN Tag: https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.5.0 0.5.0 artifacts: http://people.apache.org/~eevans +1 from me. [1] https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.5.0/CHANGES.txt -- Eric Evans eev...@rackspace.com -- Ian Holsman i...@holsman.net
Re: [VOTE] release cassandra 0.5.0-rc3
+1 [binding] On Jan 8, 2010, at 4:26 AM, Eric Evans wrote: The Cassandra community voted on and approved the release of Apache Cassandra 0.5.0-rc3. We would now like to request the approval of the Incubator PMC for this release. Cassandra is a massively scalable, eventually consistent, distributed, structured key-value store. Podling vote thread: http://thread.gmane.org/gmane.comp.db.cassandra.devel/764 0.5.0-rc3 artifacts: http://people.apache.org/~eevans SVN tag: https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.5.0-rc3 Project home: http://incubator.apache.org/cassandra/ Incubation status: http://incubator.apache.org/projects/cassandra.html We received one (IPMC )binding vote[1] during the poddling vote, so we'll need at least a couple more here. The vote will remain open for 72 hours (or longer if needed). Regards, [1] http://article.gmane.org/gmane.comp.db.cassandra.devel/766 -- Eric Evans eev...@rackspace.com -- Ian Holsman i...@holsman.net
Re: Chair
+1 from me. On Jan 6, 2010, at 10:15 AM, Matthieu Riou wrote: +1 for Jonathan. He seems like a good victim ;) On Tue, Jan 5, 2010 at 3:03 PM, Jonathan Ellis jbel...@gmail.com wrote: I can volunteer. On Tue, Jan 5, 2010 at 4:27 PM, Eric Evans eev...@rackspace.com wrote: When we graduate, we need to have someone who will act as the Chair of the Project Management Committee, or Chair. The Chair reports to the ASF Board on behalf of the project, maintains information on the PMC disposition, provides write access to new committers, etc. So besides sounding kind of prestigious, the Chair is basically a glorified administrative assistant. :) http://www.apache.org/dev/pmc.html#chair My understanding is that the Chair a) needs to be on the PMC[1], and b) must volunteer for the job. So, do we have any volunteers? Jonathan (hint, hint :)? [1] http://incubator.apache.org/projects/cassandra.html#Project+info -- Eric Evans eev...@rackspace.com -- Ian Holsman i...@holsman.net
Re: [VOTE] Release 0.5.0-rc1
+1 ipmc pmc --- Sent from my phone Ian Holsman - 703 879-3128 On 24/12/2009, at 12:41 PM, Jonathan Ellis jbel...@gmail.com wrote: I have no problem addressing this during the RC period. On Wed, Dec 23, 2009 at 7:11 PM, Ramzi Rabah rra...@playdom.com wrote: Did you guys see https://issues.apache.org/jira/browse/CASSANDRA-651. That looks like a show stopper to me, when you can't restart a node. On Wed, Dec 23, 2009 at 1:43 PM, Chris Goffinet c...@chrisgoffinet.com wrote: +1 On Wed, Dec 23, 2009 at 4:36 PM, Jonathan Ellis jbel...@gmail.com wrote: +1 On Wed, Dec 23, 2009 at 3:28 PM, Eric Evans eev...@rackspace.com wrote: All of the 0.5 showstoppers are out of the way and things are looking pretty solid. Shall we push out a release candidate? I propose the following tag and artifacts for 0.5.0-rc1 SVN Tag: https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.5.0-rc1 0.5.0-rc1 artifacts: http://people.apache.org/~eevanshttp://people.apache.org/%7Eeevans If it's not obvious, +1 from me. :) [1] https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.5.0-rc1/CHANGES.txt -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release 0.5.0-beta2
+1 (IPMC binding) On Dec 10, 2009, at 11:09 AM, Jaakko wrote: +1 -J -- Ian Holsman i...@holsman.net
Re: Cassandra users survey
We're looking at it to be part of a near real time Web analytics engine, which sounds similar to Ooyala. at the moment I'm pushing to get the thing open sourced if possible. we're looking at combining Cassandra + Esper, but we are still in the very early stages. On Nov 21, 2009, at 8:17 AM, Jonathan Ellis wrote: Hi all, I'd love to get a better feel for who is using Cassandra and what kind of applications it is seeing. If you are using Cassandra, could you share what you're using it for and what stage you are at with it (evaluation / testing / production)? Also, what alternatives you evaluated/are evaluating would be useful. Finally, feel free to throw in I'd love to use Cassandra if only it did X wishes. :) I can start: Rackspace is using Cassandra for stats collection (testing, almost production) and as a backend for the Mail Apps division (early testing). We evaluated HBase, Hypertable, dynomite, and Voldemort as well. Thanks, -Jonathan (If you're in stealth mode or don't want to say anything in public, feel free to reply to me privately and I will keep it off the record.) -- Ian Holsman i...@holsman.net
Re: Graduation?
I don't think there is any policy or standard about RTC or CTR. different groups do different things, depending on the community. so I don't see this as a hang up for graduation. On Nov 6, 2009, at 10:57 AM, Roland Dreier wrote: I do think there should be room for individual discretion here. If you have a trivial change, just commit it and be done. But in general, I think the extra care of RTC is usually worth it for us. I see reviews becoming a lot more perfunctory / not happening at all if we just commit first. (Just about all my experience has been in CTR projects, both closed and OSS. This isn't just a theoretical concern, DESPITE the best of intentions that we'll do reviews, promise.) This gets to my central question, which I would be really happy to have answered by a CTR proponent. How do you make sure that changes *ever* get reviewed, since CTR seems to operate on lazy consensus (if you object to this change, speak up)? *everyone* would rather write code rather than review someone else's changes, so it seems that the quantity of changes going in is always going to exceed the amount of review being done, leading to an ever-growing review backlog. I just don't see how CTR can scale to a big project. It might scale to a big codebase, if each piece has only one or a few committers touching it, but when a lot of people are all working on the same stuff, I wonder how anything will get reviewed in time. (FWIW, my background is pretty much exclusively in RTC projects such as the Linux kernel) - R. -- Ian Holsman i...@holsman.net
Re: [RE-VOTE] Release 0.4.1
+1 On Oct 12, 2009, at 4:08 PM, Dan Di Spaltro wrote: +1 On Mon, Oct 12, 2009 at 1:01 PM, Michael Greene michael.gre...@gmail.com wrote: +1 On Mon, Oct 12, 2009 at 2:32 PM, Eric Evans eev...@racklabs.com wrote: The 0.4 branch has received a number of important bug fixes[1] since we released 0.4.0, it feels about time for an 0.4.1. Shall we? :) -- Dan Di Spaltro -- Ian Holsman i...@holsman.net
Re: [VOTE] Project Logo
Cheers
On Oct 6, 2009, at 2:12 AM, Eric Evans wrote:
~~{ Ballot }~~
[ ] 2http://99designs.com/contests/28940/entries/002
[ ] 30 http://99designs.com/contests/28940/entries/030
[ ] 32 http://99designs.com/contests/28940/entries/032
[1 ] 33 http://99designs.com/contests/28940/entries/033
[ ] 90 http://99designs.com/contests/28940/entries/090
[ ] 173 http://99designs.com/contests/28940/entries/173
[ ] 175 http://99designs.com/contests/28940/entries/175
[3 ] 291 http://99designs.com/contests/28940/entries/291
[2 ] 369 http://99designs.com/contests/28940/entries/369
[ ] 478 http://99designs.com/contests/28940/entries/478
[ ] 576 http://99designs.com/contests/28940/entries/576
[ ] 598 http://99designs.com/contests/28940/entries/598
[ ] NOTA
~~{ Ballot }~~
--
Ian Holsman
i...@holsman.net
Re: [VOTE] Release cassandra 0.4.0 (final)
+1 from me (IPMC mentor of cassandra) On Wed, Sep 23, 2009 at 4:49 AM, Jonas Bonér jo...@jonasboner.com wrote: Finally. +10. Good job guys. 2009/9/21 Eric Evans eev...@rackspace.com: The Cassandra community voted on and approved the release of Apache Cassandra 0.4.0. We would now like to request the approval of the Incubator PMC for this release. Cassandra is a massively scalable, eventually consistent, distributed, structured key-value store. Podling vote thread: http://www.mail-archive.com/cassandra-dev@incubator.apache.org/msg00908.html 0.4.0 artifacts: http://people.apache.org/~eevanshttp://people.apache.org/%7Eeevans SVN tag: https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.4.0-final Project home: http://incubator.apache.org/cassandra/ Incubation status: http://incubator.apache.org/projects/cassandra.html The differences between this and the recently approved RC2 are minor; it contains one bug fix (CASSANDRA-440), and a few documentation updates. If approved, this will be our new stable release, the default for new users, and one demonstrating significant progress over the current stable (0.3.0). We've already received 2 binding +1s during the poddling release vote[0][1], so we need at least one more (and no dissents obviously). The vote will remain open for 72 hours (or longer if needed). Thank you for your time. Regards, [0] http://www.mail-archive.com/cassandra-dev@incubator.apache.org/msg00917.html [1] http://www.mail-archive.com/cassandra-dev@incubator.apache.org/msg00918.html -- Eric Evans eev...@rackspace.com -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] CTR for all non-code changes
I'm happy with this The comitters know what they are doing :-) On 9/18/09, Paul Querna p...@querna.org wrote: Hi, I'm not a commiter (yet!) for Cassandra, but it seems that doing simple changes like fixing up the README requiring RTC (review-then-commit) is over burdensome, without providing any advantage to stability. For the Apache HTTP Server project, while we use RTC for all of our stable branches, for documentation and other non-code changes, we use CTR (commit-then-review). This lets simple things like typos to developing large chunks of documentation happen quickly and without any process burdens, which has allowed the Apache HTTP Servers great documentation project to thrive. I am starting to believe it would be helpful if Cassandra adopted a similar CTR policy for non-code changes on trunk and all branches. Thoughts? Thanks, Paul -- Sent from my mobile device
Re: [VOTE] Release cassandra 0.4.0-beta1
+1 from me. On Aug 18, 2009, at 2:12 AM, ant elder wrote: On Mon, Aug 17, 2009 at 4:55 PM, Eric Evanseev...@rackspace.com wrote: On Mon, 2009-08-17 at 13:00 +0100, sebb wrote: Given whats being said in the Thrift release legal issues thread i think it should be ok to have the 3rd party licenses separate, I disagree. It must be possible to find all the LICENSE files starting at the initial LICENSE file. At the very least, the initial LICENSE file should have pointers to the other license files. the NOTICE file looks acceptable to me too. AIUI, the NOTICE file needs to give attributions to all 3rd party code included in the propose release. When preparing for the 0.3.0[0] release I spent a great deal of time trying to get all of this right. I looked at list threads for both successful and failed podling release votes, I looked at what top- level projects were doing, and I read through what documentation I could find. This wasn't as helpful as I'd have liked because the documents are non-normative and the application is inconsistent, (and occasionally contradictory). So I did the best I could. The conclusion I came to with respect to NOTICE.txt was that it existed for purposes of attribution, and was specifically in response to section 4(d) of the Apache License. As a result, the NOTICE.txt in the (approved )0.3.0 artifacts and the proposed 0.4.0, contains two attribution statements, one for the Apache licensed Groovy, and one for software developed by The Apache Software Foundation which should cover everything else that is Apache licensed. The conclusion I came to for LICENSE.txt was that it was for including the full license text applicable to the project itself. Both of the above conclusions seemed consistent with at least some successful podling releases, and with some ASF top-level projects, and (to the best of my knowledge), all of the license requirements for our third-party dependencies are being met. However, I'd be happy to go back and correct any shortcomings and re-roll the artifacts if that will get us the votes we need to make a release. I just wish things were more consistent and that the process required a little less groping around in the dark. [0] http://www.mail-archive.com/gene...@incubator.apache.org/ msg21853.html -- Eric Evans eev...@rackspace.com Ok, +1 from me to release. Happy to reconsider if anyone can find an actual link to some evidence of specific policy that says how this release is done is not ok. ...ant -- Ian Holsman i...@holsman.net
Re: [vote] 0.4.0 beta 1
+1 great work jonathan! On 11/08/2009, at 4:44 PM, Jonathan Ellis wrote: Hi all, Cassandra 0.4 is feature complete based on the roadmap I suggested a few weeks ago. We also have a mostly-empty issue tracker for 0.4. (https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310865fixfor=12313862 ) I propose releasing an unofficial 0.4.0 beta based on current trunk to signal that our api is stable, our disk format is stable, and we're ready to get a wider group testing this. +1 (binding) from me. -Jonathan -- Ian Holsman i...@holsman.net
Re: The future of 0.3
sounds good to me. if you can make sure the BUGS.txt is highlighted on the release page with a big pointer to describe that there are fundamental issues in this release, so we can set people's expectations accordingly. On 30/06/2009, at 2:04 PM, Jonathan Ellis wrote: With 0.3.0 voted in (the mentors technically have the last word, but let's assume it does get approved :), we should think about the future of the 0.3 branch. Fundamentally 0.3 has issues (see BUGS.txt) and fixing those issues would turn it into 0.4, so I see the 0.3 maintenance mission as very limited in scope. It's there to show we CAN release and to give non-developers a stable branch to use until we're done breaking things. :) I'm a huge fan of the postgresql model for database release management. New features go into major versions (8.3, 8.4, etc.) and maintenance releases (8.4.1, 8.4.2, etc.) are only for bug and security fixes. That's the only way to stay sane IMO; once you start trying to do things like backport new shiny features you WILL have regressions. And stable branches are all about NOT having those. :) So I propose fixing bugs but otherwise doing the minimum possible to disturb things in 0.3 until 0.4.0 is out, and encouraging people to migrate to that quickly when it is. -Jonathan -- Ian Holsman i...@holsman.net
Re: [VOTE] 0.3.0-final
just a point of order. only comitters's votes are binding. so if you could mark your vote that way it would be great for the people who are comitters to mark their vote that way. -I On 27/06/2009, at 12:10 PM, Eric Evans wrote: On Fri, 2009-06-26 at 12:49 -0500, Jonathan Ellis wrote: I propose releasing 0.3.0-rc3 as 0.3.0-final. +1 -- Eric Evans eev...@racklabs.com -- Ian Holsman i...@holsman.net
Re: Alternative wire protocols
not everything is about speed. it really isn't. It's about cost (or if your google, power usage). and ease of use as well. claiming a interface is 10% faster is not going to help if it takes 100 times longer to develop with, or you can't wake someone up at 2am to quickly fix some data that is crashing your middleware. Also if the rest of your infrastructure is using some other protocol it makes more sense to use it than a custom one in this part of your architecture. no one is saying to ditch thrift. It's about supporting extra ones. and like I said in my previous email. If someone is prepared to write it and support it themselves, then it shouldn't bother anyone. On 25/06/2009, at 8:23 AM, Michael Greene wrote: The author of those blog posts has cheated by using the C versions of JSON serializers while using the naive Python implementation of the Thrift serializer. If he used the 'accelerated' version, Thrift would be much faster. See http://jnb.ociweb.com/jnb/jnbJun2009.html#compare for a more accurate, though perhaps no less biased, comparison. Besides the general 'Thrift is a pain' clamor, what improvements are needed from Thrift for Cassandra? It seems like at the moment it's * TFramedTransport in more languages * TCompactProtocol in more languages * Better documentation * Released / packaged binaries With regards to the first two, that just takes time and would need to be rectified for any replacement as well. The third one is something that Cassandra could help with even, through usage examples. The fourth one is something that the Thrift project is voting on at the moment and will happen really soon now... That said, I would be casually interested in HTTP+JSON and Thrift both being supported. Everyone understands HTTP+JSON these days. Michael On Wed, Jun 24, 2009 at 5:17 PM, Alexander Staubomadevilgen...@gmail.com wrote: On Wed, Jun 24, 2009 at 11:03 PM, Jonathan Ellisjbel...@gmail.com wrote: I'm not really interested in stuff that's going to be Much Slower like anything over http (Jay from Voldemort said that's basically a waste of time and I believe him) Not sure I believe that. There's nothing *inherently* slow about HTTP as a protocol, despite its stateless nature. The current Thrift implementation is not known to be a speed demon, though; neither is Protocol Buffers, for all its binary compactness. Personally I prefer JSON + HTTP. Anything that lets me debug an API using Curl makes me a lot more excited than a bloated library that has to be bundled with every client and application. (Why doesn't Thrift generate complete, dependency-free stubs? It seems like such a missed opportunity.) Could be worth investigating whether some moderately fast HTTP layer such as Jetty could beat Thrift. This blog post claims (and backs up with some hard numbers) that JSON can beat both in performance as well as bandwidth: http://www.bouncybouncy.net/ramblings/posts/json_vs_thrift_and_protocol_buffers_round_2/ It should also be noted that Cassandra's API is particularly suited to the simplicity of a pure HTTP API. anything that requires hand-writing clients for each language Doesn't that depend on the complexity of the protocol? The hugely popular Memcached server uses a *very* simple line-based protocol [2], and while you would still want a client library for most apps, writing one is usually so trivial you could do it from scratch as part of your app and it still wouldn't feel like a complete waste of time. A. -- Ian Holsman i...@holsman.net
Re: proposal: rename table to namespace
if you don't change it from table, what about putting a huge comment in the config file with the FAQ entry in it. On 21/06/2009, at 9:32 AM, Sandeep Tata wrote: I'd like for us to continue with Table as well. I agree with Alexander's argument for what namespaces mean for most CS domains. Moving up a notch to a database is also confusing (Do we also have tables? Are there tablespaces? Different storage engines for each tablespace?) We'll have to think of new names for columns and supercolumns too --- I'd rather we stayed with Table On Sat, Jun 20, 2009 at 11:16 AM, Chris Goffinetc...@chrisgoffinet.com wrote: I think we should keep it as 'table'. It's understood everywhere. I've always even heard BigTable call it a Table? I think namespace might just be more confusing. On Jun 20, 2009, at 6:54 AM, Jonathan Ellis wrote: Since we're proposing things that break stuff this weekend... :) I think we should rename table to namespace in the config file. Calling it table confuses people coming from an rdbms background (i.e. just about everyone). -Jonathan -- Ian Holsman i...@holsman.net
Re: moving to framed transport (client breakage inevitable)
Hey guys. is it possible to make this a run time option or something? On 20/06/2009, at 10:03 AM, Michael Greene wrote: Hopping on a plane so this will be brief, but C# does not have a Framed Transport, nor do a few of the other languages, so I'd have to be -1 on this change. On Fri, Jun 19, 2009 at 3:22 PM, Eric Evanseev...@rackspace.com wrote: As explained in CASSANDRA-241[1], the daemon process, which is currently using a non-framed thrift transport is incompatible with (some?) non-blocking client implementations. The solution is to standardize on a framed transport which is compatible with all client implementations. [1] https://issues.apache.org/jira/browse/CASSANDRA-241 Unfortunately this is going to break everyone's client apps. Fortunately the fix is trivial. For Java clients that look something like ... socket = new TSocket(hostname, port); TProtocol protocol = new TBinaryProtocol(socket); client = new Cassandra.Client(protocol); ... changing them to look like ... socket = new TSocket(hostname, port); TTransport transport = new TFramedTransport(socket) TProtocol protocol = new TBinaryProtocol(transport); client = new Cassandra.Client(protocol); ... should do the trick. For a Python client that looks something like ... socket = TSocket.TSocket(host, port) transport = TTransport.TBufferedTransport(socket) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = Cassandra.Client(protocol) ... change it to look like ... socket = TSocket.TSocket(host, port) transport = TTransport.TFramedTransport(socket) protocol = TBinaryProtocol.TBinaryProtocol(transport) client = Cassandra.Client(protocol) Unless confronted with compelling arguments, Jonathan has agreed to commit this change on Monday, so speak soon or forever hold your peace. :) -- Eric Evans eev...@rackspace.com -- Ian Holsman i...@holsman.net
Re: Web sIte design, humble beginnings ... and a doodle
it looks good to me. On 16/06/2009, at 8:48 AM, Daniel L wrote: Hey guys, A sketch I drew up tonight, as a start: http://stashbox.org/543286/Cassandra_Logo_Draft1.png The general concept being the cassandra mythology, seeing the future (which of course is full of stars), and a cluster image that is not your typical network of nodes or a fractal. :) Cheers, /d -- Ian Holsman i...@holsman.net
Re: working together
just on a point here. They were invited from Day 1 (Actually 20-Jan-2009) to be on there. It wasn't done out of malice. On 08/04/2009, at 6:10 AM, Torsten Curdt wrote: Unfortunately no one noticed that the actual authors bringing the code were NOT on the private list where the vote was held. -- Ian Holsman i...@holsman.net
Re: Random Checkins
ideally the test cases that your working with could be made public, but until then is it possible for you to run a hudson like service inside of FB and mail the test result output to the list so people know that tests are failing. On 03/04/2009, at 1:21 PM, Jonathan Ellis wrote: On Thu, Apr 2, 2009 at 6:37 PM, Avinash Lakshman avinash.laksh...@gmail.com wrote: Another issue with ConcurrentHashMap is that the dude is a memory hog. We got rid of it over a year ago because of the very same reason. Re CHM: what do you suggest instead? I assume you are talking about for EfficientBidiMap. Do you want the Getter to return a copy of the ColumnFamily and stick with non-concurrent structures? Or use NonBlockingHashMap? Also for everything that is done there is a reason. I don't see any harm in, for instance, me making a commit, you saying ConcurrentHashMap is a memory hog, and me saying, okay, what do you suggest instead? Nothing wrong with post-commit review in trunk. I think we are not asking for much to apart from run it by someone before what are basically changes that suit your style. We've tried waiting for you or Prashant to review things. That didn't work over on the code.google project and it hasn't worked here. My remove patches sat unreviewed for weeks, literally. More recently, a request for a list of known issues and my attempt to start a conversation about a roadmap have gone without comment so far. I'm not trying to dump on you; we know you're busy. But we have deadlines too and we can't hold every patch waiting days or weeks for a review. Tell you what. I will try to get changes reviewed by someone in the community before committing. We will see how that works. That should at least give you some confidence that it's not just me off being a cowboy. -Jonathan -- Ian Holsman i...@holsman.net
Welcome to our new committer Jonathan Ellis
It gives me great pleasure to officially welcome Jonathan to the cassandra project as our first comitter since incubation! Congrats! Ian
Re: [Patch] Detect invalid sort order
a better way would be to mail cassandra-priv...@incubator.apache.org. On 22/03/2009, at 8:30 AM, Avinash Lakshman wrote: Hi Alexander Thanks for the patch. Prashant and I run the Cassandra effort and if you ever feel like this Apache process is getting in the way (since this is in its nascent stage) just feel free to ping either one of us at avinash.laksh...@gmail.com or pma...@gmail.com Regards Avinash On Sat, Mar 21, 2009 at 12:56 PM, Alexander Staubo a...@bengler.no wrote: On Sat, Mar 21, 2009 at 7:55 PM, Jeff Hammerbacher jeff.hammerbac...@gmail.com wrote: Thanks for the patch. Now that Cassandra's moved into the Apache incubator, you should open an issue on the JIRA when you find a bug (I've done that for you at https://issues.apache.org/jira/browse/CASSANDRA-8), and you should communicate your problem in the comments on that issue, which will generate an email to the new developer's list, cassandra-dev@incubator.apache.org . Thanks. Actually I could not find a bug tracker since the Incubator page (http://incubator.apache.org/cassandra/) is down. I am not familiar with how the Apache project structures things, so it did not occur to me to sign up for a JIRA account. Is cassandra-dev@incubator.apache.org a development mailing list I should subscribe to? I didn't attach your patch to the issue, since there's a legal disclaimer required during patch submission that I can't make for you. If you have some time, could you attach the patch over at https://issues.apache.org/jira/browse/CASSANDRA-8? Done. Alexander. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cassandra Users group. To post to this group, send email to cassandra-u...@googlegroups.com To unsubscribe from this group, send email to cassandra-user+unsubscr...@googlegroups.comcassandra-user%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cassandra-user?hl=en -~--~~~~--~~--~--~--- -- Ian Holsman i...@holsman.net
