Re: [DISCUSS] CEP-22: Drivers Donation Status

At DataStax, we're trying to make sure we have everything in order from a CLA perspective before moving forward with the process. The drivers have always been Apache-2.0 licensed but we just want to make sure everything is in order. We're really close on the Java driver to move forward. Once

Re: [VOTE] CEP-21 Transactional Cluster Metadata

I just want to say after Alex's presentation at ApacheCon, I'm really excited about this as an underappreciated feature for 5.0: how it will help cluster stability through membership changes and schema evolutions, how it will improve both the scalability of clusters and the flexibility of replic

Re: Role of Hadoop code in Cassandra 5.0

+1 from me to deprecate in 4.x and remove in 5.0. > On Mar 9, 2023, at 12:01 PM, J. D. Jordan wrote: > > +1 from me to deprecate in 4.x and remove in 5.0. > > -Jeremiah > >> On Mar 9, 2023, at 11:53 AM, Brandon Williams wrote: >> >> I think if we reach consensus here that decides it. I too

Re: Role of Hadoop code in Cassandra 5.0

It was mainly to integrate with Hadoop - I used it from 0.6 to 1.2 in production prior to starting at DataStax and at that time I was stitching together Cloudera's distribution of Hadoop with Cassandra. Back then there were others that used it as well. As far as I know, usage dropped off when

Re: Role of Hadoop code in Cassandra 5.0

pt., 10 mar 2023 o 09:56 Berenguer Blasi <mailto:berenguerbl...@gmail.com><mailto:berenguerbl...@gmail.com>> > napisał(a): > > +1 deprecate + removal > > On 10/3/23 1:41, Jeremy Hanna wrote: > It was mainly to integrate with Hadoop - I used it from 0.6 to 1.2 in

Re: [DISCUSS] CEP-26: Unified Compaction Strategy

I think it's important to highlight a few of practical elements of this work that may not be completely clear. Sharding ranges allows for parallel compactions - taking advantage of additional CPUs on the server. This allows compactions to keep up much easier. One much more graceful element of

Re: [DISCUSS] CEP-26: Unified Compaction Strategy

, Jeremy > On Mar 17, 2023, at 4:52 PM, Jeff Jirsa wrote: > > > >> On Mar 17, 2023, at 1:46 PM, Jeremy Hanna wrote: >> >> >> >> One much more graceful element of UCS is that instead of what was previously >> done with compaction st

Re: Welcome our next PMC Chair Josh McKenzie

Thank you Mick for all of your hard work in the project including your time as the PMC chair! Thank you too Josh for all that you do - and for the work that you'll do as chair! > On Mar 23, 2023, at 3:22 AM, Mick Semb Wever wrote: > > It is time to pass the baton on, and on behalf of the Apac

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

Thank you for the write-up and the efforts on CASSANDRA-16222. It sounds like you've been using this for some time. I understand from the rejected alternatives that the Spark Cassandra Connector was slower because it goes through the read and write path for C* rather than this backdoor mechani

Re: [VOTE] CEP-26: Unified Compaction Strategy

+1 nb, will be great to have this in the codebase - it will make nearly every table's compaction work more efficiently. The only possible exception is tables that are well suited for TWCS. > On Apr 4, 2023, at 8:00 AM, Berenguer Blasi wrote: > > +1 > > On 4/4/23 14:36, J. D. Jordan wrote: >>

Re: [DISCUSS] CEP-29 CQL NOT Operator

Considering all of the examples require using ALLOW FILTERING with the partition key specified, I think it's appropriate to consider separating out use of ALLOW FILTERING within a partition versus ALLOW FILTERING across the whole table. A few years back we had a discussion about this in ASF sla

Re: [DISCUSS] CEP-29 CQL NOT Operator

It can be from not specifying the full primary key including clustering columns or it can be across multiple partitions. There are two scenarios. That’s why I created https://issues.apache.org/jira/browse/CASSANDRA-15803 and why I think it’s relevant for this. On Apr 14, 2023, at 9:37 AM, Lorina Po

