Thanks,
I will follow that path then,
pon., 10 lip 2023 o 19:03 Jon Meredith napisał(a):
> +1 from me too. I would support removing all of the optional checks from
> jar/test as I also hit issues with rat from time to time while iterating,
> as long as the CI system runs them and makes it ver
Add a 'devBranch' jenkins job to that imo: The possibility to run the
full suite + multiplex new tests before commit when you're about to
release a Kraken into the codebase: Accord, TCM, TTL, SAI, Vector,
JDK... So:
1: Pre-commit subset of tests (suites + matrices + env) runs. On green,
merge
Can someone explain to me how the Bloom filter table in
BloomFilterCalculations was derived and how it is supposed to work? As I
read the table it seems to indicate that with 14 hashes and 20 bits you get
a fp of 6.71e-05. But if you plug those numbers into the Bloom filter
calculator [1], that
For quite a few years, I have done Twitter polls to gather helpful
information about how people use Apache Cassandra. Twitter is no longer the
best place to conduct this kind of activity since it has become a ghost
town.
We should ask more comprehensive questions to get the pulse of our user
commu
I would say it helps a lot of people. 45k downloads in just last month:
https://pypistats.org/packages/cqlsh
I feel like a CEP would be in order, along the lines of CEP-8:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
Unless anyone objects, I can help yo
Same - really appreciate those efforts and also welcome the upstreaming and
release automation...
German
From: Jeff Widman
Sent: Sunday, July 9, 2023 1:44 PM
To: Max C.
Cc: dev@cassandra.apache.org ; Brad Schoening
Subject: [EXTERNAL] Re: CASSANDRA-18654 - sta
We use Nodetool in scripts sparsely, in my opinion trying to programmatically
parse the human readable output should be avoided as much as possible, it’s
usually leads to implementations that are brittle.
I certainly agree you don’t want to make these kinds of changes in 3.11 or 4.x
(and I don’
OK, thanks all, we will go with 2), we will deprecate it in 5.0 and we remove
it the next major.
From: Jeff Jirsa
Sent: Monday, July 10, 2023 18:13
To: dev@cassandra.apache.org
Subject: Re: Removal of CloudstackSnitch
NetApp Security WARNING: This is an
On Sun, Jul 9, 2023 at 9:10 PM Dinesh Joshi wrote:
> On Jul 8, 2023, at 8:43 AM, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
>
>
> If we are providing CQL / JSON / YAML for couple years, I do not believe
> that the argument "lets not break it for folks in nodetool" is still
> re
On Fri, Jul 7, 2023 at 10:20 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> Hi list,
>
> I want to clarify the policy we have when we want to / going to change the
> output of the tooling (nodetool or tools/bin etc.).
>
> I am not sure it is written somewhere explicitly, but how I
+1 from me too. I would support removing all of the optional checks from
jar/test as I also hit issues with rat from time to time while iterating,
as long as the CI system runs them and makes it very clear for any
committer there are failures.
On Mon, Jul 10, 2023 at 9:40 AM Josh McKenzie wrote:
+1
On Mon, Jul 10, 2023 at 8:42 AM Josh McKenzie wrote:
> 2) keep it there in 5.0 but mark it @Deprecated
>
> I'd say Deprecate, log warnings that it's not supported nor maintained and
> people to use it at their own risk, and that it's going to be removed.
>
> That is, assuming the maintenance
Hey Brad,
Thanks for raising the topic. I wanted to mention we are now on a very old
version of commons-cli (1.1 from 2007). So I would suggest we first update
it.
While there is activity in the commons-cli github repo (a lot of dependency
updates as far as I can tell from a quick look), the last
The Apache Commons CLI library provides an API for parsing command line
options with the package org.apache.commons.cli and this is already used by
a dozen of existing Cassandra utilities including:
SSTableMetadataViewer, StandaloneScrubber, StandaloneSplitter,
SSTableExport, BulkLoader, and other
> 2) keep it there in 5.0 but mark it @Deprecated
I'd say Deprecate, log warnings that it's not supported nor maintained and
people to use it at their own risk, and that it's going to be removed.
That is, assuming the maintenance burden of it isn't high. I assume not since,
as Brandon said, they
> • Remove the checkstyle dependency from "jar" and "test"
> • Create a single "check" target that includes all the checks we expect to
> pass in the CI (currently Checkstyle, RAT, and Eclipse-Warnings), making this
> task the default.
+1 here.
(of note: haven't forgotten the request from this
I'm personally not thinking about CircleCI at all; I'm envisioning a world
where all of us have 1 CI *software* system (i.e. reproducible on any env) that
we use for pre-commit validation, and then post-commit happens on reference ASF
hardware.
So:
1: Pre-commit subset of tests (suites + matric
I agree with Ekaterina, but also want to point out that snitches are
pluggable, so whatever we do should be pretty safe. If someone
discovers after the removal that they need it, they can just plug it
back in.
Kind Regards,
Brandon
On Mon, Jul 10, 2023 at 8:54 AM Ekaterina Dimitrova
wrote:
>
>
Hey,
should we still keep it around if we are not even sure it still works? As I see
it, we are not able to verify it works on 5.0 release. What value there is in a
snitch we do not know is still functioning?
Regards
From: Ekaterina Dimitrova
Sent: Mon
Hi Stefan,
I think we should follow our deprecation rules and deprecate it in 5.0,
potentially remove in 6.0. (Deprecate in one major, remove in the next
major)
Maybe the deprecation can come with a note on your findings for the users,
just in case someone somewhere uses it and did not follow the
Hi list,
I want to ask about the future of CloudstackSnitch.
This snitch was added 9 years ago (1). I contacted the original author of that
snitch, Pierre-Yves Ritschard, who is currently CEO of a company he coded that
snitch for.
In a nutshell, Pierre answered that he does not think this snit
On Mon, Jul 10, 2023 at 6:07 AM Jacek Lewandowski
wrote:
> Remove the checkstyle dependency from "jar" and "test"
> Create a single "check" target that includes all the checks we expect to pass
> in the CI (currently Checkstyle, RAT, and Eclipse-Warnings), making this task
> the default.
I supp
Maxim, I don't think it would work, especially this command:
"ant test -Dno-build=true"
would execute the whole pipeline up to the "test" target, skipping only the
"build" target. However, none of its dependencies would be missed. In Ant,
when a target is skipped due to some property, skipping
Given what was said, I propose rephrasing this functionality to limit the
memory used to execute a query. We will not expose the page size measured
in bytes to the client. Instead, an upper limit will be a guardrail so that
we won't fetch more data.
Aggregation query with grouping is a special cas
24 matches
Mail list logo
