Re: [VOTE] Release Apache Cassandra 4.0.3

[Aleksey Yeschenko]

+1

> On 15 Feb 2022, at 07:49, Marcus Eriksson  wrote:
> 
> +1
> 
> On Sun, Feb 13, 2022 at 11:03:01PM +0100, Mick Semb Wever wrote:
>> Proposing the test build of Cassandra 4.0.3 for release.
>> 
>> 
>> sha1: a87055d56a33a9b17606f14535f48eb461965b82
>> 
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.3-tentative
>> 
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1259/org/apache/cassandra/cassandra-all/4.0.3/
>> 
>> 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.3/
>> 
>> 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.3-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.3-tentative

[DISCUSS] Hotfix release procedure

[Josh McKenzie]

On the release thread for 4.0.2 Jeremiah brought up a point about hotfix 
releases and CI: 
https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr

> 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.

I'd like to propose that in the future, regardless of the state of CI, if we 
need to cut a hotfix release we do so from the previous released SHA + only the 
changes required to address the hotfix to minimally impact our end users and 
provide them with as minimally disruptive a fix as possible.

Re: [DISCUSS] Hotfix release procedure

[J. D. Jordan]

+1. If we want to take our release quality seriously then I think this would be 
a great policy to have.

> On Feb 15, 2022, at 8:09 AM, Josh McKenzie  wrote:
> 
> 
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix 
> releases and CI: 
> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
> 
>> 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.
> 
> I'd like to propose that in the future, regardless of the state of CI, if we 
> need to cut a hotfix release we do so from the previous released SHA + only 
> the changes required to address the hotfix to minimally impact our end users 
> and provide them with as minimally disruptive a fix as possible.

Re: [DISCUSS] Hotfix release procedure

[Brandon Williams]

+1

On Tue, Feb 15, 2022 at 8:09 AM Josh McKenzie  wrote:
>
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix 
> releases and CI:
> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
>
> 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.
>
>
> I'd like to propose that in the future, regardless of the state of CI, if we 
> need to cut a hotfix release we do so from the previous released SHA + only 
> the changes required to address the hotfix to minimally impact our end users 
> and provide them with as minimally disruptive a fix as possible.

Re: [DISCUSS] Hotfix release procedure

[bened...@apache.org]

One issue with this approach is that we are advertising that we are preparing a 
security release by preparing such a release candidate.

I wonder if we need to find a way to produce binaries without leaving an 
obvious public mark (i.e. private CI, private branch)


From: Josh McKenzie 
Date: Tuesday, 15 February 2022 at 14:09
To: dev@cassandra.apache.org 
Subject: [DISCUSS] Hotfix release procedure
On the release thread for 4.0.2 Jeremiah brought up a point about hotfix 
releases and CI:
https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr

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.

I'd like to propose that in the future, regardless of the state of CI, if we 
need to cut a hotfix release we do so from the previous released SHA + only the 
changes required to address the hotfix to minimally impact our end users and 
provide them with as minimally disruptive a fix as possible.

Re: [DISCUSS] Hotfix release procedure

[J. D. Jordan]

We already advertise that we are preparing a security release when ever we 
release all of our patch versions at the same time. So I don’t think there is 
an issue there.
I was not involved in any PMC discussions and had no knowledge of the CVE, but 
when three branches got release votes at the same moment I knew one of the 
final couple patches that was on all three must be an un-announced CVE. It is 
especially more obvious when said patches mention JIRA ticket numbers with no 
information in the ticket. Nobody is being sneaky here as long as the vote and 
code are in the open.