Re: [POLL] Vector type for ML

I'm all for bringing more functionality to the masses sooner, but the original idea has a very very specific use case. Do we have use cases for a general purpose Vector/Array data structure? If so, awesome. I just wondered if generalizing provides value, beyond being straightforward to implem

Re: [VOTE] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

+1 nb, I had to run Cassandra + Hadoop from the early days (0.7+) and it was painful. This is a major step forward. > On May 4, 2023, at 1:44 PM, Patrick McFadin wrote: > > As somebody who gave this talk: https://youtu.be/9xf_IXNylhM I love the > evolution of this topic. Excited to see this!

Re: CEP-30: Approximate Nearest Neighbor(ANN) Vector Search via Storage-Attached Indexes

I talked to David and some others in slack to hopefully clarify: With SAI, can you have partial results? When you have a query that is non-key based, you need to have full token range coverage of the results. If that isn't possible, will Vector Search/SAI return partial results? Anything can

Re: CEP-30: Approximate Nearest Neighbor(ANN) Vector Search via Storage-Attached Indexes

clear about partial results - the default with DSE Search at least is to fail a query if it can't get the full token range coverage. However there is an option to allow for shards being unavailable and return partial results. > On May 9, 2023, at 3:38 PM, Jeremy Hanna wrote: > >

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

I think it would be great to onboard Harry more officially into the project. However it would be nice to perhaps do some sanity checking outside of Apple folks to see how approachable it is. That is, can someone take it and just run it with the current readme without any additional context? I

[DISCUSS] CEP-8 Drivers Donation - take 2

To add to a somewhat crowded [DISCUSS] party, I'd like to restart the discussion around CEP-8. This is the original thread from July 2020: https://lists.apache.org/thread/01pljcncyjyo467l5orh8nf9okrh7oxm At the time, several good points were discussed and the CEP has been updated with many of

Re: [DISCUSS] CEP-8 Drivers Donation - take 2

I'd like to close out this thread. As Benjamin notes, we'll have a single subproject for all of the drivers and with 3 PMC members overseeing the subproject as outlined in the linked subproject governance procedures. However we'll introduce the drivers to that subproject one by one out of nece

[VOTE] CEP-8 Datastax Drivers Donation

Calling for a vote on CEP-8 [1]. To clarify the intent, as Benjamin said in the discussion thread [2], the goal of this vote is simply to ensure that the community is in favor of the donation. Nothing more. The plan is to introduce the drivers, one by one. Each driver donation will need to be a

Re: [VOTE] CEP-8 Datastax Drivers Donation

3, at 15:19, Chris Lohfink wrote: >> >> +1 >> >> On Wed, Jun 14, 2023 at 9:05 PM Jon Haddad > <mailto:rustyrazorbl...@apache.org>> wrote: >>> +1 >>> >>> On 2023/06/13 14:14:35 Jeremy Hanna wrote: >>> > Calling for a vote o

Re: [DISCUSS] Being specific about JDK versions and python lib versions in CI

I like having the latest patch release always brought in for testing and CI for the JDK versions explicitly supported. So for this release, 11/17.On Jun 22, 2023, at 5:42 PM, Jeremiah Jordan wrote: Yes.  -1 on forcing the patch release version, and possibly minor version, for anything that is

Re: [VOTE] CEP 33 - CIDR filtering authorizer

+1 (nb) will be great to get this into the project. > On Jun 28, 2023, at 12:15 PM, Patrick McFadin wrote: > > +1 > > On Wed, Jun 28, 2023 at 3:42 AM Brandon Williams > wrote: >> +1 >> >> Kind Regards, >> Brandon >> >> >> On Tue, Jun 27, 2023 at 12:17 PM Shailaja Ko

Re: Status Update on CEP-7 Storage Attached Indexes (SAI)

