Re: [VOTE] Release Apache Cassandra 3.0.26

[Marcus Eriksson]

+1

On Mon, Feb 07, 2022 at 03:14:15PM +0100, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 3.0.26 for release.
> 
> sha1: b18adcba1a808cf77576905dc2ceccd7783bdb18
> 
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentative
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.26/
> 
> 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]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.26-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative

Re: [VOTE] Release Apache Cassandra 4.0.2

[Marcus Eriksson]

+1

On Mon, Feb 07, 2022 at 03:14:36PM +0100, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0.2 for release.
> 
> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
> 
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
> 
> 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]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

Re: [VOTE] Release Apache Cassandra 3.11.12

[Marcus Eriksson]

+1

On Mon, Feb 07, 2022 at 03:14:25PM +0100, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 3.11.12 for release.
> 
> sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa
> 
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/
> 
> 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]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative

Re: [VOTE] Release Apache Cassandra 4.0.2

[Brandon Williams]

+1. Smoke tested debs and rpms, unit tests passed.

On Mon, Feb 7, 2022 at 8:15 AM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 4.0.2 for release.
>
> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
>
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
>
> 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]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

Re: [VOTE] Release Apache Cassandra 3.0.26

[Mick Semb Wever]

+1


Checked
- signing correct
- checksums are correct
- source artefact builds
- binary artefact runs
- debian package runs
- redhat package runs

( used https://github.com/apache/cassandra-builds/pull/32 )


On Tue, 8 Feb 2022 at 11:12, Marcus Eriksson  wrote:

> +1
>
> On Mon, Feb 07, 2022 at 03:14:15PM +0100, Mick Semb Wever wrote:
> > Proposing the test build of Cassandra 3.0.26 for release.
> >
> > sha1: b18adcba1a808cf77576905dc2ceccd7783bdb18
> >
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentative
> >
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/3.0.26/
> >
> > 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]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.26-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative
>

Re: [VOTE] Release Apache Cassandra 3.11.12

[Mick Semb Wever]

+1


Checked
- signing correct
- checksums are correct
- source artefact builds
- binary artefact runs
- debian package runs
- redhat package runs

( used https://github.com/apache/cassandra-builds/pull/32 )



On Tue, 8 Feb 2022 at 11:13, Marcus Eriksson  wrote:

> +1
>
> On Mon, Feb 07, 2022 at 03:14:25PM +0100, Mick Semb Wever wrote:
> > Proposing the test build of Cassandra 3.11.12 for release.
> >
> > sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa
> >
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative
> >
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/
> >
> > 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]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative
>

Re: [VOTE] Release Apache Cassandra 4.0.2

[Mick Semb Wever]

+1


Checked
- signing correct
- checksums are correct
- source artefact builds
- binary artefact runs
- debian package runs
- redhat package runs

( used https://github.com/apache/cassandra-builds/pull/32 )



On Tue, 8 Feb 2022 at 11:12, Marcus Eriksson  wrote:

> +1
>
> On Mon, Feb 07, 2022 at 03:14:36PM +0100, Mick Semb Wever wrote:
> > Proposing the test build of Cassandra 4.0.2 for release.
> >
> > sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
> >
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
> >
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
> >
> > 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]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative
>

Re: [VOTE] release cassandra-harry 0.0.1

[Brandon Williams]

+1

On Mon, Feb 7, 2022 at 8:44 AM Alex Petrov  wrote:
>
> Proposing the test build of cassandra-harry 0.0.1 for release, to start using 
> it in Cassandra tree.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.1
>
> Candidate SHA:
> https://github.com/apache/cassandra-harry/commit/40fb37ec8a4f08dc6a258a50cbdeab92e2894266
> tagged with 0.0.1
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1257/org/apache/cassandra/
>
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>
> This is a first release of harry-core, but you can read more about its 
> integration with Cassandra in CASSANDRA-16262:
>
> The vote will be open for 24 hours. 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.

Re: [VOTE] release cassandra-harry 0.0.1

[C. Scott Andreas]

+1nb

> On Feb 8, 2022, at 4:18 AM, Brandon Williams  wrote:
> 
> +1
> 
>> On Mon, Feb 7, 2022 at 8:44 AM Alex Petrov  wrote:
>> 
>> Proposing the test build of cassandra-harry 0.0.1 for release, to start 
>> using it in Cassandra tree.
>> 
>> Repository:
>> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.1
>> 
>> Candidate SHA:
>> https://github.com/apache/cassandra-harry/commit/40fb37ec8a4f08dc6a258a50cbdeab92e2894266
>> tagged with 0.0.1
>> 
>> Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1257/org/apache/cassandra/
>> 
>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>> 
>> This is a first release of harry-core, but you can read more about its 
>> integration with Cassandra in CASSANDRA-16262:
>> 
>> The vote will be open for 24 hours. 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.

Re: [VOTE] release cassandra-harry 0.0.1

[Caleb Rackliffe]

+1

On Mon, Feb 7, 2022 at 8:44 AM Alex Petrov  wrote:

> Proposing the test build of cassandra-harry 0.0.1 for release, to start
> using it in Cassandra tree.
>
> Repository:
>
> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.1
>
> Candidate SHA:
>
> https://github.com/apache/cassandra-harry/commit/40fb37ec8a4f08dc6a258a50cbdeab92e2894266
> tagged with 0.0.1
>
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1257/org/apache/cassandra/
>
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>
> This is a first release of harry-core, but you can read more about its
> integration with Cassandra in CASSANDRA-16262:
>
> The vote will be open for 24 hours. 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.
>

Re: [VOTE] release cassandra-harry 0.0.1

[abe]

+1

Re: [VOTE] Release Apache Cassandra 4.0.2

[Jeremiah D Jordan]

-1 nb

So we just voted on an approved the CI process page recently:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 


Where we said:
"All releases by default are expected to have a green test run on 
ci-cassandra.apache.org Jenkins. In exceptional circumstances (security 
incidents, data loss, etc requiring hotfix), members with binding votes on a 
release may choose to approve a release with known failing tests.”

I do not see green CI runs recently for 4.0. 
https://ci-cassandra.apache.org/job/Cassandra-4.0/ 


If we are making this release for a security incident/data loss/hot fix reason, 
then I would expect to see the related change set only containing those 
patches.  But the change set in the tag here the latest 4.0-dev commits.

Do we want to be violating our goal of only releasing with green CI less than a 
month after the vote?

-Jeremiah Jordan

> On Feb 7, 2022, at 8:14 AM, Mick Semb Wever  wrote:
> 
> Proposing the test build of Cassandra 4.0.2 for release.
> 
> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
> 
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>  
> 
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
>  
> 
> 
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/ 
> 
> 
> 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]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
>  
> 
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative
>  
> 

Re: [DISCUSS] CEP-19: Trie memtable implementation

[Dinesh Joshi]

Thank you for sharing the perf test results.

Going back to the schema vs yaml configuration. I am concerned users may pick 
the wrong implementation for their use-case. Is there any chance for us to 
automatically pick a MemTable implementation based on heuristics? Do we foresee 
users ever picking the existing SkipList implementation over the Trie Given the 
performance tests, it seems the Trie implementation is the clear winner.

To be clear, I am not suggesting we remove the existing implementation. I am 
for maintaining a pluggable API for various components.

Dinesh

> On Feb 7, 2022, at 8:39 AM, Branimir Lambov  wrote:
> 
> Added some performance results to the ticket: 
> https://issues.apache.org/jira/browse/CASSANDRA-17240 
> 
> 
> Regards,
> Branimir
> 
> On Sat, Feb 5, 2022 at 10:59 PM Dinesh Joshi  > wrote:
> This is excellent. Thanks for opening up this CEP. It would be great to get 
> some stats around GC allocation rate / memory pressure, read & write 
> latencies, etc. compared to existing implementation.
> 
> Dinesh
> 
>> On Jan 18, 2022, at 2:13 AM, Branimir Lambov > > wrote:
>> 
>> The memtable pluggability API (CEP-11) is per-table to enable memtable 
>> selection that suits specific workflows. It also makes full sense to permit 
>> per-node configuration, both to be able to modify the configuration to suit 
>> heterogeneous deployments better, as well as to test changes for 
>> improvements such as this one.
>> Recognizing this, the patch comes with a modification to the API 
>> 
>>  that defines memtable templates in cassandra.yaml (i.e. per node) and 
>> allows the schema to select a template (in addition to being able to specify 
>> the full memtable configuration). One could use this e.g. by adding:
>> memtable_templates:
>> trie:
>> class: TrieMemtable
>> shards: 16
>> skiplist:
>> class: SkipListMemtable
>> memtable:
>> template: skiplist
>> (which defines two templates and specifies the default memtable 
>> implementation to use) to cassandra.yaml and specifying  WITH memtable = 
>> {'template' : 'trie'} in the table schema.
>> 
>> I intend to commit this modification with the memtable API 
>> (CASSANDRA-17034/CEP-11).
>> 
>> Performance comparisons will be published soon.
>> 
>> Regards,
>> Branimir
>> 
>> On Fri, Jan 14, 2022 at 4:15 PM Jeff Jirsa > > wrote:
>> Sounds like a great addition
>> 
>> Can you share some of the details around gc and latency improvements you’ve 
>> observed with the list? 
>> 
>> Any specific reason the confirmation is through schema vs yaml? Presumably 
>> it’s so a user can test per table, but this changes every host in a cluster, 
>> so the impact of a bug/regression is much higher. 
>> 
>> 
>>> On Jan 10, 2022, at 1:30 AM, Branimir Lambov >> > wrote:
>>> 
>>> 
>>> We would like to contribute our TrieMemtable to Cassandra. 
>>> 
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
>>>  
>>> 
>>> 
>>> This is a new memtable solution aimed to replace the legacy implementation, 
>>> developed with the following objectives:
>>> - lowering the on-heap complexity and the ability to store memtable 
>>> indexing structures off-heap,
>>> - leveraging byte order and a trie structure to lower the memory footprint 
>>> and improve mutation and lookup performance.
>>> 
>>> The new memtable relies on CASSANDRA-6936 to translate to and from 
>>> byte-ordered representations of types, and CASSANDRA-17034 / CEP-11 to plug 
>>> into Cassandra. The memtable is built on multiple shards of custom 
>>> in-memory single-writer multiple-reader tries, whose implementation uses a 
>>> combination of state-of-the-art and novel features for greater efficiency.
>>> 
>>> The CEP's JIRA ticket 
>>> (https://issues.apache.org/jira/browse/CASSANDRA-17240 
>>> ) contains the 
>>> initial version of the implementation. In its current form it achieves much 
>>> better garbage collection latency, significantly bigger data sizes between 
>>> flushes for the same memory allocation, as well as drastically increased 
>>> write throughput, and we expect the memory and garbage collection 
>>> improvements to go much further with upcoming improvements to the solution.
>>> 
>>> I am interested in hearing your thoughts on the proposal.
>>> 
>>> Regards,
>>> Branimir
>>> 
> 

