[ https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624340#comment-17624340 ]
Andres de la Peña commented on CASSANDRA-17240: ----------------------------------------------- {quote}I realise there might be no desire to adopt Harry by either you personally or by members of your team {quote} I have never said that. I'd like to use Harry, but that and marking any new features as experimental just because they haven't been tested with Harry are different things. As for members of my team, here we are all individuals forming the Cassandra community. We all try to achieve the same goal. I don't think that attributing desires with expressions such as "you personally or members of your team" helps us in anything but creating conflict. {quote}I think with 4.0 release, we've been able to prove that fuzz testing is the only way to build confidence, since smaller and targeted use-cases often exercise only a fraction of our code. {quote} {quote}I'm using it for my development all the time, and it is proving itself useful every day. {quote} Are those tests publicly available? CASSANDRA-16262 was meant to add fuzz testing for coordination and replication. We had it as a blocker for 4.0 for some time, but we finally released without it. That ticket was closed in February but we never got any new tests. Instead, the ticket added some tooling to use Harry with JVM dtests. Specifically, it added a new {{FuzzTestBase}} class that I understand should be extended by dtests using Harry. However, eight months have passed and I can't find a single class extending that {{{}FuzzTestBase{}}}. So far it seems dead code that we still have to maintain. For example, this very same patch has to make some (trivial) changes on {{{}SSTableGenerator{}}}. Is there some test extending {{FuzzTestBase}} ? Maybe I'm missing some public, community-owned repo containing a gazillion tests using Harry. But if we don't have that, nor a single class extending {{{}FuzzTestBase{}}}, I'm inclined to think that Harry-based testing is itself experimental. Hence my reluctance to making it mandatory or blocking things on it. {quote}I would not go as far as "forcing" anyone to use Harry. {quote} Marking any new features as experimental until they are tested with Harry is mostly equivalent to force people to use it, isn't it? {quote}Similarly, we do have a strong preference (even though not a general rule) for in-jvm dtests over python dtests. {quote} In-JVM dtests are a good example of how to introduce a new testing tool. They have never been mandatory, but they have made their way on their own merits and people have gradually adopted them. The suite hasn't stopped growing since its introduction, and no enforcing policy has been needed. Those wanting to use them just used it, and that led others by example. I'd suggest the same approach for Harry. > CEP-19: Trie memtable implementation > ------------------------------------ > > Key: CASSANDRA-17240 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17240 > Project: Cassandra > Issue Type: Improvement > Components: Local/Memtable > Reporter: Branimir Lambov > Assignee: Branimir Lambov > Priority: Normal > Fix For: 4.2 > > Attachments: SkipListMemtable-OSS.png, TrieMemtable-OSS.png, > density_SG.html.gz, density_test_with_sharding.html.gz, latency-1_1-95.png, > latency-9_1-95.png, throughput_SG.png, throughput_apache.png > > Time Spent: 13.5h > Remaining Estimate: 0h > > Trie-based memtable implementation as described in CEP-19, built on top of > CASSANDRA-17034 and CASSANDRA-6936. > The implementation is available in this > [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240]. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org