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:

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

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: 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: >> >>

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

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: [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: [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

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

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

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

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

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

[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

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

[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] 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?

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

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: > > I talked

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: [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: [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

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

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

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-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

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

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

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 strategies where the server just shuts dow

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: Role of Hadoop code in Cassandra 5.0

3 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 > producti

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

+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

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

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: Naming conventions for CQL native functions

+1 (nb) mixed case is a miserable experience and snake case makes it readable. > On Nov 10, 2022, at 10:57 AM, Francisco Guerrero wrote: > > +1 (nb) as well > >> On 2022/11/10 17:16:21 Caleb Rackliffe wrote: >> +100 on snake case for built-in functions given I think MySQL and Postgres >>

Re: Thanks to Nate for his service as PMC Chair

Thanks Nate for all of your behind the scenes work! Thanks Mick for stepping up even more to help with the project! > On Jul 11, 2022, at 7:54 AM, Paulo Motta wrote: > > Hi, > > I wanted to announce on behalf of the Apache Cassandra Project Management > Committee (PMC) that Nate McCall

Re: New Apache Cassandra Group on LinkedIn

Is it possible to ask someone at linkedin to merge the groups together so that it's managed by the PMC but with the explicit permission of the people running the other group? In the past, I know that Twitter does things like that in terms of handles and followers. Is that a desirable outcome?

Re: [DISCUSS] CASSANDRA-17292 Move cassandra.yaml toward a nested structure around major database concepts

If we support both formats for a time, I just would want to make absolutely sure that it will read only one or the other so there's no uncertainty about the server configuration. Perhaps to avoid unforeseen migration problems, we only read the old format if a specific flag is set? So with

Re: [VOTE] CEP-7: Storage Attached Index

+1 nb. Thanks Caleb, Mike, Jason, and everyone involved with the effort. > On Feb 17, 2022, at 4:23 PM, Caleb Rackliffe wrote: > >  > Hi everyone, > > I'd like to call a vote to approve CEP-7. > > Proposal: >

Re: [VOTE] CEP-19: Trie memtable implementation

+1 nb. Thanks for all of the great work on this Branimir. Excited to see this moving forward. > On Feb 16, 2022, at 7:56 AM, J. D. Jordan wrote: > > +1 nb > >> On Feb 16, 2022, at 7:30 AM, Josh McKenzie wrote: >> >>  >> +1 >> >> On Wed, Feb 16, 2022, at 7:33 AM, Ekaterina Dimitrova

Re: [DISCUSS] Java support roadmap

One of the things I'm excited about with the 4+ releases is this running with Java 17+ (including ZGC) so I would love to see this get more serious testing and validation. Anecdotal account - at an event a couple of years ago, I spoke to someone from an education software company was running

Re: [DISCUSS] CEP 14: Paxos Improvements

It sounds like a great improvement! Just for those who had followed the development of ePaxos* that Blake and others worked on but was never committed, it would be nice to briefly compare the two. https://issues.apache.org/jira/browse/CASSANDRA-6246 > On Aug 19, 2021, at 9:18 AM, Scott

Re: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

+1 nb On Sat, Jul 24, 2021 at 11:50 AM Scott Andreas wrote: > +1 nb > > > On Jul 23, 2021, at 2:46 PM, Mick Semb Wever wrote: > > > >  > >> > >> > >> The vote will be open for 72 hours (longer if needed). Everyone who > >> has tested the build is invited to vote. Votes by PMC members are > >>

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 (nb) > On Jul 15, 2021, at 3:42 AM, Blake Eggleston > wrote: > > +1 > >> On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko wrote: >> >> +1 >> On 14 Jul 2021, at 15:37, Jonathan Ellis wrote: >>> >>> +1 >>> On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever wrote:

Re: [VOTE] Release Apache Cassandra 4.0-rc2

+1 (nb) nice to see all of the fixes and the use of newer TLS by default and obfuscation of passwords in the audit log for the 4.0 release. > On Jun 29, 2021, at 6:01 AM, Jon Meredith wrote: > > +1 (nb) > >> On Mon, Jun 28, 2021 at 9:47 AM Yifan Cai wrote: >> >> +1 >> >> >> - Yifan >>

Re: Welcome Caleb Rackliffe as Cassandra committer

Congratulations Caleb! > On May 14, 2021, at 11:02 PM, Mick Semb Wever wrote: > > The PMC members are pleased to announce that Caleb Rackliffe has > accepted the invitation to become committer. > > Thanks heaps Caleb for helping make Cassandra awesome! > > Congratulations and welcome, > The

Re: [DISCUSSION] Attracting new contributors

periodic group chat to talk through one of the issues that they > may be working on together as a group with an active contributor might make > sense, and be more targeted in focus? > > > On 27/04/2021, 12:45, "Manish G" wrote: > >Contributor bootcamps can really help n

Re: [DISCUSSION] Attracting new contributors

One thing we've done in the past is contributor bootcamps along with the the new contributor guide and the LHF complexity tickets. Unfortunately, I don't know that the contributor bootcamps were ever recorded. Presentations were done to introduce people to the codebase generally (I think Gary

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

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

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

Re: [Discuss] num_tokens default in Cassandra 4.0

with 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: Update defaults for 4.0?

; > 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 this email, either way. > :) > >

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

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

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

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

Re: [Discuss] num_tokens default in Cassandra 4.0

t; 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 >>> >&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

Re: Update defaults for 4.0?

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 > > sur

Re: Update defaults for 4.0?

yments, 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 > the list -

Re: Update defaults for 4.0?

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. > > > > On Tue, Jan 21, 2020, 7:22 PM Jeremy Hanna > > wrote: > > > > > I mentioned this in t

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

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

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

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

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: Deprecating/removing PropertyFileSnitch?

age it >>>>>>>> across multiple nodes, as pointed out by Sean Durity on CASSANDRA-10745 >>>>>>>> (which is also it's Achilles' heel). To keep this ability, we could >>>>> make >>>>>>&

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

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

Re: Testing 4.0 Post-Freeze

e for 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

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

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

Re: Roadmap for 4.0

On Wed, Apr 4, 2018 at 7:50 PM, Michael Shuler wrote: > On 04/04/2018 07:06 PM, Nate McCall wrote: > > > > It feels to me like we are coalescing on two points: > > 1. June 1 as a freeze for alpha > > 2. "Stable" is the new "Exciting" (and the testing and dogfooding > >

Re: Proposal to retroactively mark materialized views experimental

At the risk of sounding redundant it sounds like for MVs at this point we want to preserve current functionality for existing users. We would have a flag in the yaml to disable it by default for new MV creation with an error message. In addition we want a warning in the log and in cqlsh upon

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

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 ( >

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

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: Truncate operation not available in Mutation Object

t such a truncate operation was performed on the >> table? Does it leave a trace that the truncate happened anywhere? >> >> >> Best regards, >> Sanal >> >> On Thu, Feb 23, 2017 at 11:47 AM, Jeremy Hanna <jeremy.hanna1...@gmail.com >>> >>

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

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

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

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 <jeremy.hanna1...@gmail.com> wrote: > > No it wasn't

Re: DataStax role in Cassandra and the ASF

Nov 5, 2016, at 10:02 AM, Jim Jagielski <j...@jagunet.com> wrote: > > Which is what was done: https://whimsy.apache.org/board/minutes/Cassandra.html > >> On Nov 5, 2016, at 10:48 AM, Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote: >> >> If the ASF is at risk

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

Re: DataStax role in Cassandra and the ASF

t any qualification :) Kind regards, Jeremy > On Nov 4, 2016, at 10:58 PM, Jeremy Hanna <jeremy.hanna1...@gmail.com> 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 ma

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

Re: Low hanging fruit crew

; 1) There’s a lot of low hanging tickets that would benefit from >> outside >>>>> contributors as their first-patch in Cassandra (like >>>>> https://issues.apache.org/jira/browse/CASSANDRA-12541 , >>>>> https://issues.apache.org/jira/browse/CASSANDRA

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

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

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

> >>> Russ >>> >>> On Mon, Aug 29, 2016 at 10:45 AM, Jonathan Haddad <j...@jonhaddad.com> >>> wrote: >>> >>>> A daily digest of new issues would be incredible. A non-binding +1 >> from >>>> this guy. >>>

Re: Support Multi-Tenant in Cassandra

l-informed 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 <jeremy.hanna1...@

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

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

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

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

project. > On Aug 15, 2016, at 1:27 PM, Chris Mattmann <mattm...@apache.org> 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, "

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

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

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. >

  1   2   >