Re: [VOTE] Release Apache Cassandra 3.0.26

[Jeremiah D Jordan]

-1 nb for same reason as I said for the 4.0.2 vote here: 
https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr 

 

> On Feb 8, 2022, at 6:15 AM, Mick Semb Wever  wrote:
> 
> 
> +1
> 
> 
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds
> - binary artefact runs
> - debian package runs
> - redhat package runs
> 
> ( used https://github.com/apache/cassandra-builds/pull/32 
>  )
> 
> 
> On Tue, 8 Feb 2022 at 11:12, Marcus Eriksson  > wrote:
> +1
> 
> On Mon, Feb 07, 2022 at 03:14:15PM +0100, Mick Semb Wever wrote:
> > Proposing the test build of Cassandra 3.0.26 for release.
> > 
> > sha1: b18adcba1a808cf77576905dc2ceccd7783bdb18
> > 
> > Git:
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentative
> >  
> > 
> > 
> > Maven Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/
> >  
> > 
> > 
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/3.0.26/ 
> > 
> > 
> > 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]: CHANGES.txt:
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.26-tentative
> >  
> > 
> > [2]: NEWS.txt:
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative
> >  
> > 

Re: [VOTE] Release Apache Cassandra 3.11.12

[Jeremiah D Jordan]

-1 nb for same reason as I said for the 4.0.2 vote here: 
https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr 



> On Feb 8, 2022, at 4:10 AM, Dorian ROSSE  wrote:
> 
> Hello Scott,
> 
> 
> Yours links should work but thoses aren't the link shared by Mick,
> 
> As you see in attachment,
> 
> Regards.
> 
> 
> Dorian Rosse.
> 
> De : C. Scott Andreas 
> Envoyé : mardi 8 février 2022 à 00:30
> À : dev@cassandra.apache.org
> Cc : dev
> Objet : Re: [VOTE] Release Apache Cassandra 3.11.12
> 
> Hi Dorian,
> 
> I see that the following download URLs appear to work fine for me and result 
> in the tarballs being downloaded as expected.
> 
> – 
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/apache-cassandra-3.11.12-src.tar.gz
>  
> 
> – 
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gz
>  
> 
> 
> As Alex mentioned, to help the community debug and ensure a high quality 
> release - in a JIRA ticket, could you please share specific steps to 
> reproduce the issues you're encountering as well as any error messages you 
> receive?
> 
> We would like to resolve these concerns as quickly as possible.
> 
> Thanks,
> 
> – Scott
> 
>> On Feb 7, 2022, at 1:11 PM, Dorian ROSSE  wrote:
>> 
>> 
>> -1 I don't success to download it I fall on index.html
>> 
>>  
>> De : Mick Semb Wever 
>> Envoyé : lundi 7 février 2022 15:14
>> À : dev 
>> Objet : [VOTE] Release Apache Cassandra 3.11.12
>>  
>> Proposing the test build of Cassandra 3.11.12 for release.
>> 
>> sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa
>> 
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative
>>  
>> 
>> 
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/
>>  
>> 
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available 
>> here:https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/ 
>> 
>> 
>> 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]: CHANGES.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
>>  
>> 
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative
>>  
>> 
> 
> 
> 
> 

Re: [DISCUSS] CEP-19: Trie memtable implementation

[bened...@apache.org]

FWIW, I think the proposed approach to configuration is fine.

I think selecting a choice for the user should be done simply and 
deterministically. We should probably default to Trie based memtables for users 
with a fresh config file, and we can consider changing the default in a later 
release for those with an old config file that does not specify an 
implementation.


From: Dinesh Joshi 
Date: Tuesday, 8 February 2022 at 20:21
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] CEP-19: Trie memtable implementation
Thank you for sharing the perf test results.

Going back to the schema vs yaml configuration. I am concerned users may pick 
the wrong implementation for their use-case. Is there any chance for us to 
automatically pick a MemTable implementation based on heuristics? Do we foresee 
users ever picking the existing SkipList implementation over the Trie Given the 
performance tests, it seems the Trie implementation is the clear winner.

To be clear, I am not suggesting we remove the existing implementation. I am 
for maintaining a pluggable API for various components.

Dinesh


On Feb 7, 2022, at 8:39 AM, Branimir Lambov 
mailto:blam...@apache.org>> wrote:

Added some performance results to the ticket: 
https://issues.apache.org/jira/browse/CASSANDRA-17240

