Congrats, Maxim!
On Tue, 9 Jan 2024 at 03:45, guo Maxwell wrote:
> Congratulations, Maxim!
>
> Francisco Guerrero 于2024年1月9日周二 09:00写道：
>
>> Congratulations, Maxim! Well deserved!
>>
>> On 2024/01/08 18:19:04 Josh McKenzie wrote:
>> > The Apache Cassandra PMC is pleased to announce that Maxim
Congrats Mike!
On Fri, 8 Dec 2023 at 14:53, Jeremiah Jordan
wrote:
> Congrats Mike! Thanks for all your work on SAI and Vector index. Well
> deserved!
>
> On Dec 8, 2023 at 8:52:07 AM, Brandon Williams wrote:
>
>> Congratulations Mike!
>>
>> Kind Regards,
>> Brandon
>>
>> On Fri, Dec 8, 2023
Congrats Francisco!
On Wed, 29 Nov 2023 at 11:37, Benjamin Lerer wrote:
> Congratulations!!! Well deserved!
>
> Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi
> a écrit :
>
>> Welcome!
>> On 29/11/23 2:24, guo Maxwell wrote:
>>
>> Congrats!
>>
>> Jacek Lewandowski 于2023年11月29日周三 06:16写道：
>>
I'd add that even if we commit running CI to verify that we are not
introducing new test failures, we can always inadvertently introduce new
flakies. Those flakies can be hit long after the original commit,
for example while trying to make a release.
On Tue, 31 Oct 2023 at 17:08, Paulo Motta
+1
On Wed, 4 Oct 2023 at 05:44, Berenguer Blasi
wrote:
> +1
> On 4/10/23 4:43, Erick Ramirez wrote:
>
> +1
>
>>
I have just created CASSANDRA-18876 for this. I'll post a patch very soon.
On Wed, 20 Sept 2023 at 19:41, David Capwell wrote:
> I don’t think we can readily migrate old types away from this however,
> without breaking backwards compatibility.
>
>
> Given that java driver has a different
+1
On Thu, 7 Sept 2023 at 12:52, Jacek Lewandowski
wrote:
> Mick, is the documentation / website ok?
>
> If so, +1
>
> Best Regards,
> - - -- --- - -
> Jacek Lewandowski
>
>
> czw., 7 wrz 2023 o 12:58 Brandon Williams napisał(a):
>
>> +1
>>
>> Kind Regards,
>> Brandon
`column = term` is definitively problematic because it creates an ambiguity
when the queried column belongs to the primary key. For some queries we
wouldn't know whether the user wants a primary key query using regular
equality or an index query using the analyzer.
`term_matches(column, term)`
I think 500 runs combining all configs could be reasonable, since it's
unlikely to have config-specific flaky tests. As in five configs with 100
repetitions each.
On Fri, 7 Jul 2023 at 16:14, Josh McKenzie wrote:
> Maybe. Kind of depends on how long we write our tests to run doesn't it? :)
>
>
t caps our system tables at some value and
> keeping the guardrail user-scope specific would be a better approach. I see
> your point about leaking internal details to users, specifically on things
> they can't control at this point.
>
> On Wed, Jun 14, 2023, at 8:19 AM, Andrés de la P
ling from local schema, so to keep the same
> behavior we would need to do the same; being version dependent would
> actually break the semantics as far as I can tell.
>
> On Jun 13, 2023, at 9:50 AM, Andrés de la Peña
> wrote:
>
> Indeed "keyspace_count_warn_threshold&q
Indeed "keyspace_count_warn_threshold" and "table_count_warn_threshold"
include system keyspaces and tables. Also, differently to the newer
guardrails, they are enabled by default.
I find that problematic because users need to know how many system
keyspaces/tables there are to know if they need
+1
On Tue, 13 Jun 2023 at 16:40, Yifan Cai wrote:
> +1
> --
> *From:* David Capwell
> *Sent:* Tuesday, June 13, 2023 8:37:10 AM
> *To:* dev
> *Subject:* Re: [VOTE] CEP-8 Datastax Drivers Donation
>
> +1
>
> On Jun 13, 2023, at 7:59 AM, Josh McKenzie wrote:
>
> +1
+1
On Fri, 26 May 2023 at 12:59, Mike Adamson wrote:
> +1 (nb)
>
> On Fri, 26 May 2023 at 12:50, Stefania Alborghetti
> wrote:
>
>> +1
>>
>> On Fri, May 26, 2023 at 7:31 AM Aleksey Yeshchenko
>> wrote:
>>
>>> +1
>>>
>>> On 26 May 2023, at 07:19, Berenguer Blasi
>>> wrote:
>>>
>>> +1
>>> On
+1
On Tue, 16 May 2023 at 07:24, Alex Petrov wrote:
> +1
>
> On Tue, May 16, 2023, at 4:45 AM, Doug Rohrer wrote:
>
> +1 (nb)
>
> Doug Rohrer
>
> > On May 15, 2023, at 7:17 PM, Brandon Williams wrote:
> >
> > +1
> >
> > Kind Regards,
> > Brandon
> >
> >> On Mon, May 15, 2023 at 5:12 PM Dinesh
My vote is:
1. VECTOR
2. DENSE VECTOR
3. type[dimension]
If we ever add sparse vectors, we can assume that DENSE is the default and
allow to use either DENSE, SPARSE or nothing.
Perhaps the dimension could be separated from the type, such as in
VECTOR[dimension] or VECTOR(dimension).
On Fri, 5
A > B > C
I don't think that ML is such a niche application that it can't have its
own CQL data type. Also, vectors are mathematical elements that have more
applications that ML.
On Tue, 2 May 2023 at 19:15, Mick Semb Wever wrote:
>
>
> On Tue, 2 May 2023 at 17:14, Jonathan Ellis wrote:
>
>>
If we are going to use FLOAT[N] as sugar for another CQL data type, maybe
tuples are more convenient than lists. So FLOAT[N] could be equivalent to
TUPLE.
Differently to collections, tuples have a fixed size, they are always
frozen and I think they don't support random access. These properties
Indeed requiring AF for "select * from ks.tb where p1 = 1 and c1 = 2 and
col2 = 1", where p1 and c1 are all the columns in the primary key, sounds
like a bug.
I think the criterion in the code is that we require AF if there is any
column restriction that cannot be processed by the primary key or
I think supporting DATABASE is a great idea.
It's better aligned with SQL databases, and can save new users one of the
first troubles they find.
Probably anyone starting to use Cassandra for the first time is going to
face the what is a keyspace? question in the first minutes. Saving that to
+1
On Tue, 4 Apr 2023 at 15:09, Jeremy Hanna
wrote:
> +1 nb, will be great to have this in the codebase - it will make nearly
> every table's compaction work more efficiently. The only possible
> exception is tables that are well suited for TWCS.
>
> On Apr 4, 2023, at 8:00 AM, Berenguer Blasi
Congratulations Josh! Thanks for everything Mick!
On Thu, 23 Mar 2023 at 11:36, Ekaterina Dimitrova
wrote:
> Congrats Josh! Thanks Mick!
>
> На четвъртък, 23 март 2023 г. Brandon Williams написа:
>
>> Congrats Josh! Thanks Mick!
>>
>> Kind Regards,
>> Brandon
>>
>> On Thu, Mar 23, 2023 at
> https://issues.apache.org/jira/browse/CASSANDRA-17973 ?
>
> Thanks
>
>
> From: Andrés de la Peña
> Sent: Monday, March 13, 2023 13:22
> To: dev@cassandra.apache.org
> Subject: [DISCUSS] Remove deprecated CQL functions dateof and
> unixtime
The CQL functions "dateof" and "unixtimestampof" were deprecated on
Cassandra 2.2.0, almost eight years ago [1]. They were deprecated in favour
of the then new "totimestamp" and "tounixtimestamp" functions.
I think that we can finally remove those functions in 5.0, since they have
been deprecated
>
> Should we clarify that part first by getting an idea of the status of the
> different CEPs and other big pieces of work?
CEP-20 (dynamic data masking) should hopefully be ready by the end of this
month.
It's composed by seven small tickets. Five of those tickets are ready, and
two are under
+1
On Tue, 7 Feb 2023 at 09:52, Jacek Lewandowski
wrote:
> +1
>
> - - -- --- - -
> Jacek Lewandowski
>
>
> wt., 7 lut 2023 o 10:12 Benjamin Lerer napisał(a):
>
>> +1
>>
>> Le mar. 7 févr. 2023 à 06:21, a écrit :
>>
>>> +1 nb
>>>
>>> On Feb 6, 2023, at 9:05 PM, Ariel
memory, thus we do not
>> benefit from the advantages of ordered data (e.g. the ClientsTable and
>> its ClusteringColumn(PORT)).
>>
>> Changing the clustering column to a regular column may simplify the
>> virtual table data model, but I'm afraid it may affect u
Yes, I think that some refactors can also be directly merged if they have a
value for the end user on their own. Changes providing cleaner, better
documented and less tightly coupled code can have that value, even if they
aren't a new feature. Things like new APIs without an implementation
I'm not sure a CEP is necessarily a big, complex piece of work that needs
to be split into multiple tickets. There could be single-ticket CEPs that
don't need multiple tickets, and still need the bureaucracy of a CEP due to
the impact of the change. However that probably isn't the common case.
I think removing the need for ALLOW FILTERING on virtual tables makes sense
and would be quite useful for operators.
That guard exists for performance issues that shouldn't occur on virtual
tables. We also have a flag in case some future virtual table
implementation has limitations regarding
Congratulations, Patrick!
On Thu, 2 Feb 2023 at 19:54, Francisco Guerrero wrote:
> Congrats, Patrick!
>
> On 2023/02/02 19:52:35 Jean-Armel Luce wrote:
> > Congrats, Patrick
> >
> > Le jeu. 2 févr. 2023 à 20:46, David Capwell a
> écrit :
> >
> > > Congrats and welcome! =)
> > >
> > > On Feb 2,
I guess that depends on the type of change, and what we consider an API.
If it's a breaking change, like removing a method or property, I think we
would need a DISCUSS API thread prior to making changes. However, if the
change is an addition, like adding a new yaml property or a JMX method, I
+1 for the same reasons.
On Wed, 11 Jan 2023 at 20:14, David Capwell wrote:
> +1. We already use mockito. Also that library is basically empty, its
> just defining configs for extensions (see
>
+1
On Mon, 19 Dec 2022 at 15:11, Aleksey Yeshchenko wrote:
> +1
>
> On 19 Dec 2022, at 13:42, Ekaterina Dimitrova
> wrote:
>
> +1
>
> On Mon, 19 Dec 2022 at 8:30, J. D. Jordan
> wrote:
>
>> +1 nb
>>
>> > On Dec 19, 2022, at 7:07 AM, Brandon Williams wrote:
>> >
>> > +1
>> >
>> > Kind
+1
On Fri, 9 Dec 2022 at 15:41, Josh McKenzie wrote:
> +1
>
> On Fri, Dec 9, 2022, at 10:28 AM, Marcus Eriksson wrote:
>
> +1
>
> On Wed, Dec 07, 2022 at 10:40:21PM +0100, Mick Semb Wever wrote:
> > Proposing the (second) test build of Cassandra 4.1.0 for release.
> >
> > sha1:
various collection types. So rather than building
> ARRAY_MAX do APPLY(MAX, column)) or APPLY(MAX(column)) it is clear what is
> being requested and APPLY can be the source of truth for which aggregate
> functions work on which column types.
>
> On Fri, Dec 9, 2022 at 10:28 AM A
without it.
>
> On Dec 8, 2022, at 1:57 PM, Andrés de la Peña
> wrote:
>
>
>
>> I expect we’ll rehash it every API thread otherwise.
>
>
> Since you bring up the topic, I understand that opposing to every single
> reviewed decision that has been taken on CASS
I think we should figure out our overall strategy - these are all pieces
> of the puzzle IMO. But I guess the above questions seem to come first and
> will shape this. I would be in favour of some general approach, however,
> such as either first casting to a collection, or pass
These databases only support ARRAY_ functions, seemingly, plus
> special MULTISET operators defined by the SQL standard where that data type
> is supported.
>
>
>
> On 8 Dec 2022, at 12:11, Andrés de la Peña wrote:
>
>
> "ARRAY_MAX" and "ARRAY_MIN" func
values, or by (key, value) pairs), so this is
>> particularly poorly defined IMO.
>>
>> The maximum of a blob type is pretty well defined I think, as are
>> boolean, inetaddress etc. However, even for List or Set collections there’s
>> multiple reasonable functions one
r matching and a keyword for overriding the precedence
> order (e.g. COUNT(collection AS COLLECTION)).
> >>>
> >>> Given (2), (3) is a little more difficult. However, I think this can
> be solved several ways.
> >>> - We could permit explicit casts to collection
This will require some long introduction for context:
The MAX/MIN functions aggregate rows to get the row with min/max column
value according to their comparator. For collections, the comparison is on
the lexicographical order of the collection elements. That's the very same
comparator that is
g added to the database and chime in any areas it feel responsible for,
>>>> as it has been the case and has worked relatively well.
>>>>
>>>> I think it makes sense to look into improving visibility of API
>>>> changes, so people can more easily review a su
+1
On Mon, 5 Dec 2022 at 11:37, Benedict wrote:
> -0
>
> CASSANDRA-18086 should probably be fixed and merged first, as Paxos v2
> will be unlikely to work well for users without it. Either that or we need
> to update NEWS.txt to mention it.
>
> On 5 Dec 2022, at 11:01, Aleksey Yeshchenko
Indeed that contribution policy should be clearer and not be on a page
titled code style, thanks for briging that up.
If we consider all those things APIs, and additions are also considered
changes that require a DISCUSS thread, it turns out that almost any
not-bugfix ticket would require a mail
+1
On Mon, 21 Nov 2022 at 19:55, Josh McKenzie wrote:
> +1
>
> On Mon, Nov 21, 2022, at 12:38 PM, Mick Semb Wever wrote:
>
>
>
> On Fri, 18 Nov 2022 at 13:10, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.1-rc1 for release.
>
> sha1:
+1 to waiver
On Tue, 15 Nov 2022 at 05:54, Berenguer Blasi
wrote:
> +1 to waiver
> On 15/11/22 2:07, Josh McKenzie wrote:
>
> +1 to waiver.
>
> We still don't have some kind of @flaky annotation that sequesters tests
> do we? :)
>
> On Mon, Nov 14, 2022, at 5:58 PM, Ekaterina Dimitrova wrote:
>
too meant snake case and need coffee.
> >>>
> >>>> On Thu, Nov 10, 2022, 7:26 AM Brandon Williams
> wrote:
> >>>
> >>>> +1 on camel case and aliases for compatibility.
> >>>>
> >>>> On Thu, Nov 10, 2022, 6:21 AM
aliases for compatibility.
>
> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña
> wrote:
>
>> It seems we don't have a clear convention on how to name CQL native
>> functions.
>>
>> Most native functions are named all lower case, without underscore nor
>> hy
It seems we don't have a clear convention on how to name CQL native
functions.
Most native functions are named all lower case, without underscore nor
hyphen to separate words. That's the case, for example, of "intasblob" or
"blobasint".
We also have some functions using camel case, as in
Note that the test multiplexer also searches for tests ending with "Test",
so it will also miss new or modified tests with nonstandard names. The
automatically detected tests are listed when running generate.sh, and they
are added to the repeated run jobs. That gives us another opportunity to
>
> - Ticket for: remove -h, have -f and -p (free and paid)
+1 to this, probably there isn't anyone using -h. There are some jobs that
can't pass with the free option. Maybe we should remove them from the
workflow when the free option is used. Perhaps that could save new
contributors some
>
> Yep - instead of having to go to circle and click, when you push your
> branch the circle hook picks it up and kicks off the top level job
> automatically. I tend to be paranoid and push a lot of incremental work
> that's not ready for CI remotely so it's not great for me, but I think
> having
ing job naming, default config
> type, and updating documentation shortly.
>
> On Tue, Oct 18, 2022, at 12:33 PM, Andrés de la Peña wrote:
>
> Just to let you know that CASSANDRA-17939 has just been committed.
>
> It changes the way the CircleCI multiplexer works, in lin
Just to let you know that CASSANDRA-17939 has just been committed.
It changes the way the CircleCI multiplexer works, in line with the recent
changes in our release criteria:
* The default number of repeated tests iterations is 500, except for long
and upgrade tests.
* It is possible to specify
+1
On Tue, 11 Oct 2022 at 11:57, Brandon Williams wrote:
> +1
>
> On Sat, Oct 8, 2022 at 7:30 AM Josh McKenzie wrote:
> >
> > DISCUSS thread:
> https://lists.apache.org/thread/o166v7nr9lxnzdy5511tv40rr9t6zbrw
> >
> > Revise Release Lifecycle cwiki page (
>
to allow specifying a list of
> classes per test target, so we don't have to needlessly suffer with this
>
> This sounds integral to us multiplexing tests on large diffs whether we go
> with circle for releases or not and would be a great addition!
>
> On Tue, Sep 27, 2022, at 6:1
+1
On Fri, 30 Sept 2022 at 09:26, Benjamin Lerer wrote:
> +1
>
> Le ven. 30 sept. 2022 à 08:11, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> a écrit :
>
>> +1
>>
>>
>> From: Mick Semb Wever
>> Sent: Tuesday, September 27, 2022 15:13
>> To: dev
>
> 250 iterations isn't enough; I use 500 as a low water mark.
I agree that 500 iterations would be a reasonable minimum. We have seen
flaky unit tests requiring far more iterations, but that's not very common.
We could use to 500 iterations as default, and discretionary use a higher
limit in
I think that custom, pluggable type of guardrail will be a great addition
to the framework.
The first guardrails prototype included a factory of guardrails that was
able to provide different guardrail instances depending on the specified
class and client state. That was discarded during review in
Vote passes with eight +1s (seven binding) and no vetos.
Thanks everyone.
On Thu, 22 Sept 2022 at 20:50, Josh McKenzie wrote:
> +1
>
> On Thu, Sep 22, 2022, at 4:28 AM, Mick Semb Wever wrote:
>
>
>
> I'd like to propose CEP-20 for approval.
>
> Proposal:
>
Hi everyone,
I'd like to propose CEP-20 for approval.
Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
Discussion: https://lists.apache.org/thread/qsmxsymozymy6dy9tp5xw9gn5fhz9nt4
The vote will be open for 72 hours.
Votes by committers are
, Andrés de la Peña
wrote:
> That's 5 votes for A and 2 votes for B so far. None of these options
> opposes to the CEP, so I think we can probably start the vote, unless we
> want to wait longer for the poll.
>
> On Mon, 12 Sept 2022 at 13:51, Benjamin Lerer wrote:
>
>> A
>
> a écrit :
>
>> A
>>
>> On Sep 7, 2022, at 8:58 AM, Benedict wrote:
>>
>> Well, I am not convinced these changes will materially impact the
>> outcome, but at least we’ll have some extra fun collating the votes.
>>
>>
>> On 7 Sep 2022
nd should implement
> the view approach
> D) We should NOT implement the table schema approach, and should implement
> some other scheme (or not implement this feature)
>
> Where my vote is B
>
> On 7 Sep 2022, at 12:50, Andrés de la Peña wrote:
>
>
> If nobody has
If nobody has more concerns regarding the CEP I will start the vote
tomorrow.
On Wed, 31 Aug 2022 at 13:18, Andrés de la Peña
wrote:
> Is there enough support here for VIEWS to be the implementation strategy
>> for displaying masking functions?
>
>
> I'm not sure
>
> Is there enough support here for VIEWS to be the implementation strategy
> for displaying masking functions?
I'm not sure that views should be "the" strategy for masking functions. We
have multiple approaches here:
1) CQL functions only. Users can decide to use the masking functions on
I think I'd prefer 2), the SQL behaviour. We could also get the convenience
of 3) by adding CQL functions such as "ifNull(column, default)" or
"zeroIfNull(column)", as it's done by other dbs. So we could do things like
"UPDATE ... SET name = zeroIfNull(name) + 42".
On Wed, 31 Aug 2022 at 04:54,
g masking to schema would be
> sufficient for an initial goal? That wouldn't preclude additional
> permissions, schema integration, or perhaps just plain Views in the future.
>
> Cheers,
>
> Derek
>
> On Thu, Aug 25, 2022 at 11:12 AM Andrés de la Peña
> wrote:
>
>
te, you're saying we would need SELECT_MASKED to use it in
>> the IF clause? I worry that this proposal is increasing in complexity; I
>> would actually be OK starting with something smaller in scope. Perhaps just
>> providing the masking functions and not tying masking to schema would be
rting with something smaller in scope. Perhaps just
> providing the masking functions and not tying masking to schema would be
> sufficient for an initial goal? That wouldn't preclude additional
> permissions, schema integration, or perhaps just plain Views in the future.
>
> Cheers,
>
ture.
>
> Cheers,
>
> Derek
>
> On Thu, Aug 25, 2022 at 11:12 AM Andrés de la Peña
> wrote:
>
>> I have modified the proposal adding a new SELECT_MASKED permission. Using
>> masked columns on WHERE/IF clauses would require having SELECT and either
>> UNMASK or
gt; Is it typical for a masking feature to make no effort to prevent
>> unmasking? I’m just struggling to see the value of this without such
>> mechanisms. Otherwise it’s just a default formatter, and we should consider
>> renaming the feature IMO
>>
>> On 23 Aug 2022, a
default - forbid querying on
> columns that are masked, unless the mask permits it.
>
>
> On 24 Aug 2022, at 11:06, Andrés de la Peña wrote:
>
>
> Here are the names of the feature on same databases out there, errors and
> omission excepted:
>
>- Microsoft SQL S
ble to determine its value in one query. On the other hand masking credit
>>>> card numbers makes a lot of sense as it will complicate the life of the
>>>> person trying to have access to it and the queries needed to reach the
>>>> information will leave so
numbers makes a lot of sense as it will complicate the life of the
>>>> person trying to have access to it and the queries needed to reach the
>>>> information will leave some clear traces in the audit log.
>>>>
>>>> Dynamic Data Masking is not a magic bul
erns around masking primary key components. It's
>>> highly likely that certain personal data properties would be used as a
>>> partition or clustering key (ex: range query for people born within a
>>> certain timeframe). In addition to the "breaks existing" c
; one version of it in the result set, even if you had a way to define
> several functions.
>
> I'm not proposing this should change, just calling it out.
>
> henrik
>
> On Fri, Aug 19, 2022 at 2:50 PM Andrés de la Peña
> wrote:
>
>> Hi everyone,
>>
>>
+1 (nb)
On Tue, 23 Aug 2022 at 06:14, Tommy Stendahl via dev <
dev@cassandra.apache.org> wrote:
> +1 nb
>
> -Original Message-
> *From*: Brandon Williams >
> *Reply-To*: dev@cassandra.apache.org
> *To*: dev
> >
> *Subject*: Re: [VOTE] Release Apache Cassandra 4.0.6
> *Date*: Mon, 22
onger, but
> this feels like a sticking plaster that distracts from that underlying
> issue.
>
> my 0.02
>
> On Mon, Aug 22, 2022 at 12:30 AM Andrés de la Peña
> wrote:
>
>> > If the column names are the same for masked and unmasked data, it would
>>> im
ructure.
>
> I am not sure either about it's value, as that would still break any key
> or other cross-referencing.
>
> My 2cts.
> On 22/8/22 1:30, Andrés de la Peña wrote:
>
> > If the column names are the same for masked and unmasked data, it would
>> impact
None of the databases mentioned on the "other databases" section of
the CEP does this kind of column renaming, so it might be a kind of exotic
behaviour. wdyt?
On Fri, 19 Aug 2022 at 19:17, Andrés de la Peña
wrote:
> > This type of feature is very useful, but it may be easier to analyz
nd output from eg Azure SQL vs Cassandra vs whatever ?
>
>
> On Aug 19, 2022, at 4:50 AM, Andrés de la Peña
> wrote:
>
>
> Hi everyone,
>
> I'd like to start a discussion about this proposal for dynamic data
> masking:
> https://cwiki.apache.org/confluence/display/CA
Hi everyone,
I'd like to start a discussion about this proposal for dynamic data
masking:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
Dynamic data masking allows to obscure sensitive information without
changing the stored data. It would be based on a set
>
> > I think if we want to do this, it should be extremely easy - by which I
> mean automatic, really. This shouldn’t be too tricky I think? We just need
> to produce a diff of new test classes and methods within existing classes.
Having a CircleCI job that automatically runs all new/modified
> > On Tue, Jul 26, 2022 at 8:19 AM J. D. Jordan
>> wrote:
>> >>
>> >> I like the third option, especially if it makes it consistent with
>> repair, which has supported ranges longer and I would guess most people
>> would think the compact ranges work th
Hi all,
CASSANDRA-17575 has detected that token ranges in nodetool compact are
interpreted as closed on both sides. For example, the command "nodetool
compact -st 10 -et 50" will compact the tokens in [10, 50]. This way of
interpreting token ranges is unusual since token ranges are usually
+1 nb
On Tue, 24 May 2022 at 16:10, Benjamin Lerer wrote:
> +1
>
> Le mar. 24 mai 2022 à 16:19, Josh McKenzie a
> écrit :
>
>> +1
>>
>> On Tue, May 24, 2022, at 10:13 AM, Brandon Williams wrote:
>>
>> +1
>>
>> On Tue, May 24, 2022 at 3:39 AM Mick Semb Wever wrote:
>> >
>> > Proposing the test
+1 (nb)
On Wed, 11 May 2022 at 09:00, Sam Tunnicliffe wrote:
> +1
>
> > On 7 May 2022, at 07:39, Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 4.0.4 for release.
> > This is from the (take4) test artifact.
> >
> > sha1: 052125f2c6ed308f1473355dfe43470f0da44364
> > Git:
>
+1 (nb)
On Wed, 11 May 2022 at 09:00, Sam Tunnicliffe wrote:
> +1
>
> > On 7 May 2022, at 07:38, Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 3.11.13 for release.
> >
> > sha1: 836ab2802521a685efe84382cb48db56caf4478d
> > Git:
>
+1 (nb)
On Wed, 11 May 2022 at 08:59, Sam Tunnicliffe wrote:
> +1
>
> > On 7 May 2022, at 07:37, Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 3.0.27 for release.
> >
> > sha1: 205366131484967a3a8a749f1d1d841c952127e8
> > Git:
>
Hi,
Although it's not yet officially supported and it might still change in a
minor release, guardrails config is also pluggable (CEP-3). It is possible
to provide a custom implementation supplying guardrail properties different
to those defined in cassandra.yaml, so the thresholds, flags, etc.
Hi all,
9 people have already participated on the Build Lead rotation, now we need
a brave volunteer for the next week.
Thanks for your help,
On Wed, 2 Mar 2022 at 17:10, Ekaterina Dimitrova
wrote:
> Hi everyone,
>
> It's been a month and a half since we started the Build Lead rotation.
> 6
Congrats, well deserved!
On Wed, 16 Mar 2022 at 14:01, J. D. Jordan
wrote:
> Congratulations!
>
> On Mar 16, 2022, at 8:43 AM, Ekaterina Dimitrova
> wrote:
>
>
> Great news! Well deserved! Congrats and thank you for all your support!
>
> On Wed, 16 Mar 2022 at 9:41, Paulo Motta wrote:
>
>>
+1
On Wed, 16 Mar 2022 at 11:55, Anthony Grasso
wrote:
> +1
>
> On Wed, 16 Mar 2022 at 21:58, bened...@apache.org
> wrote:
>
>> +1
>>
>>
>>
>> *From: *Erick Ramirez
>> *Date: *Tuesday, 15 March 2022 at 22:08
>> *To: *dev@cassandra.apache.org
>> *Subject: *Re: [FOR REVIEW] Blog post: An
Last time I checked there wasn't support for vnodes on in-jvm dtests, which
seems an important limitation.
On Mon, 14 Mar 2022 at 12:24, bened...@apache.org
wrote:
> I am strongly in favour of deprecating python dtests in all cases where
> they are currently superseded by in-jvm dtests. They
+1nb
On Wed, 16 Feb 2022 at 15:57, C. Scott Andreas wrote:
> +1nb
>
> On Feb 16, 2022, at 5:59 AM, Jeremy Hanna
> wrote:
>
> +1 nb. Thanks for all of the great work on this Branimir. Excited to
> see this moving forward.
>
> On Feb 16, 2022, at 7:56 AM, J. D. Jordan
> wrote:
>
> +1 nb
>
>
Last time I ported dtests during the 4.0 quality test epic there wasn't
support for virtual nodes in in-jvm dtests. We have many Python dtests
depending on vnodes that can't be totally ported if we still don't have
support for vnodes, I don't know if it's still the case.
On Wed, 26 Jan 2022 at
+1
On Mon, 24 Jan 2022 at 12:29, Brandon Williams wrote:
> +1
>
> On Thu, Jan 13, 2022 at 12:17 PM Mick Semb Wever wrote:
> >
> > Proposing the test build of in-jvm dtest API 0.0.12 for release.
> >
> > Repository:
> >
>
Still +1 with the amendment
On Wed, 12 Jan 2022 at 19:57, C. Scott Andreas wrote:
> +1nb, with and without the amendment.
>
> Reason for mentioning without: I see the ability to cut a release to
> address an urgent security or data loss issue as one of the strongest
> arguments for maintaining
1 - 100 of 154 matches
Mail list logo
