Re: 3.0 and the Cassandra release process

. best, kjellman On Mar 18, 2015, at 3:02 PM, Ariel Weisberg ariel.weisb...@datastax.com wrote: Hi, Keep in mind it is a bug fix release every month and a feature release every two months. For development that is really a two month cycle

Improving on release quality by iterating on our definition of done

Hi, I wrote a doc https://docs.google.com/document/d/1ptr47UQ56N80jqL_O6AlE67b0STyn_cVp2k5DTv-OMc/edit?usp=sharing expounding on how tightening up our definition of when a ticket is done and merged can be used as a means of improving release quality. This is meant as a starting point for

Re: 3.0 and the Cassandra release process

will have to change with our dev process, for the better. In particular, with one month to commit new features, we don’t have room for committing sloppy work and stabilizing it later. Trunk has to be stable at all times. I asked Ariel Weisberg to put together his thoughts

Re: 3.0 and the Cassandra release process

has to be stable at all times. I asked Ariel Weisberg to put together his thoughts separately on what worked for his team at VoltDB, and how we can apply that to Cassandra -- see his email from Friday http://bit.ly/1MHaOKX. (TLDR: Redefine “done” to include automated tests. Infrastructure

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 j...@apache.org wrote: Hi, Currently in JIRA we mark an issue with a specific fixVersion upfront. When doing releases this

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: Hi, If it were automated I would have no problem

Re: Staging Branches

. On Thu, May 7, 2015 at 3:25 PM, Ariel Weisberg ariel.weisb...@datastax.com wrote: Hi, Whoah. Our process is our own. We don't have to subscribe to any cargo cult book buying seminar giving process. And whatever we do we can iterate and change until it works for us and solves

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?

Re: May 2015 Retrospective

feel should be tested for by the kitchen sink harness. Regards, Ariel On Mon, May 4, 2015 at 11:50 AM, Ariel Weisberg ariel.weisb...@datastax.com wrote: Hi, Someone asked if they can add their own to went well/poorly/changes and the answer is yes. We'll iterate on what goes up, but anyone can

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

Re: March 2015 QA retrospective

Hi Sam, CASSANDRA-8280 https://issues.apache.org/jira/browse/CASSANDRA-8280 Cassandra crashing on inserting data over 64K into indexed strings Added tests are good example, could focusing on testing all access paths and boundary conditions per access path have prevented Can you create a ticket

Re: March 2015 QA retrospective

Hi, OK, can you file and link a ticket to CASSANDRA-9012 that we should test the commands that nodetool supports? Thanks, Ariel On Fri, Apr 10, 2015 at 2:09 PM, Carl Yeksigian c...@yeksigian.com wrote: CASSANDRA-8028 https://issues.apache.org/jira/browse/CASSANDRA-8028 Carl Yeksigian

Re: March 2015 QA retrospective

far enough. Ariel On Fri, Apr 10, 2015 at 3:00 PM, Tyler Hobbs ty...@datastax.com wrote: On Fri, Apr 10, 2015 at 10:56 AM, Ariel Weisberg ariel.weisb...@datastax.com wrote: *CASSANDRA-7910- wildcard prepared statements are incorrect after a column is added to the table* I

Re: March 2015 QA retrospective

or a blackbox test? CASSANDRA-8675 https://issues.apache.org/jira/browse/CASSANDRA-8675 *Unassigned* COPY TO/FROM broken for newline characters COPY TO/FROM not tested with representative data CASSANDRA-8677 https://issues.apache.org/jira/browse/CASSANDRA-8677 Ariel Weisberg rpc_interface

Re: March 2015 QA retrospective

/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.org/jira/browse/CASSANDRA-8577 Artem Aliev Values of set

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.

June 2015 retrospective

Hi all, June 2015 retrospective doc https://docs.google.com/document/d/1HOW8tSPkizm2uUidwKxF1n7Lg2hmE6H2Goob1fOI9Xw/edit# 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: 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

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

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

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

, 2015 at 12:42 PM, Ariel Weisberg ariel.weisb...@datastax.com 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 currently operate. Right now Epics are just a way for me to bucket

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

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

Re: Use of posix_fadvise

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

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

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: Per blockng release on dtest

without the burden of an ever-later slipped release hanging > over our heads. There's plenty of bugfixes in the 3.X line; the more time > people can have to kick the tires on that code, the more things we can > find > and the better future releases will be. > > >

Re: Per blockng release on dtest

Hi, The upgrade tests are tricky because they upgrade from an existing release to a current release. The bug is in 3.9 and won't be fixed until 3.11 because the test checks out and builds 3.9 right now. 3.10 doesn't include the commit that fixes the issue so it will fail after 3.10 is released

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

Re: Proposal: push TravisCI and CircleCI yaml files into the active branches

Hi, I think we should support something that we can scale out and that can produce consistent reproducible results. One of the longer term issues is going to be different CI systems producing different sets of failures. It's not going to happen often but it will and it's one way flakiness will

