[
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