Thanks Caleb and Mike and Zhao and Andres and Piotr and everyone else involved with the SAI implementation!On Jul 25, 2023, at 3:01 PM, Caleb Rackliffe wrote:Just a quick update...With CASSANDRA-18670 complete, and all remaining items in the category of performance optimizations and further testi

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

I think the goal is to say "how could we get some working version of TCM/Accord into people's hands to try out at/by Summit?" That's all. People are eager to see it and try it out. > On Oct 31, 2023, at 12:16 PM, Benedict wrote: > > No, if I understand it correctly we’re in weird hypothetica

Re: [DISCUSS] Harry in-tree

I'm excited for Harry to come in-tree to improve the project stability and quality. I know you're doing a talk at the Cassandra Summit about Harry to go over it. If there's anything that can be done as part of this process to improve onboarding for Harry too, that would be great. I'm just thi

Re: [VOTE] Release Apache Cassandra 5.0-beta1

I want to just follow up with functional versus production-worthy. If I'm a user interested in C* 5 and want to try it out as betas come out, I'm looking more for something functional and not perfect. So in the context of this thread, if I want to try out SAI for example, I don't care as much

Re: Welcome Brad Schoening as Cassandra Committer

Congratulations Brad! > On Feb 21, 2024, at 3:59 PM, Leo Toff wrote: > > Congratulations Brad! Thank you for helping me onboard 🙏 > > On Wed, Feb 21, 2024 at 1:56 PM Jeremiah Jordan > wrote: >> Congrats! >> >> On Feb 21, 2024 at 2:46:14 PM, Josh McKenzie >

Re: Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, Olivier Michallat as Cassandra Committers

Congratulations to all and it’s exciting to see the java driver get its footing with some great contributors/committers. > On Apr 17, 2024, at 12:14 PM, Abe Ratnofsky wrote: > > Congrats everyone! > >> On Apr 17, 2024, at 1:10 PM, Benjamin Lerer wrote: >> >> The Apache Cassandra PMC is pleas

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thanks for being willing to serve in this capacity. Thanks also to Josh for doing a lot of this behind the scenes work this past year. > On Jun 20, 2024, at 11:22 PM, Maxim Muzafarov wrote: > > Congratulations Dinesh! > >> On Fri, 21 Jun 2024 at 05:12, Abhijeet Dubey >> wrote: >> >> Thank

Re: [DISCUSS] spark-cassandra-connector donation to Analytics subproject

+1 nb. I too see these tools (bulk analytics and scc) as complementary as has been said. SCC also does some nice things to support Spark Streaming that I don't think are addressed by the bulk analytics subproject today. Regarding dsbulk, I think that's another thread but it's something we're

Re: [VOTE] Release Apache Cassandra 5.0-rc1

It definitely looks like a good thing to investigate and fix. However, it's not a regression and not new in 5.0. I think we should push forward with 5.0 and fix/release it separately in a 4.1.x and 5.0.x release. > On Jun 27, 2024, at 12:46 PM, Brandon Williams wrote: > > I don't know that w

Re: [VOTE] Release Apache Cassandra 5.0-rc1 (take2)

+1 nb Great to get the fix in so quickly. Thanks all! > On Jul 3, 2024, at 9:59 AM, Jon Haddad wrote: > > +1 > > Thanks Mick! > > On Tue, Jul 2, 2024 at 4:20 AM Mick Semb Wever > wrote: >> >> Proposing the test build of Cassandra 5.0-rc1 for release. >> >> sha1: 01

Re: Improve the performance of CAS

Hi Dikang, Have you seen Blake’s work on implementing egalitarian paxos or epaxos*? That might be helpful for the discussion. Jeremy * https://issues.apache.org/jira/browse/CASSANDRA-6246 > On May 16, 2018, at 3:37 PM, Dikang Gu wrote: > > Hello C* developers, > > I'm working on some perfo

Re: Testing 4.0 Post-Freeze

