Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 On Mon, Feb 6, 2023, at 11:15 AM, Sam Tunnicliffe wrote: > Hi everyone, > > I would like to start a vote on this CEP. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata > > Discussion: > https://lists.apache.org/thread/h25skwkbdztz9

Re: Welcome Patrick McFadin as Cassandra Committer

Welcome Patrick! Thank you for your years of contributions to the community. On Thu, Feb 2, 2023, at 12:58 PM, Benjamin Lerer wrote: > The PMC members are pleased to announce that Patrick McFadin has accepted > the invitation to become committer today. > > Thanks a lot, Patrick, for everything yo

Re: [DISCUSS] Lift MessagingService.minimum_version to 40 in trunk

Hi, I am pretty strongly in favor just to keep the amount of code kept around for serialization/deserialization and caching serialized sizes for different versions under control. 5.0 will have changes necessitating using another version so it will be adding to the clutter. Ariel On Mon, Mar

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

Hi, Support for multiple storage backends including remote storage backends is a pretty high value piece of functionality. I am happy to see there is interest in that. I think that `ChannelProxyFactory` as an integration point is going to quickly turn into a dead end as we get into really usin

Future direction for the row cache and OHC implementation

Hi, Now seems like a good time to discuss the future direction of the row cache and its only implementation OHC (https://github.com/snazy/ohc). OHC is currently unmaintained and we don’t have the ability to release maven artifacts for it or commit to the original repo. I have reached out to the

Re: Future direction for the row cache and OHC implementation

Hi, To add some additional context. The row cache is disabled by default and it is already pluggable, but there isn’t a Caffeine implementation present. I think one used to exist and could be resurrected. I personally also think that people should be able to scratch their own itch row cache w

Re: Future direction for the row cache and OHC implementation

gt;>> So, unless it is being widely used by someone else outside of the >>> community (which it doesn't seem to be), from a maintenance and >>> integration testing perspective I think it would be better to keep the >>> ohc in-tree, so we will be aware of any i

Re: Future direction for the row cache and OHC implementation

Hi, Thanks for the generous offer. Before you do that can you give me a chance to add back support for Caffeine for the row cache so you can test the option of switching back to an on-heap row cache? Ariel On Thu, Dec 14, 2023, at 9:28 PM, Jon Haddad wrote: > I think we should probably figure

Re: [DISCUSS] CEP-39: Cost Based Optimizer

Hi, I am burying the lede, but it's important to keep an eye on runtime-adaptive vs planning time optimization as the cost/benefits vary greatly between the two and runtime adaptive can be a game changer. Basically CBO optimizes for query efficiency and startup time at the expense of not handli

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

🥳🎉 Thanks for your work on this. Excited to have an easier way to write tests that leverage schema and data that also covers more. Ariel On Sat, Dec 23, 2023, at 9:17 AM, Alex Petrov wrote: > Thanks everyone, Harry is now in tree! Of course, that's just a small > milestone, hope it'll prove as

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

Hi, If there is a faster/better way to replace a node why not have Cassandra support that natively without the sidecar so people who aren’t running the sidecar can benefit? Copying files over a network shouldn’t be slow in C* and it would also already have all the connectivity issues solved.

Re: discuss: add to_human_size function

Hi, I think it’s a good quality of life improvement, but I am someone who believes in a rich set of built-in functions being a good thing. A format function is a bit more scope and kind of orthogonal. It would still be good to have shorthand functions for things like size. Ariel On Tue, Apr 9

Re: [DISCUSS] ccm as a subproject

Hi, Strong +1 as well. It's a pretty critical dependency in the path of testing and committing changes. Supporting integration points for alternative distributions of Cassandra is something I think we should generally be supportive as it's generally an opportunity to make things more modular an

Re: CCM and CASSANDRA_USE_JDK11

Hi, There is definitely a mismatch between how the full range of dtests work and the direction CCM is going in and we have some difficulty getting those to match. I fully empathize with several of those CI systems not being publicly visible/accessible, and the behavior of upgrade paths being ab

Re: CCM and CASSANDRA_USE_JDK11

that they run the same set of tests in >>> as similar environments as possible >> Yeah, I took a superset of circle and ASF tests to try and run >> :allthethings:. Part of how the checkstyle dependency check got in the way >> too, since we weren't running that

Re: [DISCUSS] Stream Pipelines on hot paths

+1. To not using streams in hot paths. Regarding string concatenation in logging, for debug and trace it makes sense to avoid concatenation. For info and error I don't think it matters and it can be more concise to concatenate. It's not a big deal to standardize on one just because the extra ve

Re: [DISCUSS] Increments on non-existent rows in Accord

Hi, I think the current behavior maps to SQL more than CQL. In SQL an update doesn't generate an error if the row to be updating doesn't exist it just return 0 rows updated. If someone wanted an upsert or increment behavior in their transaction could they accomplish it with the current transa

Re: [DISCUSS] Increments on non-existent rows in Accord

condition was met but couldn't update a non-existent row), or > CONDITION_NOT_MET > > > On Mon, Jun 24, 2024 at 11:42 AM Ariel Weisberg wrote: >> __ >> Hi, >> >> I think the current behavior maps to SQL more than CQL. In SQL an update >>

Re: [DISCUSS] CEP-42: Constraints Framework

Hi, I see a vote for this has been called. I should have provided more prompt feedback sooner. I am a strong +1 on adding column level constraints being a good thing to add. I'm not too concerned about row/partition/table level constraints, but I would like to change the syntax before I would

Re: [DISCUSS] CEP-42: Constraints Framework

those application > level constraints that Doug mentions in an more accesible way than having to > configure such specific guardrais. > > For the addition of the CHECK keyword, I'm definitely not opposed to it if it > helps Cassandra users coming from other databases un

Re: [VOTE] CEP-42: Constraints Framework

Hi, I am +1 on CEP-42 with the latest updates to the CEP to clarify syntax, error messages, constraint naming and generated naming, alter/drop, describe etc. I think this now tracks very closely to how other SQL databases define constraints and the syntax is easily extensible to multi-column an

Re: Evolving the client protocol

ke a potential approach. > > > > This would give you a path forward at least for the short term. > > > > > > On Thu, Apr 19, 2018 at 12:10 PM Ariel Weisberg wrote: > > > >> Hi, > >> > >> I think that updating the protocol spec to Cassa

Re: Evolving the client protocol

contribute an Apache >> licensed thread per core implementation in Java that matches the protocol >> change and shard concept you are looking for ;P > > I doubt I'll survive the egregious top-posting that is going on in this list. > >> >> >>>

Re: Improve the performance of CAS

Hi, I think you are looking at the right low hanging fruit. Cassandra deserves a better consensus protocol, but it's a very big project. Regards, Ariel On Wed, May 16, 2018, at 5:51 PM, Dikang Gu wrote: > Cool, create a jira for it, > https://issues.apache.org/jira/browse/CASSANDRA-14448. I hav

Re: GitHub PR ticket spam

Hi, I really like having it mirrored. I would not be in favor of eliminating automated mirroring. What we are seeing is that removing the pain of commenting in JIRA is encouraging people to converse more in finer detail. That's a good thing. I have also seen the pain of how various github work

Re: GitHub PR ticket spam

Hi, Great idea. +1 to moving it to the work log. Thanks, Ariel On Mon, Aug 6, 2018, at 12:40 PM, Aleksey Yeshchenko wrote: > Nice indeed. I assume it also doesn’t spam commits@ when done this way, > in which case double +1 from me. > > — > AY > > On 6 August 2018 at 17:18:36, Jeremiah D Jorda

Re: upgrade guava on trunk before 9/1?

Hi, What do we get from Guava in exchange for upgrading? Ariel On Wed, Aug 15, 2018, at 10:19 AM, Jason Brown wrote: > Hey all, > > Does anyone feel strongly about upgrading guava on trunk before the 9/1 > feature freeze for 4.0? We are currently at 23.3 (thanks to > CASSANDRA-13997), and the c

Re: upgrade guava on trunk before 9/1?

r at least two years from now. > > As I asked, "does anybody feeling strongly?". Personally, I'm sorta +0 to > +0.5, but I was just throwing this out there in case someone does really > think it best we upgrade (and wants to make a contribution). > > -Jason > >

Transient Replication 4.0 status update

Hi all, I wanted to give everyone an update on how development of Transient Replication is going and where we are going to be as of 9/1. Blake Eggleston, Alex Petrov, Benedict Elliott Smith, and myself have been working to get TR implemented for 4.0. Up to now we have avoided merging anything r

Re: Transient Replication 4.0 status update

#x27;m not familiar with how much work has gone into fixing cluster expansion > with vnodes, it is my understanding that you typically expand only one node > at a time or in multiples of the datacenter size > > On Mon, Aug 27, 2018 at 12:29 PM Ariel Weisberg wrote: > > > Hi al

Re: Transient Replication 4.0 status update

rent nodes? Admittedly > > I'm not familiar with how much work has gone into fixing cluster expansion > > with vnodes, it is my understanding that you typically expand only one node > > at a time or in multiples of the datacenter size > > > > On Mon, Aug 27, 2018

Re: Request for post-freeze merge exception

+1 Transient Replication had some rebase pain as well, but we were able to get through it at the last minute. The traffic on the last few days was pretty heavy with several substantial commits. On Tue, Sep 4, 2018, at 2:19 PM, Jeff Jirsa wrote: > Seems like a reasonable thing to merge to me. Not

Re: Recommended circleci settings for DTest

Hi, Apply the following diff and if you have access to the higher memory containers it should run the dtests with whatever you have. You may need to adjust parallelism to match whatever you paid for. diff --git a/.circleci/config.yml b/.circleci/config.yml index 5a84f724fc..76a2c9f841 100644 --

Re: Recommended circleci settings for DTest

/development/testing.rst#circleci > > > > On Fri, Sep 28, 2018 at 2:55 PM Ariel Weisberg wrote: > > > Hi, > > > > Apply the following diff and if you have access to the higher memory > > containers it should run the dtests with whatever you have. You may need t

Re: Implicit Casts for Arithmetic Operators

Hi, I think we should decide based on what is least surprising as you mention, but isn't overridden by some other concern. It seems to me the priorities are * Correctness * Performance * User visible complexity * Developer visible complexity Defaulting to silent implicit data loss is not ideal

Re: Implicit Casts for Arithmetic Operators

> changes to go unnoticed on a JIRA, and then ossify. > > > > On 2 Oct 2018, at 15:48, Ariel Weisberg wrote: > > > > Hi, > > > > I think we should decide based on what is least surprising as you mention, > > but isn't overridden by some o

CASSANDRA-13241 lower default chunk_length_in_kb

Hi, This is regarding https://issues.apache.org/jira/browse/CASSANDRA-13241 This ticket has languished for a while. IMO it's too late in 4.0 to implement a more memory efficient representation for compressed chunk offsets. However I don't think we should put out another release with the current

Re: Tested to upgrade to 4.0

Hi, Thanks for reporting this. I'll get this fixed today. Ariel On Fri, Oct 12, 2018, at 7:21 AM, Tommy Stendahl wrote: > Hi, > > I tested to upgrade to Cassandra 4.0. I had an existing cluster with > 3.0.15 and upgraded the first node but it fails to start due to a > NullPointerException. >

Re: Implicit Casts for Arithmetic Operators

Hi, I agree with what's been said about expectations regarding expressions involving floating point numbers. I think that if one of the inputs is approximate then the result should be approximate. One thing we could look at for inspiration is the SQL spec. Not to follow dogmatically necessaril

Re: Implicit Casts for Arithmetic Operators

perand always be the > return type. > > This would still leave a decision for float+double, though. The most > consistent behaviour with that stated above would be to always take the > most approximate type to return (i.e. float), but this would seem to me > to be fairl

Re: CASSANDRA-13241 lower default chunk_length_in_kb

the small size and the large > > improvement to new users experience (as long as we are explicit in the > > documentation about memory consumption). > > > > > >> On Thu, Oct 11, 2018 at 7:11 PM Ariel Weisberg wrote: > >> > >> Hi, > >>

Re: CASSANDRA-13241 lower default chunk_length_in_kb

s a > > consensus here as well, > > > > C*heers, > > --- > > Alain Rodriguez - al...@thelastpickle.com > > France / Spain > > > > The Last Pickle - Apache Cassandra Consulting > > http://www.thelastpickle.com > > >

Re: CASSANDRA-13241 lower default chunk_length_in_kb

at 5:32 AM, Benedict Elliott Smith wrote: > FWIW, I’m not -0, just think that long after the freeze date a change > like this needs a strong mandate from the community. I think the change > is a good one. > > > > > > > On 17 Oct 2018, at 22:09, Ariel Weisberg wrote:

Re: CASSANDRA-13241 lower default chunk_length_in_kb

5:20 64k 25:33 32k 20:01 16k 19:19 16k 19:14 8k 16:51 4k 15:39 Ariel On Thu, Oct 18, 2018, at 2:55 PM, Ariel Weisberg wrote: > Hi, > > For those who were asking about the performance impact of block size on > compr

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Hi, To summarize who we have heard from so far WRT to changing just the default: +1: Jon Haddadd Ben Bromhead Alain Rodriguez Sankalp Kohli (not explicit) -0: Sylvaine Lebresne Jeff Jirsa Not sure: Kurt Greaves Joshua Mckenzie Benedict Elliot Smith WRT to change the representation: +1: Ther

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Hi, I just asked Jeff. He is -0 and -0.5 respectively. Ariel On Tue, Oct 23, 2018, at 11:50 AM, Benedict Elliott Smith wrote: > I’m +1 change of default. I think Jeff was -1 on that though. > > > > On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: > > > > Hi, &

Re: Proposed changes to CircleCI testing workflow

Hi, Thank you for working on this. These all sound like good changes to me. Ariel On Fri, Oct 26, 2018, at 10:49 AM, Stefan Podkowinski wrote: > I'd like to give you a quick update on the work that has been done > lately on running tests using CircleCI. Please let me know if you have > any objec

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Use a more space efficient representation for compressed chunk offsets" for post 4.0. Regards, Ariel On Tue, Oct 23, 2018, at 11:46 AM, Ariel Weisberg wrote: > Hi, > > To summarize who we have heard from so far > > WRT to changing just the default: > > +1: > Jon H

Re: Implicit Casts for Arithmetic Operators

we will hopefully minimise surprise to operators this way. >> >> If people largely agree, I will call a vote, and we can pick up a couple >> of more focused discussions afterwards on how we interpret the leeway it >> gives. >> >> >>> On 12 Oct 2

Re: Request to review feature-freeze proposed tickets

Hi, I would like to get as many of these as is feasible in. Before the feature freeze started 1 out of 17 JIRAs that were patch available were reviewed and committed. If you didn’t have access reviewers and committers, as the one out of the 17 did, it has been essentially impossible to get you

Re: JIRA Workflow Proposals

Hi, Late but. 1. A 2. +1 3. +1 4. -1 5. -0 6. +1 RE 4, I think blocker is an important priority. High and urgent mean the same thing to me. Wish is fine, but that is too similar to low if you ask me. My ideal would be low, medium, high, blocker. Medium feels weird, but it's a real thing, it's

Re: JIRA Workflow Proposals

> > > > On 7 Dec 2018, at 17:52, Ariel Weisberg wrote: > > > > Hi, > > > > Late but. > > No harm in them continuing to roll in, I’m just cognisant of needing to > annoy everyone with a second poll, so no point perpetuating it past a > likely una

Re: JIRA Workflow Proposals

ack Ariel’s dissenting view. > > My votes are: > 1: +1 > 2: B,C,A > 3: A > 4: +0.5 > > > For tracking, the new consensus from the prior vote is: > 1: A (+10) > 2: +9 -0.1 > 3: +10 > 4: +6 -2 (=+4) > 5: +2; a lot of meh. > 6: +9 > > > > > On 7

Re: JIRA Workflow Proposals

e I don't think it's that harmful either. Ariel On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote: > On 10 Dec 2018, at 16:21, Ariel Weisberg wrote: > > > > Hi, > > > > RE #1, does this mean if you submit a ticket and you are not a contributor >

Re: JIRA Workflow Proposals

Hi, Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged. 1. E, D, C, B, A 2. B, C, A 3. A 4. -.5 Ariel On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote: > Hi, > > Sorry I was just slow on the uptake as to what auto-populate meant RE #2. > &g

Re: Revisit the proposal to use github PR

Hi, I'm not clear on what github makes worse. It preserves more history then the JIRA approach. When people invitably force push their branches you can't tell from the link to a branch on JIRA. Github preserves the comments and force push history so you know what version of the code each commen

Re: Revisit the proposal to use github PR

t well, unless there's some > technique I and perhaps others are unaware of. > > On Thu, Dec 13, 2018 at 9:47 AM Ariel Weisberg wrote: > > > Hi, > > > > I'm not clear on what github makes worse. It preserves more history then > > the JIRA approach. When p

Re: [VOTE] Change Jira Workflow

+1 On Mon, Dec 17, 2018, at 10:19 AM, Benedict Elliott Smith wrote: > I propose these changes > * > > to the Jira Workflow for the project. The vote will be open for 72 > hours**. > > I am, of course, +1. > > * W

Re: Git Repo Migration

+1 On Fri, Jan 4, 2019, at 5:49 AM, Sam Tunnicliffe wrote: > As per the announcement on 7th December 2018[1], ASF infra are planning > to shutdown the service behind git-wip-us.apache.org and migrate all > existing repos to gitbox.apache.org > > There are further details in the original mail,

Re: Implementing an Abstract Replication Strategy

Hi, Cassandra expects a replication strategy to accept a description of a consistent hash ring and then use that description to determine what ranges on the consistent hash ring each node replicates. If you implement the API those operations should all just work. I'm not sure what the implici

Re: [VOTE] Release Apache Cassandra 2.2.14

Hi, Can we also run the upgrade tests? We should do that as part of the release process. I can do that tomorrow. Ariel On Tue, Feb 5, 2019, at 1:11 PM, Joseph Lynch wrote: > 2.2.14-tentative unit and dtest run: > https://circleci.com/gh/jolynch/cassandra/tree/2.2.14-tentative > > unit tests: 0

Re: [VOTE] Release Apache Cassandra 2.2.14

Hi, +1 Upgrade tests: https://circleci.com/gh/aweisberg/cassandra/2587 Known issue https://issues.apache.org/jira/browse/CASSANDRA-14155 which is not a blocker There is a test failure on a thrift connection not being open. Might be test bug. If it's a product bug it's probably not that seriou

Re: [VOTE] Release Apache Cassandra 3.0.18

Hi, +1 Upgrade test look OK. There are failures I also found against 2.2 plus some other test bugs. Nothing that looks like a product bug. https://circleci.com/gh/aweisberg/cassandra/2589 Ariel On Wed, Feb 6, 2019, at 5:02 AM, Marcus Eriksson wrote: > +1 > > Den ons 6 feb. 2019 kl 10:53 skrev

Re: [VOTE] Release Apache Cassandra 3.11.4

Hi, -0 bootstrap_upgrade_test.py test_simple_bootstrap_mixed_versions fails because it doesn't see the expected on disk size within 30% of the expected value. It's bootstrapping a new version node and runs cleanup on the existing node. If the data were evenly distributed the on disk size shoul

Re: [VOTE] Release Apache Cassandra 3.11.4

Hi, It fails consistently. I don't know why the data is not evenly distributed. Can someone volunteer to debug this failing test to make sure there isn't an issue with bootstrap in 3.11? https://circleci.com/gh/aweisberg/cassandra/2593 Thanks, Ariel On Wed, Feb 6, 2019, at 3:11

Re: [VOTE] Release Apache Cassandra 3.11.4

73-L174> > > Let me know if this looks good to you, I will send a patch to > cassandra-dtest > > > > Thanks, > Vinay Chella > > > On Wed, Feb 6, 2019 at 8:07 PM Vinay Chella wrote: > > > Hi Ariel, > > > > Sure, I am volunteering to de

Re: cqlsh tests and Python 3

Hi, Do you mean Python 2/3 compatibility? This has been discussed earlier and I think that being compatible with both is an easier sell. Ariel > On Feb 11, 2019, at 1:24 PM, dinesh.jo...@yahoo.com.INVALID > wrote: > > Hey all, > We've gotten the cqlsh tests running in the Cassandra repo (t

Re: CASSANDRA-14482

Hi, I am +1 since it's an additional compressor and not the default. Ariel On Fri, Feb 15, 2019, at 11:41 AM, Dinesh Joshi wrote: > Hey folks, > > Just wanted to get a pulse on whether we can proceed with ZStd support. > The consensus on the ticket was that it’s a very valuable addition > wit

Re: March 2015 QA retrospective

ionality better before release. CASSANDRA-8668 <https://issues.apache.org/jira/browse/CASSANDRA-8668> Benedict We don't enforce offheap memory constraints; regression introduced by 7882 Memory constraints was a supported feature/UI, but not completely tested before release. Could t

Re: March 2015 QA retrospective

test. CASSANDRA-8677 <https://issues.apache.org/jira/browse/CASSANDRA-8677> Ariel Weisberg rpc_interface and listen_interface generate NPE on startup when specified interface doesn't exist Missing unit tests checking error messages for DatabaseDescriptor CASSANDRA-8577 <https://issues.apache.o

Re: March 2015 QA retrospective

Hi Benedict, This only requires unit testing or dtests to be run this way. However for > the kitchen sink tests this is just another dimension in the configuration > state space, which IMO should be addressed as a whole methodically. Perhaps > we should file a central JIRA, or the Google doc you s

Re: Cassandra fixVersion JIRA change

Hi, How are we going to communicate this convention to people that are being onboarded to Cassandra development? Ariel On Wed, Apr 29, 2015 at 12:56 PM, Jake Luciani wrote: > Hi, > > > Currently in JIRA we mark an issue with a specific fixVersion upfront. > When doing releases this causes issu

May 2015 Retrospective

Hi, It's time. This month were are going to try and do the retrospective in a Google doc . Inside the docs I am guessing we will do a threaded conversation and sign off contributions in the discussion

Re: May 2015 Retrospective

r just you. When something doesn't work for you it's not working for any of us. Ariel On Mon, May 4, 2015 at 11:40 AM, Ariel Weisberg wrote: > Hi, > > It's time. This month were are going to try and do the retrospective in a > Google > d

Re: Staging Branches

Hi, I don't think this is necessary. If you merge with trunk, test, and someone gets in a head of you just merge up and push to trunk anyways. Most of the time the changes the other person made will be unrelated and they will compose fine. If you actually conflict then yeah you test again but this

Re: Staging Branches

uit, including duration tests. > > That said, perhaps it’s too much change at once. We still have missing > pieces of infrastructure, and TE is busy with what’s already back-logged. > So let’s revisit this proposal in a few months, closer to 3.1 or 3.2, maybe? > > -- > AY > >

Re: Staging Branches

me we agreed to the > position Aleksey is taking, and he is not blindly following some other > process that is not ours. > > On Thu, May 7, 2015 at 3:25 PM, Ariel Weisberg < > ariel.weisb...@datastax.com> > wrote: > > > Hi, > > > > Whoah. Our process is our

Re: Staging Branches

Hi, If it were automated I would have no problem with it. That would be less work for me because the problems detected would occur anyways and have to be dealt with by me. I just don't want to deal with extra steps and latency manually. So who and when is going to implement the automation? Ariel

Re: Staging Branches

to implement the automation? > > > I don't believe we have sufficient consensus that this is necessary to > start doling out action-items for implementation. > > On Thu, May 7, 2015 at 10:16 AM, Ariel Weisberg < > ariel.weisb...@datastax.com > > wrote: > > >

Re: Staging Branches

> > (this is before 8099, which is going to make a *world* of hurt, and > > will > > > > stick around for a year). It is *very* easy to break things, with > even > > > the > > > > utmost care. > > > > > > > > > While I a

Re: May 2015 Retrospective

the doc just had a links to bugs we feel should be tested for by the kitchen sink harness. Regards, Ariel On Mon, May 4, 2015 at 11:50 AM, Ariel Weisberg wrote: > Hi, > > Someone asked if they can add their own to went well/poorly/changes and > the answer is yes. We'll iterate

May 2015 retrospective

Hi, Astute observers will note that last month's retrospective email was also for May. The Google doc was labelled April. The bug is with the subject (should have been April) so this is retrospective for the events of May 2015. The retrospective doc is available here.

Re: May 2015 retrospective

/document/d/1TMdJ7-y-hKQwhPRFYL0VXf0R53MsF4QmhZmwbT8wpE0/edit#> where I am listing regressions we would like to have caught via performance tests. Regards, Ariel On Tue, Jun 2, 2015 at 4:53 PM, Ariel Weisberg wrote: > Hi, > > Astute observers will note that last month's retrospe

June 2015 retrospective

Hi all, June 2015 retrospective doc It's time for the June retrospective. It looks like there were 3 releases in June (2.0.16, 2.1.6, 2.1.7). There are 90 issues listed across those three releases. Hopefully

Re: Discussion: reviewing larger tickets

Hi, I really like github’s workflow. If you don’t abuse it you get a history of the entire review process. Right now some people have a workflow that involves force pushing and deleting branches. If you delete branches I think the pull requests are still valid so people can still do it (althou

Re: Discussion: reviewing larger tickets

Hi, If you navigate in an IDE how do you know if you are commenting on code that has changed or not? My workflow is usually to look at the diff and have it open in an IDE separately, but maybe I am failing hard at tools. Ariel > On Jul 8, 2015, at 4:00 PM, Josh McKenzie wrote: > > The abilit

End June retrospective, begin July retrospective

Hi all, Thanks for the participation in the June retrospective. I linked in a few issues that people brought up, but didn't push into the CVH doc. Some of you did your own filing which is great. The July 2015 retrospective doc

Proposal, add Epic to the set of issue types available in ASF Jira for Cassandra

Hi all, I am playing with using an Agile board to track what goes into each Cassandra release. What slips from release to release, as well as what is added after the initial set of tasks for a release is started. You can see the SCRUM agile board I created here

Re: Proposal, add Epic to the set of issue types available in ASF Jira for Cassandra

core to the release (Materialized Views, 8099), bugs or failing tests. Regards, Ariel On Wed, Aug 5, 2015 at 11:43 AM, Gary Dusbabek wrote: > Who would have the burden of assigning and managing epics? > > Thanks, > > Gary. > > > > On Tue, Aug 4, 2015 at 3:08 PM

Re: Proposal, add Epic to the set of issue types available in ASF Jira for Cassandra

x27;t support it? > > On Wed, Aug 5, 2015 at 12:42 PM, Ariel Weisberg > > wrote: > > > Hi, > > > > At this stage I wasn't going to propose a process change. My goal is to > > observe and report mall cop style so I can present what happens the way we

Re: Should we make everything blue in Jenkins?

Hi, Thanks for bring this up Michael. I want to elaborate on the impetus for this (or at least my take on it). When 8099 merged we had a thing that must never happen for our process to work. We introduced a large enough number of test failures that it was difficult to tell if you introduced a

End June retrospective, July retrospective will start @ C* summit

Hi all, I am closing out July retrospective now. The retrospective doc has a single author (me) which kind of says that doing this asynchronously by email isn't working. At least not as a starting point. I am not super surprised nor am I disappointed. Trying and failing is part of eventually tryi

Re: End June retrospective, July retrospective will start @ C* summit

Hi, I a mistake in the original email. This is actually the end of the July retrospective. The August retrospective will start @ C* summit. Regards, Ariel On Tue, Sep 8, 2015 at 2:36 PM, Ariel Weisberg wrote: > Hi all, > > I am closing out July retrospective now. The retrospective

Re: cassandra-3.1 branch and new merge order

Hi, What I had thought we were going to do was branch for a feature release every two months and then backport fixes to the last feature release (or prior ones) as desired. So in terms of extra merge effort you only have to backport fixes, and if we solved the release quality issues this is somet

Re: Use of posix_fadvise

Hi, With compaction there can be hot and cold data mixed together. So we want to drop the data and then warm it via early opening so only the hot data is in the cache. Some of those cases are for the old sstable that have been rewritten or discarded so the data is entirely defunct. The files migh

Re: Use of posix_fadvise

8, 2016, at 12:05 PM, Michael Kjellman wrote: > Within a single SegmentedFile? > > On Oct 18, 2016, at 9:02 AM, Ariel Weisberg > mailto:ariel.weisb...@datastax.com>> wrote: > > With compaction there can be hot and cold data mixed together. >

Re: Rough roadmap for 4.0

Hi, I think one additional issue to add to the pile is CASSANDRA-7544 "Allow storage port to be configurable per node" I think no matter what we land on implementation wise it will only possible to make this change in a major release as it will means change to the system schema as well as interno

Re: 3.10 release status: blocked on dtest

Hi, When we say all tests passing it does seem like we are including the upgrade tests, but there are some failures that don't seem to have tickets blocking the release. It seems like we are also excluding any tests decorated as resource intensive? There is also large_dtest, novnode_dtest, and off

Re: Per blockng release on dtest

Hi, At least some of those failures are real. I don't think we should release 3.10 until the real failures are addressed. As I said earlier one of them is a wrong answer bug that is not going to be fixed in 3.10. Can we just ignore failures because we think they don't mean anything? Who is going

Re: Wrapping up tick-tock

Hi, With yearly releases trunk is going to be a mess when it comes time to cut a release. Cutting releases is when people start caring whether all the things in the release are in a finished state. It's when the state of CI finally becomes relevant. If we wait a year we are going to accumulate a

  1   2   >