Regards,
Branimir

On Sat, Feb 5, 2022 at 10:59 PM Dinesh Joshi 
mailto:djo...@apache.org>> wrote:
This is excellent. Thanks for opening up this CEP. It would be great to get 
some stats around GC allocation rate / memory pressure, read & write latencies, 
etc. compared to existing implementation.

Dinesh


On Jan 18, 2022, at 2:13 AM, Branimir Lambov 
mailto:blam...@apache.org>> wrote:

The memtable pluggability API (CEP-11) is per-table to enable memtable 
selection that suits specific workflows. It also makes full sense to permit 
per-node configuration, both to be able to modify the configuration to suit 
heterogeneous deployments better, as well as to test changes for improvements 
such as this one.
Recognizing this, the patch comes with a modification to the 
API
 that defines memtable templates in cassandra.yaml (i.e. per node) and allows 
the schema to select a template (in addition to being able to specify the full 
memtable configuration). One could use this e.g. by adding:

memtable_templates:
trie:
class: TrieMemtable
shards: 16
skiplist:
class: SkipListMemtable
memtable:
template: skiplist
(which defines two templates and specifies the default memtable implementation 
to use) to cassandra.yaml and specifying  WITH memtable = {'template' : 'trie'} 
in the table schema.

I intend to commit this modification with the memtable API 
(CASSANDRA-17034/CEP-11).

Performance comparisons will be published soon.

Regards,
Branimir

On Fri, Jan 14, 2022 at 4:15 PM Jeff Jirsa 
mailto:jji...@gmail.com>> wrote:
Sounds like a great addition

Can you share some of the details around gc and latency improvements you’ve 
observed with the list?

Any specific reason the confirmation is through schema vs yaml? Presumably it’s 
so a user can test per table, but this changes every host in a cluster, so the 
impact of a bug/regression is much higher.



On Jan 10, 2022, at 1:30 AM, Branimir Lambov 
mailto:blam...@apache.org>> wrote:

We would like to contribute our TrieMemtable to Cassandra.

https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation

This is a new memtable solution aimed to replace the legacy implementation, 
developed with the following objectives:
- lowering the on-heap complexity and the ability to store memtable indexing 
structures off-heap,
- leveraging byte order and a trie structure to lower the memory footprint and 
improve mutation and lookup performance.

The new memtable relies on CASSANDRA-6936 to translate to and from byte-ordered 
representations of types, and CASSANDRA-17034 / CEP-11 to plug into Cassandra. 
The memtable is built on multiple shards of custom in-memory single-writer 
multiple-reader tries, whose implementation uses a combination of 
state-of-the-art and novel features for greater efficiency.

The CEP's JIRA ticket (https://issues.apache.org/jira/browse/CASSANDRA-17240) 
contains the initial version of the implementation. In its current form it 
achieves much better garbage collection latency, significantly bigger data 
sizes between flushes for the same memory allocation, as well as drastically 
increased write throughput, and we expect the memory and garbage collection 
improvements to go much further with upcoming improvements to the solution.

I am interested in hearing your thoughts on the proposal.

Regards,
Branimir

Re: [DISCUSS] CEP-19: Trie memtable implementation

[Jeremiah D Jordan]

I don’t really see most users touching the default implementation.  I would 
expect the main reason someone would change would be
1. They run into some bug that is only in one of the implementations.
2. They have persistent memory and so want to use 
https://issues.apache.org/jira/browse/CASSANDRA-13981 


Given that I doubt most people will touch it, I think it is good to give 
advanced operators the ability to have more control over switching to things 
that have new performance characteristics.  So I like the idea that the 
proposed configuration approach which allows someone to change to a new 
implementation one node at a time and only for specific tables.

