I just created a dedicated repository and pushed the code there
Since there was no outrage over the name, I opted to save myself some painful
renaming work and keep the cassandra-diff name.
https://gitbox.apache.org/repos/asf?p=cassandra-diff.git
https://github.com/apache/cassandra-diff
Pull
> - Yifan
>
> - Yifan
>
>
> From: Dinesh Joshi
> Sent: Thursday, August 22, 2019 11:42 AM
> To: dev
> Subject: Re: Contributing cassandra-diff
>
> +1 on a discrete repo.
>
> Dinesh
>
> > On Aug 22, 2019, at 9:14 AM, Mich
To: dev
Subject: Re: Contributing cassandra-diff
+1 on a discrete repo.
Dinesh
> On Aug 22, 2019, at 9:14 AM, Michael Shuler wrote:
>
> CI git polling for changes on a separate repository (if/when CI is needed) is
> probably a better way to go. I don't believe there are any issue
uld be handled in a single repo, but with different repos we'd
>>> get natural boundaries.
>>>
>>> -----Original Message-----
>>> From: Sumanth Pasupuleti
>>> Sent: den 22 augusti 2019 14:40
>>> To: dev@cassandra.apache.org
>>> Subject: R
;
> >> -Original Message-----
> >> From: Sumanth Pasupuleti
> >> Sent: den 22 augusti 2019 14:40
> >> To: dev@cassandra.apache.org
> >> Subject: Re: Contributing cassandra-diff
> >>
> >> No hard preference on the repo, but just excited about
life cycles and tool chains. Yes, that could
be handled in a single repo, but with different repos we'd get natural
boundaries.
-Original Message-
From: Sumanth Pasupuleti
Sent: den 22 augusti 2019 14:40
To: dev@cassandra.apache.org
Subject: Re: Contributing cassandra-diff
No hard
ycles and tool chains.
> Yes, that could be handled in a single repo, but with different repos we'd
> get natural boundaries.
>
> -Original Message-
> From: Sumanth Pasupuleti
> Sent: den 22 augusti 2019 14:40
> To: dev@cassandra.apache.org
> Subject: Re: Contri
No hard preference on the repo, but just excited about this tool! Looking
forward to employing this for upgrade testing (very timely :))
On Thu, Aug 22, 2019 at 3:38 AM Sam Tunnicliffe wrote:
> My own weak preference would be for a dedicated repo in the first
> instance. If/when additional
My own weak preference would be for a dedicated repo in the first instance.
If/when additional tools are contributed we should look at co-locating common
stuff, but rushing toward a monorepo would be a mistake IMO.
> On 22 Aug 2019, at 11:10, Jeff Jirsa wrote:
>
> I weakly prefer contrib.
>
I weakly prefer contrib.
On Thu, Aug 22, 2019 at 12:09 PM Marcus Eriksson wrote:
> Hi, we are about to open source our tooling for comparing two cassandra
> clusters and want to get some feedback where to push it. I think the
> options are: (name bike-shedding welcome)
>
> 1. create
Great addition! Thanks Marcus.
+1 for cassandra-compare as said by Jeremy.
We can also think about other features like:
- Comparing just the count between 2 tables. In some cases, It will be
enough to say that our copy is OK.
- Making a difference on a set of partition ==> This will avoid
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
This is a great addition to our Cassandra validation framework/tools. I can
see many teams in the community get benefited from tooling like this.
I like the idea of the generic repo (repos/asf/cassandra-contrib.git
or *whatever
the name is*) for tools like this, for the following 2 main reasons.
Hi, we are about to open source our tooling for comparing two cassandra
clusters and want to get some feedback where to push it. I think the options
are: (name bike-shedding welcome)
1. create repos/asf/cassandra-diff.git
2. create a generic repos/asf/cassandra-contrib.git where we can add more
14 matches
Mail list logo