> On Feb 15, 2022, at 9:15 AM, bened...@apache.org wrote:
> 
> 
> One issue with this approach is that we are advertising that we are preparing 
> a security release by preparing such a release candidate.
>  
> I wonder if we need to find a way to produce binaries without leaving an 
> obvious public mark (i.e. private CI, private branch)
>  
>  
> From: Josh McKenzie 
> Date: Tuesday, 15 February 2022 at 14:09
> To: dev@cassandra.apache.org 
> Subject: [DISCUSS] Hotfix release procedure
> 
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix 
> releases and CI: 
> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
>  
> 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.
>  
> I'd like to propose that in the future, regardless of the state of CI, if we 
> need to cut a hotfix release we do so from the previous released SHA + only 
> the changes required to address the hotfix to minimally impact our end users 
> and provide them with as minimally disruptive a fix as possible.

Re: [DISCUSS] Hotfix release procedure

[Jeff Jirsa]

We've done concurrent releases without security before, and you follow much
closer than others. I feel most people, if they saw all of the
changes reverted and a release of a single fix, would either instantly know
it's security (high confidence pointer to exactly which patch) OR assume
someone botched the release prep and draw attention to it. So we're trading
"someone who's very involved has a high confidence it's security but has to
dig through 30 patches to find it" vs "everyone knows exactly what's going
on", the former seems better

The only way I'd be in favor of a release that removes all other committed
patches is if the vote happened in private@ . I don't see any prohibition
on that in https://www.apache.org/foundation/voting.html#ReleaseVotes , so
that seems like an alternate, easy workaround to privacy.



On Tue, Feb 15, 2022 at 7:42 AM J. D. Jordan 
wrote:

> We already advertise that we are preparing a security release when ever we
> release all of our patch versions at the same time. So I don’t think there
> is an issue there.
> I was not involved in any PMC discussions and had no knowledge of the CVE,
> but when three branches got release votes at the same moment I knew one of
> the final couple patches that was on all three must be an un-announced CVE.
> It is especially more obvious when said patches mention JIRA ticket numbers
> with no information in the ticket. Nobody is being sneaky here as long as
> the vote and code are in the open.
>
> On Feb 15, 2022, at 9:15 AM, bened...@apache.org wrote:
>
> 
>
> One issue with this approach is that we are advertising that we are
> preparing a security release by preparing such a release candidate.
>
>
>
> I wonder if we need to find a way to produce binaries without leaving an
> obvious public mark (i.e. private CI, private branch)
>
>
>
>
>
> *From: *Josh McKenzie 
> *Date: *Tuesday, 15 February 2022 at 14:09
> *To: *dev@cassandra.apache.org 
> *Subject: *[DISCUSS] Hotfix release procedure
>
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix
> releases and CI:
>
> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
>
>
>
> 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.
>
>
>
> I'd like to propose that in the future, regardless of the state of CI, if
> we need to cut a hotfix release we do so from the previous released SHA +
> only the changes required to address the hotfix to minimally impact our end
> users and provide them with as minimally disruptive a fix as possible.
>
>

Re: [DISCUSS] Hotfix release procedure

[Josh McKenzie]

> The only way I'd be in favor of a release that removes all other committed 
> patches
Couldn't we just have a snapshot branch for each supported major/minor release 
branch that we patch for hotfixes and we bump up whenever we have a GA on a 
parent branch?

Shouldn't be any extra burden other than having three extra branches to 
remember exist; wouldn't need to merge to them or patch to them other than a 
fast-forward on a given GA.