> On Feb 8, 2022, at 2:21 PM, Dinesh Joshi  wrote:
> 
> Thank you for sharing the perf test results.
> 
> Going back to the schema vs yaml configuration. I am concerned users may pick 
> the wrong implementation for their use-case. Is there any chance for us to 
> automatically pick a MemTable implementation based on heuristics? Do we 
> foresee users ever picking the existing SkipList implementation over the Trie 
> Given the performance tests, it seems the Trie implementation is the clear 
> winner.
> 
> To be clear, I am not suggesting we remove the existing implementation. I am 
> for maintaining a pluggable API for various components.
> 
> Dinesh
> 
>> On Feb 7, 2022, at 8:39 AM, Branimir Lambov > > wrote:
>> 
>> Added some performance results to the ticket: 
>> https://issues.apache.org/jira/browse/CASSANDRA-17240 
>> 
>> 
>> Regards,
>> Branimir
>> 
>> On Sat, Feb 5, 2022 at 10:59 PM Dinesh Joshi > > wrote:
>> This is excellent. Thanks for opening up this CEP. It would be great to get 
>> some stats around GC allocation rate / memory pressure, read & write 
>> latencies, etc. compared to existing implementation.
>> 
>> Dinesh
>> 
>>> On Jan 18, 2022, at 2:13 AM, Branimir Lambov >> > wrote:
>>> 
>>> The memtable pluggability API (CEP-11) is per-table to enable memtable 
>>> selection that suits specific workflows. It also makes full sense to permit 
>>> per-node configuration, both to be able to modify the configuration to suit 
>>> heterogeneous deployments better, as well as to test changes for 
>>> improvements such as this one.
>>> Recognizing this, the patch comes with a modification to the API 
>>> 
>>>  that defines memtable templates in cassandra.yaml (i.e. per node) and 
>>> allows the schema to select a template (in addition to being able to 
>>> specify the full memtable configuration). One could use this e.g. by adding:
>>> memtable_templates:
>>> trie:
>>> class: TrieMemtable
>>> shards: 16
>>> skiplist:
>>> class: SkipListMemtable
>>> memtable:
>>> template: skiplist
>>> (which defines two templates and specifies the default memtable 
>>> implementation to use) to cassandra.yaml and specifying  WITH memtable = 
>>> {'template' : 'trie'} in the table schema.
>>> 
>>> I intend to commit this modification with the memtable API 
>>> (CASSANDRA-17034/CEP-11).
>>> 
>>> Performance comparisons will be published soon.
>>> 
>>> Regards,
>>> Branimir
>>> 
>>> On Fri, Jan 14, 2022 at 4:15 PM Jeff Jirsa >> > wrote:
>>> Sounds like a great addition
>>> 
>>> Can you share some of the details around gc and latency improvements you’ve 
>>> observed with the list? 
>>> 
>>> Any specific reason the confirmation is through schema vs yaml? Presumably 
>>> it’s so a user can test per table, but this changes every host in a 
>>> cluster, so the impact of a bug/regression is much higher. 
>>> 
>>> 
 On Jan 10, 2022, at 1:30 AM, Branimir Lambov >>> > wrote:
 
 
 We would like to contribute our TrieMemtable to Cassandra. 
 
 https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
  
 
 
 This is a new memtable solution aimed to replace the legacy 
 implementation, developed with the following objectives:
 - lowering the on-heap complexity and the ability to store memtable 
 indexing structures off-heap,
 - leveraging byte order and a trie structure to lower the memory footprint 
 and improve mutation and lookup performance.
 
 The new memtable relies on CASSANDRA-6936 to translate to and from 
 byte-ordered representations of types, and CASSANDRA-17034 / CEP-11 to 
 plug into Cassandra. The memtable is built on multiple shards of custom 
 in-memory single-writer multiple-reader tries, whose implementation uses a 
 combination of state-of-the-art and novel features for greater efficien

Re: [DISCUSS] CEP-19: Trie memtable implementation

[Dinesh Joshi]

My quick reading of the code suggests that schema will override the operator's 
default preference in the YAML. In the event of a bug in the new 
implementation, there could be situation where the operator might need to 
override this via the YAML.

> On Feb 8, 2022, at 12:29 PM, Jeremiah D Jordan  
> wrote:
> 
> I don’t really see most users touching the default implementation.  I would 
> expect the main reason someone would change would be
> 1. They run into some bug that is only in one of the implementations.
> 2. They have persistent memory and so want to use 
> https://issues.apache.org/jira/browse/CASSANDRA-13981 
> 
> 
> Given that I doubt most people will touch it, I think it is good to give 
> advanced operators the ability to have more control over switching to things 
> that have new performance characteristics.  So I like the idea that the 
> proposed configuration approach which allows someone to change to a new 
> implementation one node at a time and only for specific tables.
> 
>> On Feb 8, 2022, at 2:21 PM, Dinesh Joshi > > wrote:
>> 
>> Thank you for sharing the perf test results.
>> 
>> Going back to the schema vs yaml configuration. I am concerned users may 
>> pick the wrong implementation for their use-case. Is there any chance for us 
>> to automatically pick a MemTable implementation based on heuristics? Do we 
>> foresee users ever picking the existing SkipList implementation over the 
>> Trie Given the performance tests, it seems the Trie implementation is the 
>> clear winner.
>> 
>> To be clear, I am not suggesting we remove the existing implementation. I am 
>> for maintaining a pluggable API for various components.
>> 
>> Dinesh
>> 
>>> On Feb 7, 2022, at 8:39 AM, Branimir Lambov >> > wrote:
>>> 
>>> Added some performance results to the ticket: 
>>> https://issues.apache.org/jira/browse/CASSANDRA-17240 
>>> 
>>> 
>>> Regards,
>>> Branimir
>>> 
>>> On Sat, Feb 5, 2022 at 10:59 PM Dinesh Joshi >> > wrote:
>>> This is excellent. Thanks for opening up this CEP. It would be great to get 
>>> some stats around GC allocation rate / memory pressure, read & write 
>>> latencies, etc. compared to existing implementation.
>>> 
>>> Dinesh
>>> 
 On Jan 18, 2022, at 2:13 AM, Branimir Lambov >>> > wrote:
 
 The memtable pluggability API (CEP-11) is per-table to enable memtable 
 selection that suits specific workflows. It also makes full sense to 
 permit per-node configuration, both to be able to modify the configuration 
 to suit heterogeneous deployments better, as well as to test changes for 
 improvements such as this one.
 Recognizing this, the patch comes with a modification to the API 
 
  that defines memtable templates in cassandra.yaml (i.e. per node) and 
 allows the schema to select a template (in addition to being able to 
 specify the full memtable configuration). One could use this e.g. by 
 adding:
 memtable_templates:
 trie:
 class: TrieMemtable
 shards: 16
 skiplist:
 class: SkipListMemtable
 memtable:
 template: skiplist
 (which defines two templates and specifies the default memtable 
 implementation to use) to cassandra.yaml and specifying  WITH memtable = 
 {'template' : 'trie'} in the table schema.
 
 I intend to commit this modification with the memtable API 
 (CASSANDRA-17034/CEP-11).
 
 Performance comparisons will be published soon.
 
 Regards,
 Branimir
 
 On Fri, Jan 14, 2022 at 4:15 PM Jeff Jirsa >>> > wrote:
 Sounds like a great addition
 
 Can you share some of the details around gc and latency improvements 
 you’ve observed with the list? 
 
 Any specific reason the confirmation is through schema vs yaml? Presumably 
 it’s so a user can test per table, but this changes every host in a 
 cluster, so the impact of a bug/regression is much higher. 
 
 
