*Glad you brought up compaction here - I think there would be a significant
benefit to moving compaction to direct i/o.*
+1. Would love to see this get traction.
On Mon, 16 Oct 2023 at 19:38, Jon Haddad wrote:
> Glad you brought up compaction here - I think there would be a significant
> benefi
Please can I have an invite to the Slack workspace on this email. I'd like
to take a look through some of the items for first time contributors :-)
Thanks!
On Fri, 27 Oct 2023 at 18:10, Josh McKenzie wrote:
> In case you're keeping score on how frequently these are coming out: *please
> stop*.
*"Glad you brought up compaction here - I think there would be a
significant benefit to moving compaction to direct i/o."*
Support Direct I/O for SSTable writing
https://issues.apache.org/jira/browse/CASSANDRA-19707
On Mon, 16 Oct 2023 at 17:38, Jon Haddad wrote:
> Glad you brought up compacti
This is quite timely as we're just gearing up to begin pushing the work we've
been doing on CEP-21 into the public domain.
This CEP is a slightly different from others that have gone before in that it
touches almost every area of the system. This presents a few implementation
challenges, most
there are at least three binding +1s and no binding vetoes.
Thanks,
Sam
The vote passes with 23 +1s (13 binding) and no negative votes.
Thanks all,
Sam
> On 6 Feb 2023, at 16:15, Sam Tunnicliffe wrote:
>
> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA
Hi,
In the recent DISCUSS thread on merging incremental feature work[1] I mentioned
that we've been preparing a code contribution to support CEP-21[2]. Today we
have a branch based off trunk which supports a significant subset of the
functionality described in the CEP. Whilst being mindful of t
gree on
> some timeline for the freeze. We could then discuss how to make predictable
> the time from freeze to GA.
>
>
>
> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <mailto:jmcken...@apache.org>> a écrit :
>> (for convenience sake, I'm referring to both Major
created a Jira epic (CASSANDRA-18330) as an umberella for CEP-21 and
over the coming days we'll start to file seperate tickets for the
upcoming/remaining work.
[1]
https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249
> On 13 Feb 202
Congrats Josh and big thanks to Mick for everything this past year
> On 23 Mar 2023, at 08: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 Jo
+1
> On 4 May 2023, at 17:46, Doug Rohrer wrote:
>
> Hello all,
>
> I’d like to put CEP-28 to a vote.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics
>
> Jira:
> https://issues.apache.org/jira/brow
+1
> On 25 May 2023, at 16:12, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0.10 for release.
>
> sha1: da77d3f729160e84fbab37666de99550be794265
> Git: https://github.com/apache/cassandra/tree/4.0.10-tentative
> Maven Artifacts:
> https://repository.apache.org/content/rep
+1
> On 25 May 2023, at 16:12, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.1.2 for release.
>
> sha1: c5c075f0080f3f499d2b01ffb155f89723076285
> Git: https://github.com/apache/cassandra/tree/4.1.2-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repos
+1
> On 13 Jun 2023, at 15:14, Jeremy Hanna wrote:
>
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of the
> donation. Nothing more.
> The plan is to introd
There are some completely valid points here, but you are conflating internode
messaging with native (aka client) protocol somewhat. Since native protocol V5
in C* 4.0, there is a degree of code re-use between the two, native protocol
having adopted the framing model and resource allocation from
+1 from me too.
Regarding Benedict's point, backwards incompatibility should be minimal; we
modified snitch behaviour slightly, so that local snitch config only relates to
the local node, all peer info is fetched from cluster metadata. There is also a
minor change to the way failed bootstraps
Definite +1 to bringing harry-core in tree.
> On 24 Nov 2023, at 15:43, Alex Petrov wrote:
>
> Hi everyone,
>
> With TCM landed, there will be way more Harry tests in-tree: we are using it
> for many coordination tests, and there's now a simulator test that uses
> Harry. During development, H
he final agreement was that
>>> the requirement for a merge was a green CI.
>>> I could understand that for some reasons as a community we could wish to
>>> make some exceptions. In this present case there was no official discussion
>>> to ask for an exception
Congrats Francisco!
> On 28 Nov 2023, at 18:52, Dinesh Joshi wrote:
>
> The PMC members are pleased to announce that Francisco Guerrero Hernandez has
> accepted
> the invitation to become committer today.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
+1
> On 29 Nov 2023, at 11:14, Alex Petrov wrote:
>
> Even though we would like to bring harry in-tree, this is not an immediate
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no
> custom jars. We will have at least one more Harry release with outstanding
> featur
Late to the party I'm afraid, but I'd agree with Abe's proposal to deprecate
the dual port approach given that CASSANDRA-10559 makes it pretty much
redundant. Adding further yaml options like "default ssl/no ssl" feels like
another nasty band-aid that we'll have to live with for the foreseeable
>Regarding removal of inheriting superuser role needs broader discussion. There
>must be a reason why it was done and removing this feature may impact existing
>use cases.
The reason behind the current behaviour is almost irrelevant, the fact is that
this is the way that it works and has done s
he kinks
in the TCM implementation itself. It'd be good to get a bit more road testing
done with that before we start adding more to it, which I'm sure will start to
ramp up once 5.0 is out.
Thanks,
Sam
> On 7 Jun 2024, at 19:19, Štefan Miklošovič
> wrote:
>
> Yes,
100% Option 1. Once it's out in GA release we're stuck with it so any short
term disruption to adopters of pre-release versions is a trivial price to pay.
> On 20 Jun 2024, at 17:46, Štefan Miklošovič wrote:
>
> List,
>
> we need your opinions about CASSANDRA-18078.
>
> That ticket is about
-1
I'm afraid we have found an issue with coordinator level latency metrics being
artificially inflated for certain types of queries.
Unfortunately this is a new regression, introduced by CASSANDRA-19534, so we
shouldn't knowingly include it in the release.
The good news is that only a subset
Thanks. For those interested: opened CASSANDRA-14415.
SK
On 2018-04-19 06:04, Benjamin Lerer wrote:
> Hi Sam,
>
> Your finding is interesting. Effectively, if the number of bytes to skip is
> larger than the remaining bytes in the buffer + the buffer size it could be
> fas
K
On 2018-04-24 14:16, Sam Klock wrote:
> Thanks. For those interested: opened CASSANDRA-14415.
>
> SK
>
> On 2018-04-19 06:04, Benjamin Lerer wrote:
>> Hi Sam,
>>
>> Your finding is interesting. Effectively, if the number of bytes to skip is
>> larger than th
-1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
effect on streaming is verified. The concern is that the snitch change
could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for
this.
On 3 July 2018 at 04:02, Nate McCall wrote:
> +1
>
> On Tue, Jul 3
-1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
effect on streaming is verified. The concern is that the snitch change
could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for
this.
On 3 July 2018 at 04:02, Nate McCall wrote:
> +1
>
> On Tue, Jul 3
+1 here too
On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson wrote:
> +1 here as well
>
> On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko
> wrote:
>
> > +1 from me too.
> >
> > —
> > AY
> >
> > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote:
> >
> >
> > > We have done all
+1
On 12 July 2018 at 08:49, Mick Semb Wever wrote:
>
> > Vote will be open for 72 hours.
>
>
> +1 (non-binding)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@ca
+1
On 25 July 2018 at 08:17, Michael Shuler wrote:
> I propose the following artifacts for release as 3.0.17.
>
> sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.0.17-tentative
> Artifacts:
> https://repos
+1
On 25 July 2018 at 08:17, Michael Shuler wrote:
> I propose the following artifacts for release as 2.2.13.
>
> sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/2.2.13-tentative
> Artifacts:
> https://repos
+1
On 25 July 2018 at 08:16, Michael Shuler wrote:
> I propose the following artifacts for release as 3.11.3.
>
> sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.3-tentative
> Artifacts:
> https://repos
+1 for a separate repo
On Fri, 24 Aug 2018 at 06:40, Michael Shuler wrote:
> +1 for a separate repository.
>
> Michael
>
> On 08/23/2018 07:30 PM, Murukesh Mohanan wrote:
> > FWIW, I think it's possible to merge in a separate repository into a
> > subdirectory while keeping git history, but I do
bly be ok with
that. We did vote for a freeze though and I don't want to subvert or
undermine that decision, so I wanted to check and give a chance for anyone
to raise objections before I did.
I'll wait 24 hours, and if nobody objects before then I'll merge to trunk.
Thanks,
Sam
1: A
2: +1
3: +1
4: +1
5: +0
6: +1
On the question of keeping the contributors-only restriction on moving from
Triage->Open, I tend to agree with Benedict that a low barrier can be useful in
deterring bogus transitions (accidental or malicious) which keeps the general
noise down. I’m thinking o
1: D C B A E
2: B C A
3: A
4: -1 (get rid of Wish entirely)
Thanks,
Sam
> On 11 Dec 2018, at 22:01, Joseph Lynch wrote:
>
> Just my 2c
>
> 1. D C B E A
> 2. B, C, A
> 3. A
> 4. +0.5
>
> -Joey
>
> On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith
+1
On Tue, 18 Dec 2018 at 13:47, Joshua McKenzie wrote:
> +1
>
> On Tue, Dec 18, 2018 at 7:30 AM Aleksey Yeshchenko
> wrote:
>
> > Sure, +1
> >
> > > On 18 Dec 2018, at 09:42, Joseph Lynch wrote:
> > >
> > > +1 non-binding
> > >
> > > On Tue, Dec 18, 2018 at 1:15 AM Sylvain Lebresne
> > wrote
Cassandra devs,
I have a question about the implementation of
PartitionUpdate.singleRowUpdate(), in particular the choice to use
EncodingStats.NO_STATS when building the resulting PartitionUpdate. Is
there a functional reason for that -- i.e., is it safe to modify it to
use an EncodingStats built
; mailing list post.
>
>
> On Wed, Dec 19, 2018 at 1:58 PM Sam Klock wrote:
>
>> Cassandra devs,
>>
>> I have a question about the implementation of
>> PartitionUpdate.singleRowUpdate(), in particular the choice to use
>> EncodingStats.NO_STATS whe
that formality I'm starting this thread to gather any
objections or specific requests regarding the timing of the move.
I'll collate responses in a week or so and file the necessary INFRA Jira.
Thanks,
Sam
[1]
https://lists.apache.org/thread.html/667772efdabf49a0a23d585539c127f335477e033
, but filing the JIRA
early next week SGTM.
Thanks,
Sam
> On 4 Jan 2019, at 16:24, Michael Shuler wrote:
>
> This change will be forced on Feb 7, so a vote isn't really relevant :)
>
> I'm in favor of sooner is better. Things are relatively quiet right now,
> post-
https://issues.apache.org/jira/browse/INFRA-17593
<https://issues.apache.org/jira/browse/INFRA-17593>
Thanks,
Sam
> On 4 Jan 2019, at 21:43, Jonathan Haddad wrote:
>
> Great news, we can also remove this line: We cannot merge or close any pull
> requests opened for th
This migration is done, you'll need to update your git remotes like:
git remote set-url origin https://gitbox.apache.org/repos/asf/cassandra.git
Committers, you'll need to link your github and apache accounts via
htts://gitbox.apache.org to get push access.
Thanks,
Sam
> On 9 Ja
, Jolokia ships with
its own policy-based method of configuring access controls. I haven't looked
into it too much, but I think it would be possible to duplicate the
functionality of Cassandra's built-in auth with a custom Jolokia Restrictor.
Thanks,
Sam
> On 16 Dec 2018, at 05:21,
+1 Thanks for articulating that so well Josh.
Sam
> On 12 Apr 2019, at 16:19, Blake Eggleston
> wrote:
>
> Well said Josh. You’ve pretty much summarized my thoughts on this as well.
>
> +1 to moving forward with this
>
>> On Apr 11, 2019, at 10:15 PM, Joshua McK
+1
> On 14 May 2019, at 20:10, Benedict Elliott Smith wrote:
>
> It will be possible to insert n/a. It will simply be a text field - Jira
> doesn’t know anything about the concept of a SHA, and I don’t intend to
> introduce validation logic. It’s just a logical and consistent place for it
with those removed, it’s just a matter of having the
appropriate target jdk specified in $JAVA_HOME (and using -Duse.jdk11=true or
$CASSANDRA_USE_JDK11=true if building with jdk11).
We’ll fix this in trunk, but in the meantime removing those conditions should
unblock you.
Thanks,
Sam
>
> I als
It would also be good to include CASSANDRA-15193 (which I only just created,
sorry), as the counterpart to CASSANDRA-15176. I have a patch for this mostly
done and will post it in the next day or two.
> On 2 Jul 2019, at 07:13, Mick Semb Wever wrote:
>
>> It would be nice to have time to get C
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.
>
>
CASSANDRA-15193 just got +1’d yesterday and would be good to include in the 3.0
and 3.11 releases. If you don’t mind holding off while I add a cqlsh test and
merge it, that’d be good.
Thanks,
Sam
> On 7 Oct 2019, at 22:54, Michael Shuler wrote:
>
> Will do! I probably won't
+1
> On 24 Oct 2019, at 18:26, Michael Shuler wrote:
>
> I propose the following artifacts for release as 4.0-alpha2.
>
> sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative
> Artifacts:
> http
+1
> On 24 Oct 2019, at 18:26, Michael Shuler wrote:
>
> I propose the following artifacts for release as 3.11.5.
>
> sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.5-tentative
> Artifacts:
> https://repo
+1
> On 24 Oct 2019, at 18:25, Michael Shuler wrote:
>
> I propose the following artifacts for release as 2.2.15.
>
> sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative
> Artifacts:
> https://repo
+1
> On 24 Oct 2019, at 18:25, Michael Shuler wrote:
>
> I propose the following artifacts for release as 3.0.19.
>
> sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.19-tentative
> Artifacts:
> https://repo
+1
Sam
> On 23 Mar 2020, at 09:36, Oleksandr Petrov wrote:
>
> Thanks to everyone who participated in the previous vote, I appreciate your
> feedback.
>
> @Mick, thank you for sending a patch and helping to figure out the release
> procedure and specifics.
>
> Pro
+1
> On 8 Apr 2020, at 15:08, Mick Semb Wever wrote:
>
> Can we agree on keeping such test changes out of CHANGES.txt ?
>
> We already don't put entries into CHANGES.txt if it is not a change
> from any previous release.
>
> There was some discussion before¹ about this, and the problem that
>
+1
> On 15 Apr 2020, at 14:35, Oleksandr Petrov wrote:
>
> Hi everyone,
>
> Apache release rules were made for first-class projects. I would like to
> propose simplifying voting rules for in-jvm-dtest-api project [1].
>
> A bit of background: in-jvm-dtest-api is a project that is used by all
>
Me too.
> On 11 May 2020, at 20:23, Jake Luciani wrote:
>
> Happy to lend a hand
>
> On Mon, May 11, 2020 at 3:12 PM Eric Evans
> wrote:
>
>> I can take a turn.
>>
>> On Fri, May 8, 2020 at 11:10 AM Vinay Chella
>> wrote:
>>>
>>> I would like to help as well.
>>>
>>>
>>> On Fri, May 8, 2
> I have the feeling that the thing that prevents us primarily from
cutting beta at the moment is flaky tests
CASSANDRA-15299 is still in progress and I think we have to consider it a
blocker, given that beta "should be interface-stable, so that consumers do not
have to incur any code changes on
days, and in this stage of the feature freeze, with
> so few alpha bugs remaining, that's a long time. Sam, can you speak to its
> eta?
That is way too long without any visible progress and I apologise for the radio
silence. I have a rather small amount of tidying up to do, but otherwis
+1 (binding)
> On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
>
> +1 nb
>
> On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
>
>> +1 (binding)
>>
>> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
>> wrote:
>>
>>> Added unratified draft to the wiki here:
>>>
>>>
>> https://cwiki.a
+1
> On 22 Jun 2020, at 08:54, Sylvain Lebresne wrote:
>
> +1
> --
> Sylvain
>
>
> On Mon, Jun 22, 2020 at 9:48 AM Benjamin Lerer
> wrote:
>
>> +1
>>
>> On Mon, Jun 22, 2020 at 8:54 AM Marcus Eriksson
>> wrote:
>>
>>> +1
>>>
>>>
>>> On 22 June 2020 at 08:37:39, Mick Semb Wever (m...@apa
+1
> On 24 Jul 2020, at 12:07, Mick Semb Wever wrote:
>
>> Proposing the test build of Cassandra 2.2.17 for release.
>>
>> sha1: cd006d275aa9b6e937c6ebd036d4d27c4ed18dbe
>
>
> +1 (binding)
>
>
> Test Results:
> https://ci-cassandra.apache.org/job/Cassandra-2.2/28/testReport/
>
>
> Check
+1
> On 28 Aug 2020, at 15:18, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0-beta2 for release.
>
> sha1: 56eadf2004399a80f0733041cacf03839832249a
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta2-tentative
> Maven Artifacts:
>
+1
> On 28 Aug 2020, at 14:09, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 3.0.22 for release.
>
> sha1: 45331bb612dc7847efece7e26cdd0b376bd11249
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.22-tentative
> Maven Artifacts:
> https:
+1
> On 28 Aug 2020, at 13:44, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 2.2.18 for release.
>
> sha1: d4938cf4e488a9ef3ac48164a3e946f16255d721
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.18-tentative
> Maven Artifacts:
> https:
+1
> On 28 Aug 2020, at 14:37, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 3.11.8 for release.
>
> sha1: 8b29b698630960a0ebb2c695cc5b21dee4686d09
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.8-tentative
> Maven Artifacts:
> https:
+1
> On 28 Aug 2020, at 16:42, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 2.1.22 for release.
>
> sha1: 94e9149c22f6a7772c0015e1b1ef2e2961155c0a
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.22-tentative
> Maven Artifacts:
> https:
CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
Versions Affected:
All versions prior to: 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2
Description:
It is possible for a local attacker without access to the Apache Cassandra
process or configuration files to manipulate the RMI registry to
+1
> On 2 Sep 2020, at 09:03, Benjamin Lerer wrote:
>
> +1
>
>
>
> On Wed, Sep 2, 2020 at 5:36 AM Berenguer Blasi
> wrote:
>
>> +1
>>
>> On 2/9/20 5:09, Joshua McKenzie wrote:
>>> +1
>>>
>>> On Tue, Sep 1, 2020 at 6:26 PM Jordan West wrote:
>>>
+1
On Tue, Sep 1, 2020 at
+1
> On 16 Sep 2020, at 11:07, Benjamin Lerer wrote:
>
> +1
>
> On Wed, Sep 16, 2020 at 12:00 PM Mick Semb Wever wrote:
>
>>> Please cast your votes:
>>> [ ] +1 Accept the contribution into Cassandra
>>> [ ] -1 Do not
>>>
>>
>>
>> +1
>>
--
+1
> On 25 Sep 2020, at 15:45, Oleksandr Petrov wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.5 for release.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.5
> Candidate SHA:
> https://github.com/apache/cassandra-i
ailing and flakey upgrade dtests
> ** Reports from driver tests, and other external test systems
> ** Reports and/or integration with Fallout and Harry
>
>
> In a bit more detail…
>
>
> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
> compression
, but changing externally facing stuff at this point is not ideal.
The changes I plan to make are here:
https://github.com/beobal/cassandra/commit/3cb8cf5366a71b4a00a208716d09b4c9c9bd0544
If nobody objects, I'll go ahead and include this commit when 15299 finishes
review, which hopefully isn&#x
evelopment
(CASSANDRA-14973).
If there are no objections, I'll file a JIRA for 3.11.x and post a patch
shortly.
Thanks,
Sam
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands
void this
> issue?
>
> On 08/12/2020, 10:53, "Sam Tunnicliffe" wrote:
>
>CASSANDRA-15299 has revised the wire format of CQL native protocol to add
> a framing layer around the existing CQL messages. This is targetted at
> protocol v5, which is (still) cu
> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti
> wrote:
>
> +1 to moving v5-beta changes in trunk to new protocol v6.
>
> Regarding 3.11 and v5, I suppose we could say, v5 could never get matured
> beyond beta, but not sure if it would be confusing to see v6 while v5 is
> still in beta (curio
.atlassian.net/browse/PYTHON-1232
[3] https://datastax-oss.atlassian.net/browse/JAVA-2704
[4] https://datastax-oss.atlassian.net/browse/JAVA-2705
> On 9 Dec 2020, at 11:02, Sam Tunnicliffe wrote:
>
>
>
>> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti
>> wrote:
>>
>
> What's the verdict now for CASSANDRA-14973 ?
My aim is to have a C* patch and PRs for the python and java drivers this week,
but really there's nothing to block cutting a new C* beta now (or whenever
we're ready).
> On 15 Dec 2020, at 15:39, Mick Semb Wever wrote:
>
>>
>> To use a beta fla
> On 17 Dec 2020, at 10:54, Michael Semb Wever wrote:
>
>
>> I propose to:
>>
>> - update the documentation to clarify the meaning of the fix version as
>> 'The version in which the item must be fixed' (e.g 4.0-beta if the ticket
>> must be fixed in a beta release)
>> - create a 4.0-
+1
> On 29 Jan 2021, at 12:50, Oleksandr Petrov wrote:
>
> Proposing the test build of Cassandra 3.11.10 for release.
>
> sha1: 181a4969290f1c756089b2993a638fe403bc1314
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.10-tentative
> Maven Artifacts:
> htt
+1
> On 29 Jan 2021, at 13:21, Oleksandr Petrov wrote:
>
>> Proposing the test build of Cassandra 4.0-beta4 for release.
>
> Correction: test build of 3.0.24. The rest looks right.
>
> On Fri, Jan 29, 2021 at 1:48 PM Oleksandr Petrov
> wrote:
>
>> Proposing the test build of Cassandra 4.0-be
+1 to both the yearly cadence and the periodic publishing of bleeding edge
snapshots.
> On 5 Feb 2021, at 16:14, Benedict Elliott Smith wrote:
>
> +1
>
> +1 also to mixing this with an experiment on regular "releasable" (without
> API stability) snapshots from trunk.
>
> On 05/02/2021, 16:0
Hi folks,
I have a question about a design choice on how expiring cells are
reconciled with tombstones. For two cells with the same timestamp, if
one is expiring and one is a tombstone, Cassandra *always* prefers the
tombstone. This matches its behavior for normal/non-expiring cells, but
the fol
> could result in that, but not much else.
>
>
> On Wed, Jun 17, 2015 at 10:05 AM, Josef Lindman Hörnlund
> wrote:
>
>>
>> Hello Sam,
>>
>> This is not answering your direct question but if you worry about clock
>> skew take a loo
ive) around minor-ish things like naming, nits
and so forth. At the moment these are a) not recorded & b) marginally more
difficult to do asynchronously. So I think in future I may personally start
using a GH branch for such remarks, though I don't think that should become
a mandated part of Th
+1
On Sat, 22 Aug 2015 04:15 Jake Luciani wrote:
> I propose the following artifacts for release as 3.0.0-beta1.
>
> sha1: 356c755a3b7aa1c71f72cf81fbe810670bd71de7
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-beta1-tentative
> Artifacts:
>
> http
+1
On 19 Sep 2015 21:42, "Jake Luciani" wrote:
> I propose the following artifacts for release as 3.0.0-rc1.
>
> sha1: c95a7098cf77b5b8e96feb7c39aca8fec3a02f9c
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-rc1-tentative
> Artifacts:
>
> https://rep
+1
On 4 Dec 2015 22:07, "Jake Luciani" wrote:
> I propose the following artifacts for release as 3.1.
>
> sha1: e092873728dc88aebc6ee10153b9bd3cd90cd858
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.1-tentative
> Artifacts:
>
> https://repository.apach
+1
I propose the following artifacts for release as 3.0.1.
sha1: cf567703db2cc6859731405322f19f55345b5c57
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.1-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1092/org/apa
+1
On Fri, Jan 8, 2016 at 9:12 PM, Jake Luciani wrote:
> I propose the following artifacts for release as 3.2.
>
> sha1: 3c6dfa4aa0b9ffb0a48a02b949bff2a8406764e6
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2-tentative
> Artifacts:
>
> https://reposi
+1
On Fri, Jan 15, 2016 at 3:03 AM, Jake Luciani wrote:
> I propose the following artifacts for release as 3.2.1.
>
> sha1: 2ac95bd6c5699a605e6f4256cb17b016c99e6dda
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2.1-tentative
> Artifacts:
>
> https://r
+1
On Wed, Feb 3, 2016 at 1:44 PM, Jake Luciani wrote:
> I propose the following artifacts for release as 2.1.13.
>
> sha1: d5b6d1b634f69709d2b3caa17cba52696ed2033d
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.13-tentative
> Artifacts:
>
> https://
+1
On Wed, Feb 3, 2016 at 1:51 PM, Jake Luciani wrote:
> I propose the following artifacts for release as 2.2.5.
>
> sha1: dd76858c7652541c7b137323f7b9e154686d6fba
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.5-tentative
> Artifacts:
>
> https://re
+1
On Sat, Feb 6, 2016 at 3:11 AM, Jake Luciani wrote:
> I propose the following artifacts for release as 3.3.
>
> sha1: 5669c6967bbdd540f27aeebf5a2c258bc4defbe3
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.3-tentative
> Artifacts:
>
> https://reposi
You might find o.a.c.i.StubIndex in the test source tree useful.
On 6 Mar 2016 19:24, "Henry Manasseh" wrote:
> Hello,
> I was wondering if anyone is aware of a minimal reference implementation
> for a java class implementing a secondary index or some documentation of
> the interface(s) I would n
have checked the only two calls to Indexer.removeRows in
> o.a.c.index.SecondaryIndexManager.IndexGCTransaction.commit in the
> followings releases and it seems that has not changed at all.
>
> Sam Tunnicliffe, any ideas about this??
>
> Regards
>
>
> Eduardo Alonso
> Vía de las dos Cast
+1
On Wed, May 11, 2016 at 9:51 AM, Aleksey Yeschenko
wrote:
> +1
>
> --
> AY
>
> On 11 May 2016 at 02:55:11, Jake Luciani (j...@apache.org) wrote:
>
> I propose the following artifacts for release as 3.0.6.
>
> sha1: 52447873a361647a5e80c547adea9cf5ee85254a
> Git:
>
> http://git-wip-us.apache.o
1 - 100 of 185 matches
Mail list logo