Re: [DISCUSS] Implementing code quality principles, and rules (was: Code quality, principles and rules)

Hi, Code coverage: I value code coverage as part of the review and development process. As a project wide target I think it's not as high value, but having a standard encourages people to take the time to use the tools and that's a healthy side effect. Code coverage is a measure of code

Re: committing performance patches without performance numbers

st, Set and Map serialization. Would it really > have been that crazy to run a handful of benchmarks locally and post > those > results? > > On Thu, Mar 9, 2017 at 12:26 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > > > Hi, > > > > I think there

Re: Testing and jira tickets

Hi, Before this change I had already been queuing the jobs myself as a reviewer. It also happens to be that many reviewers are committers. I wouldn't ask contributors to run the dtests/utests for any purpose other then so that they know the submission is done. Even if they did and they pass it

Re: committing performance patches without performance numbers

Hi, I think there are issues around the availability of hardware sufficient to demonstrate the performance concerns under test. It's an open source project without centralized infrastructure. A lot of performance contributions come from people running C* in production. They are already running

Re: committing performance patches without performance numbers

Hi, I should clarify. Should in the sense of it was fine for the process we had at the time (ugh!) but it's not what we should do in the future. Ariel On Thu, Mar 9, 2017, at 04:55 PM, Ariel Weisberg wrote: > Hi, > > I agree that patch could have used it and it was amenable t

Soliciting volunteers for flaky dtests on trunk

Hi all, The unit tests are looking pretty reliable right now. There is a long tail of infrequently failing tests but it's not bad and almost all builds succeed in the current build environment. In CircleCI it seems like unit tests might be a little less reliable, but still usable. The dtests on

Re: Soliciting volunteers for flaky dtests on trunk

d on https://issues.apache.org/jira/browse/CASSANDRA-13182. > > > > On 11 May 2017 at 05:59, Blake Eggleston <beggles...@apple.com> wrote: > > > > > I've taken CASSANDRA-13194, CASSANDRA-13506, CASSANDRA-13515, > > > and CASSANDRA-13372 to start >

Re: Soliciting volunteers for flaky dtests on trunk

: cqlsh_tests.CqlshSmokeTest.[test_insert | test_truncate | test_use_keyspace | test_create_keyspace] JIRA: No JIRA yet Last failed: 4/22/2017 count: 6 If you have spare cycles you can make a huge difference in test stability by picking off one of these. Regards, Ariel On Wed, May 10, 2017, at 12:45 PM, Ariel Weisberg

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

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

we support - which is 2.1 and higher. > > > > Also, is this worth stopping the current open vote for this patch? (Not in > > a place to look at the patch and affects to impacted branches right now). > > > > Jason > > > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisbe

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

Hi, Option 4, upgrade trunk, update NEWS.TXT in prior versions warning about the vulnerability. Ariel On Tue, Feb 13, 2018, at 12:28 PM, Ariel Weisberg wrote: > Hi, > > So our options are: > > 1. Ignore it. > Most people aren't using this functionality. > Most people

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

going to break some apps according to Michael Shuler. Happened when he tried it. Certainly we can upgrade in trunk? While we are at it come up to the latest version. Ariel On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote: > Hi, > > I don't think the fix is in 1.1.11 looking at

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

Hi, Seems like users could conceivably be using the vulnerable component. Also seems like like we need potentially need to do this as far back as 2.1? Anyone else have an opinion before I commit this? What version to start from? Ariel On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote: >

Cassandra 7544 configurable storage port and you

Hi, I want to bring up some important changes to how addresses should be handled in Cassandra after 7544. As of 7544 a Cassandra instance (sometimes referred to as a node in the code) can't be identified by an InetAddress. It can't be identified for the purposes of the internal storage

Re: Release votes

Hi, I created https://issues.apache.org/jira/browse/CASSANDRA-14241 for this issue. You are right there is a solid chunk of failing tests on Apache infrastructure that don't fail on CircleCI. I'll find someone to get it done. I think that fix before commit is only going to happen if we go all

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

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

Re: upgrade guava on trunk before 9/1?

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 > > > > > On Wed, Aug

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

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

Re: Transient Replication 4.0 status update

? 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 at 12:29 PM Ar

Re: Transient Replication 4.0 status update

ith 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 all, > > > > I

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.

Re: Making RF4 useful aka primary and secondary ranges

Hi, There is a JIRA for decoupling the size of the group size used for consensus with level of data redundancy. https://issues.apache.org/jira/browse/CASSANDRA-13442 It's been discussed quite a bit offline and I did a presentation on it at NGCC. Hopefully we will see some movement on it soon.

Re: Roadmap for 4.0

Hi, +1 to having a feature freeze date. June 1st is earlier than I would have picked. Ariel On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote: > +1 here for June 1. > > On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown wrote: > > > +1 > > > > On Wed, Apr 4, 2018 at 8:31

Re: Roadmap for 4.0

Hi, What is the role of minor releases in Cassandra? I know that we have guarantees we make about minor releases that we don't make about major releases (is this summarized anywhere?), but is there anyone who actually thinks those guarantees are worth it vs having major releases on a shorter