I wholeheartedly agree with efforts to make releases more stable and the more contributors that add tests or test within the context of their own use cases, the better. +1 non-binding to the idea of better, more complete testing for releases. When it comes to how to do this, I think that’s whe

Re: Testing 4.0 Post-Freeze

4.0 which will make it more successful? > > Not branching is one idea but we should discuss what will change now than > iterating what has already happened. > > On Mon, Jul 9, 2018 at 11:25 AM Jeremy Hanna > wrote: > >> I wholeheartedly agree with efforts to make release

Re: Testing 4.0 Post-Freeze

If this motivates individuals and organizations to contribute time and resources to testing more before the release then +1. The varied testing before the release will make a huge difference. > On Jul 10, 2018, at 12:30 PM, Jeff Jirsa wrote: > > Ultimately, we have a consensus driven developm

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

I don’t know if others have this same question, but what does accepting the gocql driver donation mean? It becomes a full Apache project separate from Cassandra and there exists a separate set of PMC members and such? Or does it become part of the Cassandra project itself? From Sylvain and Jo

Re: [DISCUSS] changing default token behavior for 4.0

I agree that it should be lowered. What I’ve seen debated a bit in the past is the number but I don’t think anyone thinks that it should remain 256. > On Sep 21, 2018, at 7:05 PM, Jonathan Haddad wrote: > > One thing that's really, really bothered me for a while is how we default > to 256 token

Deprecating/removing PropertyFileSnitch?

We have had PropertyFileSnitch for a long time even though GossipingPropertyFileSnitch is effectively a superset of what it offers and is much less error prone. There are some unexpected behaviors when things aren’t configured correctly with PFS. For example, if you replace nodes in one DC and

Re: Deprecating/removing PropertyFileSnitch?

t;>> >>>> We should, but the 4.0 features that log/reject verbs to invalid >> replicas >>>> solves a lot of the concerns here >>>> >>>> -- >>>> Jeff Jirsa >>>> >>>> >>>>> On Oct 16,

Re: Deprecating/removing PropertyFileSnitch?

>>>>>>> Perhaps one good reason to use PFS is the ability to easily package it >>>>>>>> across multiple nodes, as pointed out by Sean Durity on CASSANDRA-10745 >>>>>>>> (which is also it's Achilles' heel). To keep this abi

Re: Deprecating/removing PropertyFileSnitch?

> On Oct 29, 2018, at 11:20 AM, Jeff Jirsa wrote: > > On Mon, Oct 29, 2018 at 8:35 AM Jeremy Hanna > wrote: > >> Re-reading this thread, it sounds like the issue is there are times when a >> field may go missing in gossip and it hasn’t yet been tracked down. As &

Re: JIRA Workflow Proposals

Regarding labels, I am personally a fan of both - the mapping of commonly used labels to things like components, features, tools, etc. as well as keeping labels for newer and more arbitrary groupings. I’ve tried to maintain certain labels like virtual-tables, lcs, lwt, fqltool, etc because ther

Re: Contributing cassandra-diff

It’s great to contribute such a tool. The change between 2.x and 3.0 brought a translation layer from thrift to cql that is hard to validate on real clusters without something like this. Thank you. As for naming, perhaps cassandra-compare might be clearer as diff is an overloaded word but that’

Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

(non-binding) +1 Speaking of the testing, thanks all for the different tooling and test runs. Things like fqltool, cassandra-diff, and the testing that Joey has been doing with https://issues.apache.org/jira/browse/CASSANDRA-14747 are gre

Update defaults for 4.0?

I mentioned this in the contributor meeting as a topic to bring up on the list - should we take the opportunity to update defaults for Cassandra 4.0? The rationale is two-fold: 1) There are best practices and tribal knowledge around certain properties where people just know to update those prope

Re: Update defaults for 4.0?

; > I am in favor of changing these defaults, but should provide very clear > > guidance on vnodes (unless I am wrong). > > > > I'm sure there are others that would be safe to change. I'll review our > > defaults we typically set and report back tomorrow. > > >