On Tue, Feb 15, 2022, at 10:48 AM, Jeff Jirsa wrote:
> We've done concurrent releases without security before, and you follow much 
> closer than others. I feel most people, if they saw all of the changes 
> reverted and a release of a single fix, would either instantly know it's 
> security (high confidence pointer to exactly which patch) OR assume someone 
> botched the release prep and draw attention to it. So we're trading "someone 
> who's very involved has a high confidence it's security but has to dig 
> through 30 patches to find it" vs "everyone knows exactly what's going on", 
> the former seems better
> 
> The only way I'd be in favor of a release that removes all other committed 
> patches is if the vote happened in private@ . I don't see any prohibition on 
> that in https://www.apache.org/foundation/voting.html#ReleaseVotes , so that 
> seems like an alternate, easy workaround to privacy. 
> 
> 
> 
> On Tue, Feb 15, 2022 at 7:42 AM J. D. Jordan  
> wrote:
>> 
>> We already advertise that we are preparing a security release when ever we 
>> release all of our patch versions at the same time. So I don’t think there 
>> is an issue there.
>> I was not involved in any PMC discussions and had no knowledge of the CVE, 
>> but when three branches got release votes at the same moment I knew one of 
>> the final couple patches that was on all three must be an un-announced CVE. 
>> It is especially more obvious when said patches mention JIRA ticket numbers 
>> with no information in the ticket. Nobody is being sneaky here as long as 
>> the vote and code are in the open.
>> 
>>> On Feb 15, 2022, at 9:15 AM, bened...@apache.org wrote:
>>>  
>>> One issue with this approach is that we are advertising that we are 
>>> preparing a security release by preparing such a release candidate.
>>> __ __
>>> I wonder if we need to find a way to produce binaries without leaving an 
>>> obvious public mark (i.e. private CI, private branch)
>>> __ __
>>> __ __
>>> *From: *Josh McKenzie 
>>> *Date: *Tuesday, 15 February 2022 at 14:09
>>> *To: *dev@cassandra.apache.org 
>>> *Subject: *[DISCUSS] Hotfix release procedure
>>> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix 
>>> releases and CI: 
>>> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
>>> __ __
 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.
>>> __ __
>>> I'd like to propose that in the future, regardless of the state of CI, if 
>>> we need to cut a hotfix release we do so from the previous released SHA + 
>>> only the changes required to address the hotfix to minimally impact our end 
>>> users and provide them with as minimally disruptive a fix as possible.

Re: [DISCUSS] Hotfix release procedure

[Marcus Eriksson]

+1 (hotfix with only security fix, private vote, private branch & private ci)

On Tue, Feb 15, 2022 at 02:18:42PM +, bened...@apache.org wrote:
> One issue with this approach is that we are advertising that we are preparing 
> a security release by preparing such a release candidate.
> 
> I wonder if we need to find a way to produce binaries without leaving an 
> obvious public mark (i.e. private CI, private branch)
> 
> 
> From: Josh McKenzie 
> Date: Tuesday, 15 February 2022 at 14:09
> To: dev@cassandra.apache.org 
> Subject: [DISCUSS] Hotfix release procedure
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix 
> releases and CI:
> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
> 
> 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.
> 
> I'd like to propose that in the future, regardless of the state of CI, if we 
> need to cut a hotfix release we do so from the previous released SHA + only 
> the changes required to address the hotfix to minimally impact our end users 
> and provide them with as minimally disruptive a fix as possible.

Re: [DISCUSS] Hotfix release procedure

[Brandon Williams]

On Tue, Feb 15, 2022 at 9:53 AM Josh McKenzie  wrote:
>
> The only way I'd be in favor of a release that removes all other committed 
> patches
>
> Couldn't we just have a snapshot branch for each supported major/minor 
> release branch that we patch for hotfixes and we bump up whenever we have a 
> GA on a parent branch?

I think you could just checkout the tag of the previous release into a
new branch and apply the fix to it.

Kind Regards,
Brandon

Re: [DISCUSS] Hotfix release procedure

[Josh McKenzie]

Was thinking that too after I wrote this. Means we'd only need to change our 
process for future hotfixes and keep everything else as-is.

On Tue, Feb 15, 2022, at 10:55 AM, Brandon Williams wrote:
> On Tue, Feb 15, 2022 at 9:53 AM Josh McKenzie  wrote:
> >
> > The only way I'd be in favor of a release that removes all other committed 
> > patches
> >
> > Couldn't we just have a snapshot branch for each supported major/minor 
> > release branch that we patch for hotfixes and we bump up whenever we have a 
> > GA on a parent branch?
> 
> I think you could just checkout the tag of the previous release into a
> new branch and apply the fix to it.
> 
> Kind Regards,
> Brandon
> 

Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Benjamin Lerer]

 The PMC members are pleased to announce that Anthony Grasso, Erick Ramirez