Re: Roadmap for 4.0

Hi, +1 to September 1st. I know I will have much better availability then. Ariel On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote: > +1 with Sept 1st as I am seeing willingness for people to test it after it > > > On Apr 12, 2018, at 13:59, Ben Bromhead wrote: > > >

Re: Evolving the client protocol

Hi, I think that updating the protocol spec to Cassandra puts the onus on the party changing the protocol specification to have an implementation of the spec in Cassandra as well as the Java and Python driver (those are both used in the Cassandra repo). Until it's implemented in Cassandra we

Re: Evolving the client protocol

changes, but if no one commits to doing the work you might find we release the next protocol version without the tentative spec changes. Ariel On Thu, Apr 19, 2018, at 12:53 PM, Avi Kivity wrote: > > > On 2018-04-19 19:10, Ariel Weisberg wrote: > > Hi, > > > >

Re: Evolving the client protocol

t; This would give you a path forward at least for the short term. > > > > > > On Thu, Apr 19, 2018 at 12:10 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > > > >> Hi, > >> > >> I think that updating the protocol spec to Cassandra puts the onu

Re: Evolving the client protocol

pport might be to 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: question on running cassandra-dtests

Hi, Great! Glad you were able to get up and running. The dtests can be tricky if you aren't already somewhat familiar with Python. Ariel On Mon, Mar 26, 2018, at 9:10 PM, Murukesh Mohanan wrote: > On Tue, Mar 27, 2018 at 6:47 Ariel Weisberg <ar...@weisberg.ws> wrote: > > > H

Re: question on running cassandra-dtests

efaultThreadFactory.java:138) [netty- > all-4.1.14.Final.jar:4.1.14.Final] > at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151], ERROR > [MessagingService-NettyOutbound-Thread-4-7] 2018-03-28 00:24:37,063 > OutboundHandshakeHandler.java:209 - Failed to properly handshake with > peer 127.0.0.3

Re: question on running cassandra-dtests

Hi, Your environment is python 2.7 when it should be python 3. See: > File "/usr/local/lib/python2.7/dist-packages/_pytest/assertion/ > rewrite.py", line 213, in load_module Are you using virtualenv to create a python 3 environment to use with the tests? >From README.md: **Note**: While

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

Hi, +1 to what Jordan is saying. It seems like if we are cutting a release off of trunk we want to make sure we get N years of supported JDK out of it. For a single LTS release N could be at most 3 and historically that isn't long enough and it's very likely we will get < 3 after a release is

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

t; 08:42:43 CI ? It just let's your test matrix explode - a litte ;) > > 08:46:48 Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8 > > (latest)'` in job DSL and could easily modify that > > > > On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali <k...@peernova.com> wrote: >

Re: Debug logging enabled by default since 2.2

Hi, In a way the real issue might be that we don’t have nightly performance runs that would make an accidentally introduced debug statement obvious. A log statement that runs once or more per read or write should be easy to spot. I haven’t measured the impact though. And as a bonus by having

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

Hi, I'm not clear on what building and bundling our own JRE/JDK accomplishes? What is our source for JRE updates going to be? Are we going to build our own and does Oracle release the source for their LTS releases? Are we going to extract LTS updates from CentOS? If the goal of bundling is to

Re: Debug logging enabled by default since 2.2

Hi, Signal to noise ratio matters for logs. Things that we log at DEBUG aren't at all bound by constraints of human readability or being particularly relevant most of the time. I don't want to see most of this stuff unless I have already not found what I am looking for at INFO and above. Can

Re: Debug logging enabled by default since 2.2

log. > > I guess in that configuration, some/most TRACE level loggings would then be > eligible to graduate to DEBUG...? > > > > > On Tue, Mar 20, 2018 at 4:19 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > > > Hi, > > > > Signal to nois

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

Re: Implicit Casts for Arithmetic Operators

> 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 fairly unexpected for the user

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

Re: CASSANDRA-13241 lower default chunk_length_in_kb

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

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

Re: CASSANDRA-13241 lower default chunk_length_in_kb

as well, > > > > C*heers, > > --- > > Alain Rodriguez - al...@thelastpickle.com > > France / Spain > > > > The Last Pickle - Apache Cassandra Consulting > > http://www.thelastpickle.com > > > > Le sam. 13 oct. 201

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

Re: CASSANDRA-13241 lower default chunk_length_in_kb

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 Haddad

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

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

Re: Implicit Casts for Arithmetic Operators

ssify. > > > > 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 other concern. > > > > It seems to me the p

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: 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: JIRA Workflow Proposals

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 > > you can't modify any of

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

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

Re: Revisit the proposal to use github PR

l, 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 people invitably

Re: JIRA Workflow Proposals

t; > 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 unassailable conse

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,

Re: JIRA Workflow Proposals

ng 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 Dec 2018, at 17:

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

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

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

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

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 PM, Ariel

  1   2   >