Re: Update defaults for 4.0?

nter deployments, and for real production we need to use >GossipingPropertyFileSnitch - why not to set it as default? > > > Jeremy Hanna at "Wed, 22 Jan 2020 11:22:36 +1100" wrote: > JH> I mentioned this in the contributor meeting as a topic to bring up on > t

Re: Update defaults for 4.0?

please do. We should also update our JVM defaults. > > On Thu, Jan 23, 2020, 9:28 PM Jeremy Hanna > wrote: > > > To summarize this thread, I think people are generally okay with updating > > certain defaults for 4.0 provided we make sure it doesn't unpleasantly > &g

[Discuss] num_tokens default in Cassandra 4.0

I wanted to start a discussion about the default for num_tokens that we'd like for people starting in Cassandra 4.0. This is for ticket CASSANDRA-13701 (which has been duplicated a number of times, most recently by me). TLDR, based on ava

Re: [Discuss] num_tokens default in Cassandra 4.0

gt; >>> Thanks for restarting this discussion Jeremy. I personally think 4 is a >>> good number as a default. I think whatever we pick, we should have enough >>> documentation for operators to make sense of the new defaults in 4.0. >>> >>> Dinesh >>

Re: [Discuss] num_tokens default in Cassandra 4.0

I think Mick and Anthony make some valid operational and skew points for smaller/starting clusters with 4 num_tokens. There’s an arbitrary line between small and large clusters but I think most would agree that most clusters are on the small to medium side. (A small nuance is afaict the probabil

Re: [Discuss] num_tokens default in Cassandra 4.0

ng them up for total failure once their > clusters get large like we are now. > > In future versions, we'll probably want to address the issue of data > imbalance by building something in that shifts individual tokens around. I > don't think we should try to do this in 4.0 eit

Re: [Discuss] num_tokens default in Cassandra 4.0

As discussed, let's go with 16. Speaking with Anthony privately as well, I had forgotten that some of the analysis that Branimir had initially done on the skew and allocation may have been internal to DataStax so I should have mentioned that previously. Thanks to Mick, Alex, and Anthony for doing

Re: [VOTE] Project governance wiki doc (take 2)

> On Jun 25, 2020, at 10:56 AM, Jordan West wrote: > > On Wed, Jun 24, 2020 at 3:43 PM Dinesh Joshi wrote: > >> 3. Discussion #3 - "... 1 business day notice period." Whose business day >> is it? US? Europe? Australia? NZ? We are a distributed community and so 1 >> business day is ambiguous

Moving forward towards our best release yet

I've been in the Cassandra community for about 10 years now and I've seen a lot of ups and downs. I care deeply about both the project and the people interacting on the project personally. I consider many of you to be good friends. Regardless of the history that's caused some friction on rece

Re: Update defaults for 4.0?

nsition to LDAP. > > > > Since I planned on experimenting with the whole "what does the confluent > > testing page look like in an epic" today, I'll ping Nate once it's not > > godawfully early in NZ about this. Or he'll read

Re: [Discuss] num_tokens default in Cassandra 4.0

num_tokens: 16. There is a note in the NEWS.txt about upgrading and bootstrapping. It is a lot of effort to change this once it is set, so hopefully new users will be in a much better place out of the box. Thanks everyone for your efforts in this. On Wed, Apr 1, 2020 at 4:28 PM Jeremy Hanna wrote

Re: Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…

I know the dtests take a long time and this will make them longer. As a counter point most people run individual dtests locally and the full set on dedicated test infrastructure. For the dedicated test infrastructure Mick also improved the wall clock runtime when parallelizing the dtests on htt

Re: Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…

Thanks Adam. Now that we have CASSANDRA-16079 created and work is proceeding, can we please commit CASSANDRA-13701? There are many clusters out there that use the default of 256 num_tokens and migrating to something more sane is a lot of work. It would also be very helpful for having reasonab

Re: Supported upgrade path for 4.0

So to reiterate the recommended/tested paths that I get from this thread: 2.1.x -> 2.1.latest -> [3.0.latest | 3.11.latest] -> 4.0 2.2.x -> 2.2.latest -> [3.0.latest | 3.11.latest] -> 4.0 3.0 -> 3.0.latest -> 4.0 3.x -> 3.11.latest -> 4.0 I just wanted to be explicit about getting to the latest i

Re: Requiring Java 8 for C* 3.0

There’s no reason why people can’t run java 8 with 2.1. IIRC the only issue we’d had with it was Dave’s https://issues.apache.org/jira/browse/CASSANDRA-7028. That’s probably the best thing for people to do though - run java 8 with 2.1 so the jump to 3.0 isn’t as significant. Good point. > O

Re: Stream sstables hosted on a node from client using streaming protocol

You may also be interested in this going forward: https://issues.apache.org/jira/browse/CASSANDRA-9259 > On May 9, 2015, at 3:31 PM, Yuki Morishita wrote: > > Hi Pierre, > > I haven't tried writing that kind of client, but I think it should work. > Try providing your own connection provider as

Re: Short column names

It has been talked about in the past, see https://issues.apache.org/jira/browse/CASSANDRA-4175 for example. However with https://issues.apache.org/jira/browse/CASSANDRA-8099, the duplication of column names is gone. So once you’re on Cassandra 3+, this optimization is a lot less valuable. >

Re: Cassandra Java Driver and DataStax

> On Jun 5, 2016, at 4:33 PM, Mattmann, Chris A (3980) > wrote: > > Thanks for the info Jonathan. I think have assessed based on > the replies thus far, my studying of the archives and > commit and project history the following situation. > > Unfortunately it seems like there is a bit of contr

Re: A proposal to move away from Jira-centric development

Jiras are a lot easier to follow as they are focused on a single item of work and it comes with an id that is a lot easier to reference and remember. If there is a high level discussion on the list, that’s fine. A link to that initial discussion can be referenced in the Jira. As already menti

Re: A proposal to move away from Jira-centric development

Regarding high level linking, if I’m in irc or slack or hipchat or a mailing list thread, it’s easy to reference a Jira ID and chat programs can link to it and bots can bring up various details. I don’t think a hash id for a mailing list is as simple or memorable. A feature of a mailing list t

Re: A proposal to move away from Jira-centric development

project. > On Aug 15, 2016, at 1:27 PM, Chris Mattmann wrote: > > s/dev list followers// > > That’s (one of) the disconnect(s). It’s not *you the emboldened, powerful > PMC* > and then everyone else. > > > On 8/15/16, 11:25 AM, "Jeremy Hanna" wrote:

Re: A proposal to move away from Jira-centric development

I think a separate mailing list for just ticket creation would be nice as well. I think that’s what many of us filter down the commits@ list to. That doesn’t have to happen in place of the proposed change but would make it easier for people to follow new issue creation. From there I go to and

Proposal: create a mailing list for just the newly created Jira ticket notifications

Currently we have a mailing list (commits@) that includes commit messages as well as all updates to Jira tickets. However for the purpose of staying up to date with new tickets, it’s something of a firehose with the rapid rate of change. Some people (like me) filter out just the new ticket cre

Re: Support Multi-Tenant in Cassandra

I agree that the request scheduler should probably be deprecated and removed unless someone wants to put in something that's usable from the non thrift request processor. We added it for prioritization and QoS but I don't know of anyone ever using it. Our project we thought of using it for got s

Re: Support Multi-Tenant in Cassandra

pros/cons of why we as a community choose to not do it, > postpone for later, or actually do it. Of course, it would be great for a > motivated individual to lead the effort if we really want to entertain it. > > On Friday, September 9, 2016, Jeremy Hanna > wrote: > >> I agree

Re: Proposal: create a mailing list for just the newly created Jira ticket notifications

edDate DESC >>> >>> When viewing your filter, go to Details > New Subscription and set it up >> to >>> run once a day and you're set! >>> >>> Hope it helps, >>> >>> Russ >>> >>> On Mon, Aug 29, 2016 at

Re: Proposal - 3.5.1

Right - I think like Jake and others have said, it seems appropriate to do something at this point. Would a clearer, more liberal backport policy to the odd versions be worthwhile until we find our footing? As Jeremiah said, it does seem like the big bang 3.0 release has caused much of the bag

Re: Low hanging fruit crew

And just to be clear, I think everyone would welcome more testing for both regressions of new code correctness. I think everyone would appreciate the time savings around more automation. That should give more time for a thoughtful review - which is likely what new contributors really need to g

Re: Low hanging fruit crew

.apache.org/jira/browse/CASSANDRA-12541 , >>>>> https://issues.apache.org/jira/browse/CASSANDRA-12776 ) >>>>> 2) Some of these patches already exist and just need to be reviewed >> and >>>>> eventually committed. >>>>> >>>>

Re: Proposal - 3.5.1

Is there consensus on a way forward with this? Is there going to be a three branch plan with “features”, “testing”, and “stable” starting with 4.0? Or is this still in the discussion mode? External to this thread there have been decisions made to create third party LTS releases and hopes that

Re: Proposal - 3.5.1

ttps://www.instaclustr.com/blog/2016/10/19/patched-cassandra-3-7/ > - https://github.com/instaclustr/cassandra#faq > > > On Thu, 20 Oct 2016 at 09:38 Jeremy Hanna > wrote: > >> Is there consensus on a way forward with this? Is there going to be a >> three branch

Re: DataStax role in Cassandra and the ASF

Hi Łukasz, I’m sorry you found the projects difficult to work with. It sounds like in this case it was about modularizing with Maven and making TinkerPop work better with OSGI. People in the project have been going back and forth about the build process since before Riptano and DataStax exist

Re: DataStax role in Cassandra and the ASF

t any qualification :) Kind regards, Jeremy > On Nov 4, 2016, at 10:58 PM, Jeremy Hanna wrote: > > Hi Łukasz, > > I’m sorry you found the projects difficult to work with. It sounds like in > this case it was about modularizing with Maven and making TinkerPop work > better