and Lorina Poland have accepted the invitation to become committers.

Thanks a lot, Anthony, Erick and Lorina for all the work you have done on
the website and documentation.

Congratulations and welcome

The Apache Cassandra PMC members

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Ekaterina Dimitrova]

Great news! Congrats and thank you for all your work!

On Tue, 15 Feb 2022 at 13:13, Benjamin Lerer  wrote:

> The PMC members are pleased to announce that Anthony Grasso, Erick Ramirez
> and Lorina Poland have accepted the invitation to become committers.
>
> Thanks a lot, Anthony, Erick and Lorina for all the work you have done on
> the website and documentation.
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members
>

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Brandon Williams]

Congratulations, well deserved!

On Tue, Feb 15, 2022 at 12:13 PM Benjamin Lerer  wrote:
>
> The PMC members are pleased to announce that Anthony Grasso, Erick Ramirez 
> and Lorina Poland have accepted the invitation to become committers.
>
> Thanks a lot, Anthony, Erick and Lorina for all the work you have done on the 
> website and documentation.
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members

Re: [DISCUSS] Hotfix release procedure

[J. D. Jordan]

Correct. No need to revert anything or keep extra branches around. You just 
checkout the tag and then make a branch with the single fix on it.

> On Feb 15, 2022, at 10:08 AM, Josh McKenzie  wrote:
> 
> 
> Was thinking that too after I wrote this. Means we'd only need to change our 
> process for future hotfixes and keep everything else as-is.
> 
>> On Tue, Feb 15, 2022, at 10:55 AM, Brandon Williams wrote:
>> On Tue, Feb 15, 2022 at 9:53 AM Josh McKenzie  wrote:
>> >
>> > The only way I'd be in favor of a release that removes all other committed 
>> > patches
>> >
>> > Couldn't we just have a snapshot branch for each supported major/minor 
>> > release branch that we patch for hotfixes and we bump up whenever we have 
>> > a GA on a parent branch?
>> 
>> I think you could just checkout the tag of the previous release into a
>> new branch and apply the fix to it.
>> 
>> Kind Regards,
>> Brandon
>> 
> 

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Patrick McFadin]

This is a great day for the project. These are three people that have been
contributing continuously to the success of Cassandra users for so many
years I can't even guess. Really makes me happy to see the project mature
into a place where a diversity of contributions are recognized.

Congratulations Lorina, Erick, and Anthony!

Patrick

On Tue, Feb 15, 2022 at 10:30 AM Brandon Williams  wrote:

> Congratulations, well deserved!
>
> On Tue, Feb 15, 2022 at 12:13 PM Benjamin Lerer  wrote:
> >
> > The PMC members are pleased to announce that Anthony Grasso, Erick
> Ramirez and Lorina Poland have accepted the invitation to become committers.
> >
> > Thanks a lot, Anthony, Erick and Lorina for all the work you have done
> on the website and documentation.
> >
> > Congratulations and welcome
> >
> > The Apache Cassandra PMC members
>

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[J. D. Jordan]

Congratulations all of you! Well deserved additions.

> On Feb 15, 2022, at 12:30 PM, Brandon Williams  wrote:
> 
> Congratulations, well deserved!
> 
>> On Tue, Feb 15, 2022 at 12:13 PM Benjamin Lerer  wrote:
>> 
>> The PMC members are pleased to announce that Anthony Grasso, Erick Ramirez 
>> and Lorina Poland have accepted the invitation to become committers.
>> 
>> Thanks a lot, Anthony, Erick and Lorina for all the work you have done on 
>> the website and documentation.
>> 
>> Congratulations and welcome
>> 
>> The Apache Cassandra PMC members