> On Jan 10, 2022, at 1:30 AM, Branimir Lambov  > wrote:
> 
> 
> We would like to contribute our TrieMemtable to Cassandra. 
> 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
>  
> 
> 
> This is a new memtable solution aimed to replace the legacy 
> implementation, developed with the following objectives:
> - lowering the on-heap complexity and the ability to store memtable 
> indexing structures off-heap,
> - leveraging byte order and a trie structure to l

Re: [DISCUSS] Non Coding Committers

[Patrick McFadin]

Sharan has done a good job shining a spotlight on something that has
created a weird bottleneck in the project. Docs and the Cassandra website
are all in-tree, but it takes somebody who probably isn't even working on
those things to commit any changes. Dinesh nailed it. It's silly. I'm sure
the PMC can come up with a reasonable solution that can be done quickly.
There are a lot of us that love this project that contribute in ways that
don't get compiled into a jar file. This is something that needs to be
solved for the sake of project velocity.

Patrick

On Sun, Feb 6, 2022 at 10:28 PM Mick Semb Wever  wrote:

>
> Thank you Sharan for sharing.
>
>
>> So here in Apache Cassandra I see there is a whole lot of activity
>> happening around the website, marketing, project promotion, blogs, social
>> media - these activities are all contributions to the project. If there are
>> contributions happening in the project that need a committer to action,
>> then it could make sense to consider having committers that are focussed
>> around the 'non coding' parts.
>>
>>
>>
>
> This is so true for us. We are spending a lot of extra time getting these
> non-code contributions across the finish line. The context switching and
> wait time involved in just one more handover, and often across time zones,
> is hurting. And regardless, totally agree we should be formally recognising
> the ongoing work that goes into these non-coding contributions.
>
>

Re: [DISCUSS] Non Coding Committers

[Lorina Poland]

+1 to this conversation, from a Docs wonk. :-)

On Tue, Feb 8, 2022 at 1:40 PM Patrick McFadin  wrote:

> Sharan has done a good job shining a spotlight on something that has
> created a weird bottleneck in the project. Docs and the Cassandra website
> are all in-tree, but it takes somebody who probably isn't even working on
> those things to commit any changes. Dinesh nailed it. It's silly. I'm sure
> the PMC can come up with a reasonable solution that can be done quickly.
> There are a lot of us that love this project that contribute in ways that
> don't get compiled into a jar file. This is something that needs to be
> solved for the sake of project velocity.
>
> Patrick
>
> On Sun, Feb 6, 2022 at 10:28 PM Mick Semb Wever  wrote:
>
>>
>> Thank you Sharan for sharing.
>>
>>
>>> So here in Apache Cassandra I see there is a whole lot of activity
>>> happening around the website, marketing, project promotion, blogs, social
>>> media - these activities are all contributions to the project. If there are
>>> contributions happening in the project that need a committer to action,
>>> then it could make sense to consider having committers that are focussed
>>> around the 'non coding' parts.
>>>
>>>
>>>
>>
>> This is so true for us. We are spending a lot of extra time getting these
>> non-code contributions across the finish line. The context switching and
>> wait time involved in just one more handover, and often across time zones,
>> is hurting. And regardless, totally agree we should be formally recognising
>> the ongoing work that goes into these non-coding contributions.
>>
>>

Re: [DISCUSS] CEP-7 Storage Attached Index

[Caleb Rackliffe]

Regarding SASI deprecation and removal, I think I'm on the same page as
Henrik. The grand glorious future involves getting to feature parity with
and then completely replacing legacy 2i and SASI, but the CEP need not
specify a hard timeline for this.

With respect to OR support, I'm actually completely on-board with shipping
a first version of SAI without it. It's possible significant improvements
to the query engine have been made since the last time I worked w/ the SAI
prototype, but disjunctions expose us to some additional risk. They would
absolutely add to our surface area for testing (correctness, performance,
etc.) Doing this in the context of holistic support for OR once SAI is off
the ground and has some traction isn't a bad plan.

I'd be interested to hear from Mike/Jason on the OR support topic, of
course.

On Mon, Feb 7, 2022 at 6:59 AM bened...@apache.org 
wrote:

> I don’t have a strong opinion about CEP-7 taking a hard dependency on any
> new CQL CEP, particularly from a point of view of first landing in the
> codebase.
>
>
>
>
>
> *From: *Henrik Ingo 
> *Date: *Monday, 7 February 2022 at 12:03
> *To: *dev@cassandra.apache.org 
> *Subject: *Re: [DISCUSS] CEP-7 Storage Attached Index
>
> Thanks Benjamin for reviewing and raising this.
>
>
>
> While I don't speak for the CEP authors, just some thoughts from me:
>
>
>
> On Mon, Feb 7, 2022 at 11:18 AM Benjamin Lerer  wrote:
>
> I would like to raise 2 points regarding the current CEP proposal:
>
>
>
> 1. There are mention of some target versions and of the removal of SASI
>
>
>
> At this point, we have not agreed on any version numbers and I do not feel
> that removing SASI should be part of the proposal for now.
>
> It seems to me that we should see first the adoption surrounding SAI
> before talking about deprecating other solutions.
>
>
>
>
>
> This seems rather uncontroversial. I think the CEP template and previous
> CEPs invite  the discussion on whether the new feature will or may replace
> an existing feature. But at the same time that's of course out of scope for
> the work at hand. I have no opinion one way or the other myself.
>
>
>
>
>
> 2. OR queries
>
>
>
> It is unclear to me if the proposal is about adding OR support only for
> SAI index or for other types of queries too.
>
> In the past, we had the nasty habit for CQL to provide only partialially
> implemented features which resulted in a bad user experience.
>
> Some examples are:
>
> * LIKE restrictions which were introduced for the need of SASI and were
> not never supported for other type of queries
>
> * IS NOT NULL restrictions for MATERIALIZED VIEWS that are not supported
> elsewhere
>
> * != operator only supported for conditional inserts or updates
>
> And there are unfortunately many more.
>
>
>
> We are currenlty slowly trying to fix those issue and make CQL a more
> mature language. By consequence, I would like that we change our way of
> doing things. If we introduce support for OR it should also cover all the
> other type of queries and be fully tested.
>
> I also believe that it is a feature that due to its complexity fully
> deserves its own CEP.
>
>
>
>
>
> The current code that would be submitted for review after the CEP is
> adopted, contains OR support beyond just SAI indexes. An initial
> implementation first targeted only such queries where all columns in a
> WHERE clause using OR needed to be backed by an SAI index. This was since
> extended to also support ALLOW FILTERING mode as well as OR with clustering
> key columns. The current implementation is by no means perfect as a general
> purpose OR support, the focus all the time was on implementing OR support
> in SAI. I'll leave it to others to enumerate exactly the limitations of the
> current implementation.
>
>
>
> Seeing that also Benedict supports your point of view, I would steer the
> conversation more into a project management perspective:
>
> * How can we advance CEP-7 so that the bulk of the SAI code can still be
> added to Cassandra, so that  users can benefit from this new index type,
> albeit without OR?
>
> * This is also an important question from the point of view that this is a
> large block of code that will inevitably diverged if it's not in trunk.
> Also, merging it to trunk will allow future enhancements, including the OR
> syntax btw, to happen against trunk (aka upstream first).
>
> * Since OR support nevertheless is a feature of SAI, it needs to be at
> least unit tested, but ideally even would be exposed so that it is possible
> to test on the CQL level. Is there some mechanism such as experimental
> flags, which would allow the SAI-only OR support to be merged into trunk,
> while a separate CEP is focused on implementing "proper" general purpose OR
> support? I should note that there is no guarantee that the OR CEP would be
> implemented in time for the next release. So the answer to this point needs
> to be something that doesn't violate the desire for good user experience.
>
>
>

Re: [VOTE] Release Apache Cassandra 4.0.2

[Joshua McKenzie]

I find myself agreeing with Jeremiah's sentiment here.

For example, we're asking people that are on 4.0.1 to make the difficult
choice between accepting the risk of whatever prompts an urgent release vs.
accepting the risk of potentially destabilizing their GA critical
infrastructure. The 4.0 line is regressing, at least from a CI perspective:
https://butler.cassandra.apache.org/#/ci/upstream/trend

I'm a -0 on this release as structured; given we discussed this exact
situation when we adopted the new procedures I personally accept us moving
forward right now and wouldn't block the release, but going forward I'd
like to see us cut hotfix releases based on the latest GA plus a minimal
patchset to address whatever urgent need a release is targeting so long as
CI is in a regressing state.


On Tue, Feb 8, 2022 at 3:18 PM Jeremiah D Jordan 
wrote:

> -1 nb
>
> So we just voted on an approved the CI process page recently:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
>
> Where we said:
> "All releases by default are expected to have a green test run on
> ci-cassandra.apache.org Jenkins. In exceptional circumstances (security
> incidents, data loss, etc requiring hotfix), members with binding votes
> on a release may choose to approve a release with known failing tests.”
>
> I do not see green CI runs recently for 4.0.
> https://ci-cassandra.apache.org/job/Cassandra-4.0/
>
> If we are making this release for a security incident/data loss/hot fix
> reason, then I would expect to see the related change set only containing
> those patches.  But the change set in the tag here the latest 4.0-dev
> commits.
>
> Do we want to be violating our goal of only releasing with green CI less
> than a month after the vote?
>
> -Jeremiah Jordan
>
> On Feb 7, 2022, at 8:14 AM, Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 4.0.2 for release.
>
> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
>
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
>
> 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]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative
>
>
>