Re: DataStax role in Cassandra and the ASF

If the ASF is at risk with a single company allowed to dominate a project then why couldn't the approach have been something like: "great job on building a successful project and community. We think there is great potential for more involvement at the core contribution level. How can we work tog

Re: DataStax role in Cassandra and the ASF

> On Nov 5, 2016, at 10:02 AM, Jim Jagielski wrote: > > Which is what was done: https://whimsy.apache.org/board/minutes/Cassandra.html > >> On Nov 5, 2016, at 10:48 AM, Jeremy Hanna wrote: >> >> If the ASF is at risk with a single company allowed to dominate a pr

Re: DataStax role in Cassandra and the ASF

Ultimately it doesn't matter now. The project has a bright future with the involvement of all individuals regardless of the company they work for. That's the important thing. > On Nov 5, 2016, at 10:30 AM, Jeremy Hanna wrote: > > No it wasn't. You're citing

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

Regarding low hanging fruit, on the How To Contribute page [1] we’ve tried to keep a list of lhf tickets [2] linked to help people get started. They are usually good starting points and don’t require much context. I rarely see duplicates from lhf tickets. Regarding duplicates, in my experienc

Re: Rollback procedure for Cassandra Upgrade.

See the comment thread on https://issues.apache.org/jira/browse/CASSANDRA-8928 (add downgradesstables) > On Jan 10, 2017, at 5:00 AM, Jonathan Haddad wrote: > > There's no downgrade procedure. You either upgrade or you go back to a > snapsho