RE: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Chris Thornett]

Fantastic news! Congrats to you all and well deserved!

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Melissa Logan]

Spectacular -- congrats, all!

On Tue, Feb 15, 2022 at 11:27 AM Chris Thornett  wrote:

> Fantastic news! Congrats to you all and well deserved!
>


-- 
Melissa Logan (she/her)
Principal, Constantia.io
meli...@constantia.io
Cell: 503-317-8498
LinkedIn  | Twitter

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Paulo Motta]

Nice work guys! Very happy to see non-core-database contributors being
recognized by the project as committers.

Em ter., 15 de fev. de 2022 às 16:28, Melissa Logan 
escreveu:

> Spectacular -- congrats, all!
>
> On Tue, Feb 15, 2022 at 11:27 AM Chris Thornett 
> wrote:
>
>> Fantastic news! Congrats to you all and well deserved!
>>
>
>
> --
> Melissa Logan (she/her)
> Principal, Constantia.io
> meli...@constantia.io
> Cell: 503-317-8498
> LinkedIn  | Twitter
> 
>
>

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Mick Semb Wever]

>
>
> Thanks a lot, Anthony, Erick and Lorina for all the work you have done on
> the website and documentation.
>
>

Congrats !! There has been a huge amount of work on the docs rewrite, the
new docs build system, and all the content that's been landing recently 💪

Re: [DISCUSS] Hotfix release procedure

[Mick Semb Wever]

We've done concurrent releases without security before, and you follow much
> closer than others. I feel most people, if they saw all of the
> changes reverted and a release of a single fix, would either instantly know
> it's security (high confidence pointer to exactly which patch) OR assume
> someone botched the release prep and draw attention to it. So we're trading
> "someone who's very involved has a high confidence it's security but has to
> dig through 30 patches to find it" vs "everyone knows exactly what's going
> on", the former seems better
>


My initial thoughts are aligned with what Jeff writes here. Furthermore
when you apply our new-found practice of stable trunk and focus on QA,
which I hope is continuously improving, this point only becomes more valid.

And how to do CI (we need a green CI for a release remember ;) on a private
commit is something i really am unsure how we would do…

Re: [DISCUSS] Hotfix release procedure

[Brandon Williams]

Any committer can submit a devbranch build...

Kind Regards,
Brandon

On Tue, Feb 15, 2022 at 1:58 PM Mick Semb Wever  wrote:
>
>
>
>> We've done concurrent releases without security before, and you follow much 
>> closer than others. I feel most people, if they saw all of the changes 
>> reverted and a release of a single fix, would either instantly know it's 
>> security (high confidence pointer to exactly which patch) OR assume someone 
>> botched the release prep and draw attention to it. So we're trading "someone 
>> who's very involved has a high confidence it's security but has to dig 
>> through 30 patches to find it" vs "everyone knows exactly what's going on", 
>> the former seems better
>
>
>
> My initial thoughts are aligned with what Jeff writes here. Furthermore when 
> you apply our new-found practice of stable trunk and focus on QA, which I 
> hope is continuously improving, this point only becomes more valid.
>
> And how to do CI (we need a green CI for a release remember ;) on a private 
> commit is something i really am unsure how we would do…

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Berenguer Blasi]

Congrats, nice one!

On 15/2/22 20:50, Mick Semb Wever wrote:



Thanks a lot, Anthony, Erick and Lorina for all the work you have
done on the website and documentation.



Congrats !! There has been a huge amount of work on the docs rewrite, 
the new docs build system, and all the content that's been landing 
recently 💪

Client password hashing

[Berenguer Blasi]

Hi all,

I would like to propose to add support for client password hashing 
(https://issues.apache.org/jira/browse/CASSANDRA-17334). If anybody has 
any concerns or question with this functionality I will be happy to 
discuss them.


Thx in advance.