Re: [VOTE] Release Apache Cassandra 4.0.2

[Jeff Jirsa]

+1


On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie  wrote:

> I find myself agreeing with Jeremiah's sentiment here.
>
> For example, we're asking people that are on 4.0.1 to make the difficult
> choice between accepting the risk of whatever prompts an urgent release vs.
> accepting the risk of potentially destabilizing their GA critical
> infrastructure. The 4.0 line is regressing, at least from a CI perspective:
> https://butler.cassandra.apache.org/#/ci/upstream/trend
>
> I'm a -0 on this release as structured; given we discussed this exact
> situation when we adopted the new procedures I personally accept us moving
> forward right now and wouldn't block the release, but going forward I'd
> like to see us cut hotfix releases based on the latest GA plus a minimal
> patchset to address whatever urgent need a release is targeting so long as
> CI is in a regressing state.
>
>
> On Tue, Feb 8, 2022 at 3:18 PM Jeremiah D Jordan <
> jeremiah.jor...@gmail.com> wrote:
>
>> -1 nb
>>
>> So we just voted on an approved the CI process page recently:
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
>>
>> Where we said:
>> "All releases by default are expected to have a green test run on
>> ci-cassandra.apache.org Jenkins. In exceptional circumstances (security
>> incidents, data loss, etc requiring hotfix), members with binding votes
>> on a release may choose to approve a release with known failing tests.”
>>
>> I do not see green CI runs recently for 4.0.
>> https://ci-cassandra.apache.org/job/Cassandra-4.0/
>>
>> If we are making this release for a security incident/data loss/hot fix
>> reason, then I would expect to see the related change set only containing
>> those patches.  But the change set in the tag here the latest 4.0-dev
>> commits.
>>
>> Do we want to be violating our goal of only releasing with green CI less
>> than a month after the vote?
>>
>> -Jeremiah Jordan
>>
>> On Feb 7, 2022, at 8:14 AM, Mick Semb Wever  wrote:
>>
>> Proposing the test build of Cassandra 4.0.2 for release.
>>
>> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
>>
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>>
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
>>
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
>>
>> 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]: CHANGES.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative
>>
>>
>>

Re: [VOTE] Release Apache Cassandra 4.0.2

[Jeff Jirsa]

(This was a +1 on the release, to be clear, not a +1 on the sentiment
below, which I appreciate but still believe we should proceed with the
release)


On Tue, Feb 8, 2022 at 3:44 PM Jeff Jirsa  wrote:

> +1
>
>
> On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie 
> wrote:
>
>> I find myself agreeing with Jeremiah's sentiment here.
>>
>> For example, we're asking people that are on 4.0.1 to make the difficult
>> choice between accepting the risk of whatever prompts an urgent release vs.
>> accepting the risk of potentially destabilizing their GA critical
>> infrastructure. The 4.0 line is regressing, at least from a CI perspective:
>> https://butler.cassandra.apache.org/#/ci/upstream/trend
>>
>> I'm a -0 on this release as structured; given we discussed this exact
>> situation when we adopted the new procedures I personally accept us moving
>> forward right now and wouldn't block the release, but going forward I'd
>> like to see us cut hotfix releases based on the latest GA plus a minimal
>> patchset to address whatever urgent need a release is targeting so long as
>> CI is in a regressing state.
>>
>>
>> On Tue, Feb 8, 2022 at 3:18 PM Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com> wrote:
>>
>>> -1 nb
>>>
>>> So we just voted on an approved the CI process page recently:
>>>
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
>>>
>>> Where we said:
>>> "All releases by default are expected to have a green test run on
>>> ci-cassandra.apache.org Jenkins. In exceptional circumstances (security
>>> incidents, data loss, etc requiring hotfix), members with binding votes
>>> on a release may choose to approve a release with known failing tests.”
>>>
>>> I do not see green CI runs recently for 4.0.
>>> https://ci-cassandra.apache.org/job/Cassandra-4.0/
>>>
>>> If we are making this release for a security incident/data loss/hot fix
>>> reason, then I would expect to see the related change set only containing
>>> those patches.  But the change set in the tag here the latest 4.0-dev
>>> commits.
>>>
>>> Do we want to be violating our goal of only releasing with green CI less
>>> than a month after the vote?
>>>
>>> -Jeremiah Jordan
>>>
>>> On Feb 7, 2022, at 8:14 AM, Mick Semb Wever  wrote:
>>>
>>> Proposing the test build of Cassandra 4.0.2 for release.
>>>
>>> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
>>>
>>> Git:
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>>>
>>> Maven Artifacts:
>>> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
>>>
>>> The Source and Build Artifacts, and the Debian and RPM packages and
>>> repositories, are available here:
>>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
>>>
>>> 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]: CHANGES.txt:
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
>>> [2]: NEWS.txt:
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative
>>>
>>>
>>>