Re: Truncate operation not available in Mutation Object

Everything in that table is deleted. There's no mutation or anything in the commitlog. It's a deletion of all the sstables for that table. To make sure everything is gone, it first does a flush, then a snapshot to protect against a mistake, then the truncate itself. > On Feb 22, 2017, at 6:05 P

Re: Truncate operation not available in Mutation Object

Does it leave a trace that the truncate happened anywhere? >> >> >> Best regards, >> Sanal >> >> On Thu, Feb 23, 2017 at 11:47 AM, Jeremy Hanna >> >> wrote: >> >>> Everything in that table is deleted. There's no mutation or

Re: Contribute to the Cassandra wiki

The moinmoin wiki was preferred but because of spam, images couldn’t be attached. The options were to use confluence or have a moderated list of individuals be approved to update the wiki. The decision was made to go with the latter because of the preference to stick with moinmoin rather than

Re: Contribute to the Cassandra wiki

The moinmoin wiki was preferred but because of spam, images couldn’t be attached. The options were to use confluence or have a moderated list of individuals be approved to update the wiki. The decision was made to go with the latter because of the preference to stick with moinmoin rather than

Re: Contribute to the Cassandra wiki

The moinmoin wiki was preferred but because of spam, images couldn’t be attached. The options were to use confluence or have a moderated list of individuals be approved to update the wiki. The decision was made to go with the latter because of the preference to stick with moinmoin rather than

