Congrats all!
On 17/4/24 23:23, Jeremiah Jordan wrote:
Congrats all!
On Apr 17, 2024 at 12:10:11 PM, Benjamin Lerer wrote:
The Apache Cassandra PMC is pleased to announce that Alexandre Dutra,
Andrew Tolbert, Bret McGuire and Olivier Michallat have accepted the
invitation to become
+1
On 12/4/24 20:52, Brandon Williams wrote:
Proposing the test build of Cassandra 3.11.17 for release.
sha1: d079952c50019c3c8c96e341a01f7bc0554e1733
Git: https://github.com/apache/cassandra/tree/3.11.17-tentative
Maven Artifacts:
costs and time down. Once 18753 merges and the
discussion is finalized we can re-visit the pre-commit workflow to put
it on a diet.
Regards.
On 20/2/24 13:35, Berenguer Blasi wrote:
In the past it has been asked, iirc, to use discuss threads rather
than tickets for visibility. So details
Congrats!
On 22/2/24 9:57, Jacek Lewandowski wrote:
Congrats Brad!
- - -- --- - -
Jacek Lewandowski
czw., 22 lut 2024 o 01:29 Štefan Miklošovič
napisał(a):
Congrats Brad, great work in the Python department :)
On Wed, Feb 21, 2024 at 9:46 PM Josh
and discuss that directly on the ticket.
- - -- --- - -
Jacek Lewandowski
wt., 20 lut 2024 o 11:31 Berenguer Blasi
napisał(a):
Hi All,
after the recent discussion that came up in CASSANDRA-18753's discuss
thread and given it is a long aspiration of mine it's
Hi All,
after the recent discussion that came up in CASSANDRA-18753's discuss
thread and given it is a long aspiration of mine it's probably a good
time to thread this needle.
Jacek was kind enough to open CASSANDRA-19406 for us so I would suggest
everybody interested to watch those
On reducing circle ci usage during dev while iterating, not with the
intention to replace the pre-commit CI (yet), we could do away with
testing only dtests, jvm-dtests, units and cqlsh for a _single_
configuration imo. That would greatly reduce usage. I hacked it quickly
here for illustration
On the merging failing tests discussion I _do_ spend the time looking if
my patch did cause them or not and I certainly enforce that in the
reviews I do. The current failures are a manageable number to check
against Butler/Jenkins/Circle/Jira so I was under the impression
everybody else was
+1 to not doing, imo, the ostrich lol
On 14/2/24 10:58, Jacek Lewandowski wrote:
We should not block merging configuration changes given it is a valid
configuration - which I understand as it is correct, passes all config
validations, it matches documented rules, etc. And this provided
latest
*
*From: *Berenguer Blasi
*Date: *Wednesday, 24 January 2024 at 5:01 pm
*To: *dev@cassandra.apache.org
*Subject: *Re: [ANNOUNCE] Apache Cassandra 4.1.4 test artifact available
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
-1
I just raised CASSANDRA-19097 (4.0->
: *Berenguer Blasi
*Date: *Wednesday, 24 January 2024 at 5:01 pm
*To: *dev@cassandra.apache.org
*Subject: *Re: [ANNOUNCE] Apache Cassandra 4.1.4 test artifact available
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
-1
I just raised CASSANDRA-19097 (4.0->5.0) to critical. Basica
-1
I just raised CASSANDRA-19097 (4.0->5.0) to critical. Basically we fail
to bootstrap correctly and even reading at ALL after bootstrapping fails
to get the correct data. We didn't manage to repro and the failure looks
recently-ish. Any help from anybody familiar with that area of the code
Welcome!
On 9/1/24 13:16, Maxim Muzafarov wrote:
Thank you all so much, I'm happy to be part of such an active
community and to be able to contribute to the product that is used all
over the world!
On Tue, 9 Jan 2024 at 12:33, Mike Adamson wrote:
Congrats Maxim!!
On Tue, 9 Jan 2024, 10:41
Well done Sir! Congrats
On 9/12/23 13:47, Piotr Kołaczkowski wrote:
Congratulations, Mike! Well deserved, working with you has always been
a pleasure!
Wiadomość napisana przez Melissa Logan w dniu
09.12.2023, o godz. 02:35:
Congratulations, Mike!
On Fri, Dec 8, 2023 at 11:13 AM David
If you checked SHAs I suspect we would skip 90% of the dtests-jar builds
in CI?
On 29/11/23 9:26, Mick Semb Wever wrote:
On Tue, 28 Nov 2023 at 20:06, Abe Ratnofsky wrote:
Hey folks - wanted to raise a separate thread to discuss
publishing of dtest-shaded JARs on release.
Welcome!
On 29/11/23 2:24, guo Maxwell wrote:
Congrats!
Jacek Lewandowski 于2023年11月29日周三
06:16写道：
Congrats!!!
wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky
napisał:
Congrats Francisco!
> On Nov 28, 2023, at 1:56 PM, C. Scott Andreas
wrote:
Hi,
I have written this email like 10 times before sending it and I can't
manage to avoid making it sound with a negative spin to it. So pardon my
English or poor choice of words in advance and try to read it in a
positive way.
It is really demotivating to me seeing things getting merged
I also think there's many good new features in 5.0 already they'd make a
good release even on their own. My 2 cts.
On 24/10/23 23:20, Brandon Williams wrote:
The catch here is that we don't publish docker images currently. The
C* docker images available are not made by us.
Kind Regards,
+1
On 4/10/23 4:43, Erick Ramirez wrote:
+1
+1 I agree with Brandon. It's more like a bug imo.
On 20/9/23 21:42, Caleb Rackliffe wrote:
+1 on a 5.0 backport
On Wed, Sep 20, 2023 at 2:26 PM Brandon Williams wrote:
I think it could be argued that not retrying messages is a bug, I am
+1 on including this in 5.0.
Kind
+1
On 4/9/23 22:28, Mick Semb Wever wrote:
The vote will be open for 72 hours (longer if needed). Everyone
who has tested the build is invited to vote. Votes by PMC members
are considered binding. A vote passes if there are at least three
binding +1s and no -1's.
+1
Checked
SGTM +1
On 27/7/23 6:39, Dinesh Joshi wrote:
Mick,
This sounds like a good plan. CEP-33 and 34 are ready to go. We're
running into CI related issues but once they clear up we'll merge
them. I anticipate we'll be done in a week's time.
Thanks,
Dinesh
On Jul 26, 2023, at 3:27 PM, Mick
Nice one!
On 26/7/23 21:11, Ekaterina Dimitrova wrote:
Thanks Caleb!
Great job everyone!
On Wed, 26 Jul 2023 at 15:07, J. D. Jordan
wrote:
Thanks for all the work here!
On Jul 26, 2023, at 1:57 PM, Caleb Rackliffe
wrote:
Alright, the cep-7-sai branch is now
log
and add an upgrade note.
B. That was supported, regardless of how weird it may be. Cap it to the
current max year 4254, maybe log and add an upgrade note.
Happy to hear your thoughts.
On 5/7/23 7:05, Berenguer Blasi wrote:
Hi All,
https://issues.apache.org/jira/browse/CASSANDRA-18648
matrices + env) runs. On
green, merge.
2: Post-commit tests (all suites, matrices, env) runs. If
failure, link back to the JIRA where the commit took place
Circle would need to remain in lockstep with the requirements for
point 1 here.
On Mon, Jul 10, 2023, at 1:04 AM, Berenguer B
.
2: Post-commit tests (all suites, matrices, env) runs. If failure,
link back to the JIRA where the commit took place
Circle would need to remain in lockstep with the requirements for
point 1 here.
On Mon, Jul 10, 2023, at 1:04 AM, Berenguer Blasi wrote:
+1 to Josh which is exactly my line
+1 to Josh which is exactly my line of thought as well. But that is only
valid if we have a solid Jenkins that will eventually run all test
configs. So I think I lost track a bit here. Are you proposing:
1- CircleCI: Run pre-commit a single (the most common/meaningful, TBD)
config of tests
Hi All,
https://issues.apache.org/jira/browse/CASSANDRA-18648 up for review and
the PR is quite small
Regards
On 3/7/23 11:03, Berenguer Blasi wrote:
Thanks for the comments Benedict. Given DeletionTime.localDeletionTime
is what caps everything to year 2106 (uint enconded now) I am ok
Currently a dtest is being ran in j8 w/wo vnodes , j8/j11 w/wo vnodes
and j11 w/wo vnodes. That is 6 times total. I wonder about that ROI.
On dtest cluster reusage yes, I stopped that as at the time we had lots
of CI changes, an upcoming release and priorities. But when the CI
starts flexing
2023, at 05:45, Berenguer Blasi
wrote:
It can look into it. I don't have a deep knowledge of the sstable
format hence why I wanted to document it someday. But DeletionTime is
being serialized in other places as well iirc and I doubt (finger in
the air) we'll have that Epoch handy.
On 29/6
It can look into it. I don't have a deep knowledge of the sstable format
hence why I wanted to document it someday. But DeletionTime is being
serialized in other places as well iirc and I doubt (finger in the air)
we'll have that Epoch handy.
On 29/6/23 17:22, Benedict wrote:
So I’m just
The idea is 11 bytes less per LIVE partition. So small partitions will
benefit the most.
On 29/6/23 18:44, Brandon Williams wrote:
On Thu, Jun 29, 2023 at 11:42 AM Jeff Jirsa wrote:
3-4% reduction on disk ... for what exactly?
It seems exceptionally uncommon to have 3% of your data SIZE be
checkstyle (at least) can be
disabled with a flag.
If we did do this, would it make sense to have a "release" or
"commit" target (or some other name) that ran a full build with
all checks that can be used prior to pushing changes?
On Mon, 26 Jun 2023 at 08:
is particularly more complex than the
other. There is a modest cost to maintenance from changing this
multiple times.
But if others feel strongly otherwise I won’t stand in the way.
On 26 Jun 2023, at 05:49, Berenguer Blasi
wrote:
Thanks for the replies.
I intend to javadoc the ssatble
I would prefer sthg that is totally transparent to me and not add one
more step I have to remember. Just to push/run CI to find out I missed
it and rinse and repeat... With the recent fix to checkstyle I am happy
as things stand atm. My 2cts
On 26/6/23 8:43, Jacek Lewandowski wrote:
Hi,
, 2023, at 9:02 AM, Berenguer Blasi wrote:
It's a possibility. Though I haven't coded and benchmarked such an
approach and I don't think I would have the time before the freeze to
take advantage of the sstable format change opportunity.
Still it's sthg that can be explored later. If we can shave
about this, I can already tell you now.
Sounds like a reasonable improvement to me however.
On 23 Jun 2023, at 07:22, Berenguer Blasi wrote:
Hi all,
DeletionTime.markedForDeleteAt is a long useconds since Unix Epoch. But I
noticed that with 7 bytes we can already encode ~2284 years. We can
Hi all,
DeletionTime.markedForDeleteAt is a long useconds since Unix Epoch. But
I noticed that with 7 bytes we can already encode ~2284 years. We can
either shed the 8th byte, for reduced IO and disk, or can encode some
sentinel values (such as LIVE) as flags there. That would mean reading
+1
On 26/5/23 6:07, guo Maxwell wrote:
+1
Dinesh Joshi 于2023年5月26日 周五上午11:08写道：
+1
On May 25, 2023, at 8:45 AM, Jonathan Ellis
wrote:
Let's make this official.
CEP:
+1
On 25/5/23 22:12, Mick Semb Wever wrote:
The vote will be open for 72 hours (longer if needed). Everyone
who has tested the build is invited to vote. Votes by PMC members
are considered binding. A vote passes if there are at least three
binding +1s and no -1's.
+1
+1
On 25/5/23 21:57, Mick Semb Wever wrote:
The vote will be open for 72 hours (longer if needed). Everyone
who has tested the build is invited to vote. Votes by PMC members
are considered binding. A vote passes if there are at least three
binding +1s and no -1's.
+1
+1
On 10/5/23 3:57, Jonathan Ellis wrote:
+1
On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
wrote:
Let's vote.
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
Piotr Kołaczkowski
e. pkola...@datastax.com
w. www.datastax.com
+1
On 2/5/23 8:37, Miklosovic, Stefan wrote:
Proposing the test build of Cassandra 3.11.15 for release.
sha1: 6cdcf5e56a77cf40c251125d68856a614eccbc53
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.15-tentative
Maven Artifacts:
an 4.1 at this point so I believe
that we should also release a 4.0.9 version.
Le mar. 14 mars 2023 à 17:27, Josh McKenzie
mailto:jmcken...@apache.org>> a écrit :
+1
On Tue, Mar 14, 2023, at 7:50 AM, Aleksey Yeshchenko wrote:
+1
On 14 Mar 2023, at 05:50, Berenguer Blasi
mailto:berenguerbl.
+1
On 11/4/23 9:54, Miklosovic, Stefan wrote:
Lets just vote on that straight away. Nothing significant has changed except
zstd-jni update to 1.5.5. If all goes well it would be nice to have the vote
resolved by this Friday's noon UTC.
Proposing the test build of Cassandra 4.0.9 for release.
not beginners imho.
BTW keep in mind that all nodetool commands which are using "keyspace" terminology would
have to be probably accommodated to "database" term as well.
____
From: Berenguer Blasi
Sent: Thursday, April 6, 2023 9:47
One aspect to take into account is that we might not go even get as far
as having a chance to educate the user. They start the thing up, see a
wall of logs and then start seeing 'keyspace' (what is that?), etc.
Everything seems so foreign and out of band to their 'normal' experience
they just
+1
On 4/4/23 14:36, J. D. Jordan wrote:
+1
On Apr 4, 2023, at 7:29 AM, Brandon Williams wrote:
+1
On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov wrote:
Hi everyone,
I would like to put CEP-26 to a vote.
Proposal:
Hi all,
assuming lazy consensus here
Regards
On 22/3/23 15:55, Berenguer Blasi wrote:
Hi all,
14227 has undergone review and perf numbers look ok. Now I have to
tackle the downgradability issue and hopefully then merge. This is
what I have gathered from the many conversations, please help
Congrats Josh!
On 23/3/23 9:22, Mick Semb Wever wrote:
It is time to pass the baton on, and on behalf of the Apache Cassandra
Project Management Committee (PMC) I would like to welcome and
congratulate our next PMC Chair Josh McKenzie (jmckenzie).
Most of you already know Josh, especially
.
On 3/2/23 15:24, Henrik Ingo wrote:
In that case I agree that increasing from 20 years is an interesting
opportunity but clearly out of scope for your current ticket.
On Fri, Feb 3, 2023 at 3:48 PM Berenguer Blasi
wrote:
Hi,
20y is the current and historic value. 68y is what
Hi,
I would add that CEP-20 DDM C17940 has made huge progress and nearing
completion, all praise and glory to Andres. Also TTL c14227 has made big
progress completing the first round of review and pending the sstable
format/feature flag switch only so far.
Regards
On 20/3/23 21:30,
+1
On 13/3/23 21:25, Jacek Lewandowski wrote:
+1
pon., 13 mar 2023, 20:36 użytkownik Miklosovic, Stefan
napisał:
Yes, I was waiting for CASSANDRA-18125 to be in.
I can release 4.1.1 to staging tomorrow morning CET if nobody
objects that.
Not sure about 4.0.9. We released
TTL (CASSANDRA-14227) is undergoing review and it's in final stages
afaik. A big rebase and perf re-testing will be needed to confirm all is
still good. I would expect this to happen this month.
Then the feature flag and downgradability issue, which are unkown atm in
terms of complexity, are
+1 deprecate + removal
On 10/3/23 1:41, Jeremy Hanna wrote:
It was mainly to integrate with Hadoop - I used it from 0.6 to 1.2 in
production prior to starting at DataStax and at that time I was
stitching together Cloudera's distribution of Hadoop with Cassandra.
Back then there were others
févr. 2023 à 09:48, manish khandelwal
a écrit :
Hi Team
We are hit by this bug as we approach the deadline as we reach
close to 2038 as we can see some of our projects breaching the
deadline fixed.
I can see some progress made in this bug by Berenguer Blasi in
last few
+1
On 9/2/23 12:50, Brandon Williams wrote:
+1
Kind Regards,
Brandon
On Thu, Feb 9, 2023 at 4:56 AM Miklosovic, Stefan
wrote:
Proposing the test build of Cassandra 4.0.8 for release.
sha1: 32c56df067b72da8593c1ddaaf143fe8668459dd
Git:
Hi All,
I don't think we can be 100% prescriptive here. There will always be
gray areas on where API changes start or end. Even on what is an API
change and discussions about why a change was forgotten, not
communicated, etc. I think we should rely on people's judgement on when
to hit the
any values we want, instinctively I would personally
suggest to have TTL higher than 20 years, but also kicking the can
further than 2035, which is only 13 years from now. Just to suggest a
specific number, why not 35y and 2071?
henrik
On Fri, Feb 3, 2023 at 12:32 PM Berenguer Blasi
wrote
Hi All,
a version using Uints, 20y max TTL and kicking the can down the road
until 2086 has been put up for review #justfyi
Regards
On 15/11/22 7:06, Berenguer Blasi wrote:
Hi all,
thanks for your answers!.
To Benedict's point: In terms of the uvint enconding of deletionTime
i.e
Welcome!
On 3/2/23 4:09, Vinay Chella wrote:
Well deserved one, Congratulations, Patrick.
On Fri, Feb 3, 2023 at 4:01 AM Josh McKenzie wrote:
Congrats Patrick! Well deserved.
On Thu, Feb 2, 2023, at 5:25 PM, Molly Monroy wrote:
Congrats, Patrick... much deserved!
On Thu,
I did check it when it was originally posted, I had no major concerns :-)
On 2/2/23 7:14, Mick Semb Wever wrote:
No objections from me! And yes, 7 days have passed and no one has
spoken up, you're a committer – you can assume silence is consent.
Folks, Lorina's proposal here is very
+1
On 5/12/22 10:53, guo Maxwell wrote:
+1
Mick Semb Wever 于2022年12月5日 周一下午5:33写道：
Proposing the test build of Cassandra 4.1.0 GA for release.
sha1: b807f97b37933fac251020dbd949ee8ef245b158
Git:
+1 to moving that into it's own section outside the coding style page.
Dinesh I also thought in terms of backward compatibility here. But
notice the discussion is about _any change_ to the API such as adding
new CQL functions. Would adding or changing an exception type or a user
warning
+1
On 18/11/22 13:37, Aleksey Yeshchenko wrote:
+1
On 18 Nov 2022, at 12:10, Mick Semb Wever wrote:
Proposing the test build of Cassandra 4.1-rc1 for release.
sha1: d6822c45ae3d476bc2ff674cedf7d4107b8ca2d0
Git:
und use cases.
From the perspective of storage overhead, the unsigned int approach
sounds preferable.
On Nov 13, 2022, at 10:13 PM, Berenguer Blasi
wrote:
Hi all,
We have done some more research on c14227. The current patch for
CASSANDRA-14227 solves the TTL limit issue by switchin
+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:
+1
On Mon, 14 Nov 2022 at 17:55, Brandon Williams wrote:
+1 to waiving
at 20y instead
of 68y to give us enough breathing room though, otherwise in 2035 we'd
hit the same problem again.
Happy to hear opinions.
On 18/10/22 10:56, Berenguer Blasi wrote:
Hi,
apologies for the late reply as I have been OOO. I have done some
profiling and results look virtually identical
+1 to consolidating on one option and aliasing where needed. Avoiding
camel-case to spare the user the quoting seems also like a good idea to me.
On 10/11/22 13:20, 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
+1 to static code analysis and hoping it's smart enough to check only
changed files instead of adding 30s to each build by checking everything
:fingerscrossed:
On 8/11/22 2:03, Brandon Williams wrote:
I suspect we'll have a -Dno-spotbugs flag as a counterpart to the
-Dno-checkstyle flag we
Re '@Test' without 'abstract': There's a corner case of a base abstract
class with all test cases. Then 2 or 3 inheriting classes with no
'@Test' annotations bc they just run the base class with different
configs, setups, envs, parametrized runs, etc I've seen some of those.
On 1/11/22 22:54,
be
happy to drive option 2 to completion if needed.
wdyt?
On 25/10/22 14:35, Berenguer Blasi wrote:
Well examples lend themselves to many things. I am sure I could come
up with examples in the opposite direction. I'd rather talk in terms
of the actual files and tests we have.
What I
at happens. You want to
cover that guy too.
I just find my approach easier.
You can remodel it all, for sure but I am afraid I will not be a
part of that. I just do not find it necessary to do that.
____
From: Berenguer Blasi
Sent: Tuesday,
we plan to cover with relaxed test.name property.
It seems like what you wrote means that we will fix it and tests will leak
again. That is not true.
____
From: Berenguer Blasi
Sent: Tuesday, October 25, 2022 7:26
To: dev@cassandra.apache.org
Subject: Re:
The problem with using the first approach is that it fixes the current
situation but it doesn't prevent it from happening again. The second
proposal prevents it from happening again but at the cost of a bigger
rename I'd volunteer to if needed.
Regards
On 24/10/22 20:38, Miklosovic, Stefan
Can python upgrade tests be ran without -h? Last time I tried iirc they
fail on -m
On 20/10/22 4:11, Ekaterina Dimitrova wrote:
Thank you Josh. Glad to see that our CI is getting more attention. As
no Cassandra feature will be there if we don't do proper testing,
right? Important as all the
look the same.
Regards
On 30/9/22 9:44, Berenguer Blasi wrote:
Hi Benedict,
thanks for the reply! Yes some profiling is probably needed, then we
can see if going down the delta encoding big refactor rabbit hole is
worth it?
Let's see what other concerns people bring up.
Thx.
On 29/9/22
+1
On 30/9/22 16:20, Brandon Williams wrote:
I'm +1 under these conditions as well.
Kind Regards,
Brandon
On Thu, Sep 29, 2022 at 3:34 PM Mick Semb Wever wrote:
The vote will be open for 72 hours (longer if needed). Everyone who has tested
the build is invited to vote. Votes by PMC
value by adding nowInSec to the deletionTime, and
make the underlying value private, refactoring call sites?
On 29 Sep 2022, at 09:37, Berenguer Blasi
wrote:
Hi all,
I have taken a stab in a PR you can find attached in the ticket. Mainly:
- I have moved deletion times, gc and nowInSec
+1
On 29/9/22 15:42, Derek Chen-Becker wrote:
+1 from me. It sounds like a good opportunity!
Cheers,
Derek
On Thu, Sep 29, 2022, 6:26 AM Brad wrote:
The Python standard library introduced argparse a decade ago in
Python 2.7 to replace optparse as described in PEP-0389
Hi all,
I have taken a stab in a PR you can find attached in the ticket. Mainly:
- I have moved deletion times, gc and nowInSec timestamps to long. That
should get us past the 2038 limit.
- TTL is maxed now to 68y. Think CQL API compatibility and a sort of a
'free' guardrail.
- A new NONE
I would add an option for generate.sh to detect all changed *Test.java
files, that would be handy imo.
On 28/9/22 4:29, Josh McKenzie wrote:
So:
1. 500 iterations on multiplexer
2. Augmenting generate.sh to allow providing multiple class names and
generating a single config that'll
+1
On 19/9/22 13:39, Brandon Williams wrote:
+1
Kind Regards,
Brandon
On Mon, Sep 19, 2022 at 6:39 AM Andrés de la Peña wrote:
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:
A. I agree the implementor's preference is an important aspect to take
into account.
On 7/9/22 15:23, Ekaterina Dimitrova wrote:
A
On Wed, 7 Sep 2022 at 9:05, Andrés de la Peña
wrote:
The poll makes sense to me. I would slightly change it to:
A) We shouldn't prefer neither
+1
On 23/8/22 14:50, Ekaterina Dimitrova wrote:
+1(nb)
On Tue, 23 Aug 2022 at 8:49, Josh McKenzie wrote:
+1
On Tue, Aug 23, 2022, at 6:47 AM, Benjamin Lerer wrote:
+1
Le mar. 23 août 2022 à 11:30, Andrés de la Peña
a écrit :
+1 (nb)
On Tue, 23 Aug
Maybe a small improvement is the redacted value could be of the form
`XXX1...1000` meaning XXX followed by a rand number from 1 to 1000:
XXX54, XXX998, XXX456,... Some randomness would prevent some apps
flattening all rows to a single XXX'ed one, giving a more realistic
redacted data
+1 to Mick's points.
Also notice in circle 4.1 green runs are the norm lately imo. Yes it's
not the official CI but it helps build an overall picture of improvement
towards green CI. On jenkins, if you check the latest 4.1 runs, <5-ish
failures per run are starting to be common and those that
+1 to new flags also from me
On 26/7/22 18:39, Andrés de la Peña wrote:
I think that's right, using a closed range makes sense to consume the
data provided by "sstablemetadata", which also provides closed ranges.
Especially because with half-open ranges we couldn't compact a sstable
with a
Thanks Nate and congrats Mick!
On 12/7/22 5:24, Charles Cao wrote:
Thanks Nate and Congrats Mike for the new role!
~Charles
On Jul 11, 2022, at 08:03, Mick Semb Wever wrote:
Thank you Nate, and Paulo and everyone!
On Mon, 11 Jul 2022 at 15:57, Ekaterina Dimitrova
wrote:
Hi All,
if I am parsing this thread correctly it seems we have a number of
options to attack and some are already progressing: tmp misconfig,
docker misconfig, unmatched resources in different CI envs, no
definition of minimal HW requiremenets, etc.
But so far nothing against merging
+1
On 8/7/22 18:42, Jeremiah D Jordan wrote:
4.0.4 went out mid May, so +1 from me for cutting 4.0.5 soon/now.
Should we get into a habit of releasing patch releases on some
schedule rather than waiting for someone to randomly ask for a release
after committing something they feel is
Congrsss Sir! :-)
On 6/7/22 14:00, Benjamin Lerer wrote:
The PMC members are pleased to announce that Jacek Lewandowski has
accepted
the invitation to become committer.
Thanks a lot, Jacek, for everything you have done!
Congratulations and welcome
The Apache Cassandra PMC
Hi All,
bringing https://issues.apache.org/jira/browse/CASSANDRA-17729 to the ML
for visibility as this has been a discussion point with some of you.
I noticed tests timeout much more on jenkins that circle. I was
wondering if legit bugs were hiding behind those timeouts and it might
be the
There are 3 view filtering test failures in the 8 4.1 failures which are
known offenders as being parametrized they might take long in an
overloaded systems. Once we're back to normal capacity on jenkins they
should be ok, finger in the air estimate, so we might be even better
than 8.
+1 nb
On 26/5/22 16:25, Ekaterina Dimitrova wrote:
+1 (nb)
On Tue, 24 May 2022 at 11:37, Andrés de la Peña
wrote:
+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
document.
Kind Regards,
Brandon
On Fri, May 20, 2022 at 10:05 AM Chris Thornett
wrote:
>
> Hello everyone,
>
> Here's the next Cassandra blog for the usual 72-hour community
review (lazy consensus). This one is written by Berenguer Blasi.
Please
+1 also from me. Merging versions or bulk updating should solve the post
release version consolidation. We just need to enable that if that'd be
the case.
On 10/5/22 16:20, J. D. Jordan wrote:
+1 from me.
On May 10, 2022, at 9:17 AM, Josh McKenzie wrote:
at some later point it needs to
Overloading fixVersion shouldn't be a problem. IIRC you can:
- bulk update
- Merge versions:
https://support.atlassian.com/jira-work-management/docs/view-and-manage-a-projects-versions/#Merge-versions
We just need the permissions for jira to allow us to do it.
Regards
On 10/5/22 3:02, Mick
+1 to a new cut
On 6/5/22 14:44, Mick Semb Wever wrote:
Given CASSANDRA-17612 is deserving immediate patch releases for 3.0
upwards, I suggest we veto this candidate and cut a new 4.0.4 (that
also includes 17612).
On Thu, 5 May 2022 at 18:49, Brandon Williams wrote:
+1
Also
+1
On 5/5/22 18:48, Brandon Williams wrote:
+1
Also passed dependency-check
Kind Regards,
Brandon
On Wed, May 4, 2022 at 9:33 AM Mick Semb Wever wrote:
Proposing the test build of Cassandra 4.0.4 for release.
sha1: d4dbc932bf415e0ca17c43289147e7733c67d6ab
Git:
1 - 100 of 167 matches
Mail list logo