Re: Contribute to the Cassandra wiki

Sorry - speaking of spam - my mail client went a bit crazy. Apologies if the last message was sent a few times. > On Mar 13, 2017, at 10:28 AM, Jeremy Hanna wrote: > > The moinmoin wiki was preferred but because of spam, images couldn’t be > attached. The options were to use c

Re: Contribute to the Cassandra wiki

The moinmoin wiki was preferred but because of spam, images couldn’t be attached. The options were to use confluence or have a moderated list of individuals be approved to update the wiki. The decision was made to go with the latter because of the preference to stick with moinmoin rather than

Re: Contribute to the Cassandra wiki

The moinmoin wiki was preferred but because of spam, images couldn’t be attached. The options were to use confluence or have a moderated list of individuals be approved to update the wiki. The decision was made to go with the latter because of the preference to stick with moinmoin rather than

Re: Contribute to the Cassandra wiki

The moinmoin wiki was preferred but because of spam, images couldn’t be attached. The options were to use confluence or have a moderated list of individuals be approved to update the wiki. The decision was made to go with the latter because of the preference to stick with moinmoin rather than

Re: Contribute to the Cassandra wiki

The moinmoin wiki was preferred but because of spam, images couldn’t be attached. The options were to use confluence or have a moderated list of individuals be approved to update the wiki. The decision was made to go with the latter because of the preference to stick with moinmoin rather than

Re: Contribute to the Cassandra wiki

The moinmoin wiki was preferred but because of spam, images couldn’t be attached. The options were to use confluence or have a moderated list of individuals be approved to update the wiki. The decision was made to go with the latter because of the preference to stick with moinmoin rather than

Re: Code quality, principles and rules

https://issues.apache.org/jira/browse/CASSANDRA-7837 may be some interesting context regarding what's been worked on to get rid of singletons and static initialization. > On Mar 17, 2017, at 4:47 PM, Jonathan Haddad wrote: > > I'd like to think that if someone refactors existing code, making i

Re: [VOTE] self-assignment of jira tickets

+1 non-binding. I’ve always wondered why that restriction was in place. > On Mar 29, 2017, at 8:21 AM, Jason Brown wrote: > > Hey all, > > Following up my thread from a week or two ago ( > https://lists.apache.org/thread.html/0665f40c7213654e99817141972c003a2131aba7a1c63d6765db75c5@%3Cdev.cass

Re: unsubscribe

To unsubscribe, send an email to dev-unsubscr...@cassandra.apache.org . Replying to this email does not unsubscribe you from any list. It simply perpetuates a long thread of useless emails. > On Apr 10, 2017, at 9:30 AM, Asanka Samaraweera wrote: >

  1   2   >