Re: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2

[guo Maxwell]

+1

German Eichberger via dev  于2023年11月1日周三 04:58写道：

> +1
>
> Heck, yeah, we already tested the branch (build ourselves) and it works
> great so far.
> --
> *From:* Mick Semb Wever 
> *Sent:* Tuesday, October 31, 2023 1:43 PM
> *Cc:* dev 
> *Subject:* [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2
>
> > The vote will be open for 72 hours (longer if needed). Everyone who
> > has tested the build is invited to vote. Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding
> > +1s and no -1's.
>
>
> +1
>
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds (JDK 11+17)
> - binary artefact runs (JDK 11+17)
> - debian package runs (JDK 11+17)
> - debian repo runs (JDK 11+17)
> - redhat* package runs (JDK11+17)
> - redhat* repo runs (JDK 11+17)
>

Re: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2

[German Eichberger via dev]

+1

Heck, yeah, we already tested the branch (build ourselves) and it works great 
so far.

From: Mick Semb Wever 
Sent: Tuesday, October 31, 2023 1:43 PM
Cc: dev 
Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2

> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.


+1

Checked
- signing correct
- checksums are correct
- source artefact builds (JDK 11+17)
- binary artefact runs (JDK 11+17)
- debian package runs (JDK 11+17)
- debian repo runs (JDK 11+17)
- redhat* package runs (JDK11+17)
- redhat* repo runs (JDK 11+17)

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

[Mick Semb Wever]

> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.


+1

Checked
- signing correct
- checksums are correct
- source artefact builds (JDK 11+17)
- binary artefact runs (JDK 11+17)
- debian package runs (JDK 11+17)
- debian repo runs (JDK 11+17)
- redhat* package runs (JDK11+17)
- redhat* repo runs (JDK 11+17)

Re: Immediately Deprecated Code

[Mick Semb Wever]

For online upgrades we support skipping majors so long as the majors are
adjacent.
That is, any 4.x.z to any 5.x.z
 ( Is it recommended that you always first patch upgrade the .z to the
latest before the major upgrade. )

For offline upgrades, we are aiming to maintain all compatibility.

Take care when removing code, there are various (serdes) classes that look
like they are for other components but are also used in the storage engine.



On Tue, 31 Oct 2023 at 18:42, Claude Warren, Jr via dev <
dev@cassandra.apache.org> wrote:

> In your example 5.1 can read 4.x because 4.0 (?) is the earliest version
> that 5.x supports.  I don't think you can upgrade directly from 3.x to 5.x
> without an intermediate stop at some version of 4.x can you?  So when we
> get to 6.x we won't need the 4 -> 5 conversion code because 6 will only
> support reading from  5.  If I am incorrect and we expect a version to be
> able to read 2 major versions back then indeed the deprecated since would
> be 2 major versions ahead of the version when the code was written.
>
> On Tue, Oct 31, 2023 at 2:40 PM Andrew Weaver 
> wrote:
>
>> Skipping versions on upgrade is absolutely something that happens in the
>> real world.  This is particularly highlighted by the discussion around
>> 5.0/5.1 that's been happening - 5.0 has been described as a potential
>> "ghost version" which I completely understand.
>>
>> Getting rid of some of the old cruft that seems unnecessary (and strictly
>> speaking is unnecessary) is not without its downsides.  In this case, that
>> cruft improves the user experience.
>>
>> On Tue, Oct 31, 2023 at 5:56 AM Miklosovic, Stefan via dev <
>> dev@cassandra.apache.org> wrote:
>>
>>> Do I understand it correctly that this is basically the case of
>>> "deprecated on introduction" as we know that it will not be necessary the
>>> very next version?
>>>
>>> I think that not everybody is upgrading from version to version as they
>>> appear. If somebody upgrades from 4.0 to 5.1 (which we seem to support) (1)
>>> and you would have introduced the deprecation in 4.0 with intention to
>>> remove it in 5.0 and somebody jumps to 5.1 straight away, is not that a
>>> problem? Because they have not made the move via 5.0 where you upgrade
>>> logic was triggered.
>>>
>>> (1)
>>> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L97-L108
>>>
>>> 
>>> From: Claude Warren, Jr via dev 
>>> Sent: Tuesday, October 31, 2023 10:57
>>> To: dev
>>> Cc: Claude Warren, Jr
>>> Subject: Immediately Deprecated Code
>>>
>>> NetApp Security WARNING: This is an external email. Do not click links
>>> or open attachments unless you recognize the sender and know the content is
>>> safe.
>>>
>>>
>>>
>>> I was thinking about code that is used to migrate from one version to
>>> another.  For example the code that rewrote the order of the hash values
>>> used for Bloom filters.  That code was necessary for the version it was
>>> coded in.  But the next version does not need that code because the next
>>> version is not going to read the data from 2 versions prior to itself.  So
>>> the code could be removed for verson+1.
>>>
>>> So, would it have made sense to annotate those methods (and variables)
>>> as deprecated since the version they were written in so the
>>> methods/variables can be removed in the next version?
>>>
>>> If so, what I propose is that all transitional methods and variable be
>>> marked as deprecated with the version in which they were introduced.
>>>
>>>
>>
>> --
>> Andrew Weaver
>>
>

Re: Immediately Deprecated Code

[Claude Warren, Jr via dev]

In your example 5.1 can read 4.x because 4.0 (?) is the earliest version
that 5.x supports.  I don't think you can upgrade directly from 3.x to 5.x
without an intermediate stop at some version of 4.x can you?  So when we
get to 6.x we won't need the 4 -> 5 conversion code because 6 will only
support reading from  5.  If I am incorrect and we expect a version to be
able to read 2 major versions back then indeed the deprecated since would
be 2 major versions ahead of the version when the code was written.

On Tue, Oct 31, 2023 at 2:40 PM Andrew Weaver 
wrote:

> Skipping versions on upgrade is absolutely something that happens in the
> real world.  This is particularly highlighted by the discussion around
> 5.0/5.1 that's been happening - 5.0 has been described as a potential
> "ghost version" which I completely understand.
>
> Getting rid of some of the old cruft that seems unnecessary (and strictly
> speaking is unnecessary) is not without its downsides.  In this case, that
> cruft improves the user experience.
>
> On Tue, Oct 31, 2023 at 5:56 AM Miklosovic, Stefan via dev <
> dev@cassandra.apache.org> wrote:
>
>> Do I understand it correctly that this is basically the case of
>> "deprecated on introduction" as we know that it will not be necessary the
>> very next version?
>>
>> I think that not everybody is upgrading from version to version as they
>> appear. If somebody upgrades from 4.0 to 5.1 (which we seem to support) (1)
>> and you would have introduced the deprecation in 4.0 with intention to
>> remove it in 5.0 and somebody jumps to 5.1 straight away, is not that a
>> problem? Because they have not made the move via 5.0 where you upgrade
>> logic was triggered.
>>
>> (1)
>> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L97-L108
>>
>> 
>> From: Claude Warren, Jr via dev 
>> Sent: Tuesday, October 31, 2023 10:57
>> To: dev
>> Cc: Claude Warren, Jr
>> Subject: Immediately Deprecated Code
>>
>> NetApp Security WARNING: This is an external email. Do not click links or
>> open attachments unless you recognize the sender and know the content is
>> safe.
>>
>>
>>
>> I was thinking about code that is used to migrate from one version to
>> another.  For example the code that rewrote the order of the hash values
>> used for Bloom filters.  That code was necessary for the version it was
>> coded in.  But the next version does not need that code because the next
>> version is not going to read the data from 2 versions prior to itself.  So
>> the code could be removed for verson+1.
>>
>> So, would it have made sense to annotate those methods (and variables) as
>> deprecated since the version they were written in so the methods/variables
>> can be removed in the next version?
>>
>> If so, what I propose is that all transitional methods and variable be
>> marked as deprecated with the version in which they were introduced.
>>
>>
>
> --
> Andrew Weaver
>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Jeremy Hanna]

I think the goal is to say "how could we get some working version of TCM/Accord 
into people's hands to try out at/by Summit?"  That's all.  People are eager to 
see it and try it out.

> On Oct 31, 2023, at 12:16 PM, Benedict  wrote:
> 
> No, if I understand it correctly we’re in weird hypothetical land where 
> people are inventing new release types (“preview”) to avoid merging TCM[1] in 
> the event we want to cut a 5.1 release from the PR prior to the summit if 
> there’s some handful of failing tests in the PR. 
> 
> This may or may not be a waste of everyone’s time.
> 
> Jeremiah, I’m not questioning: it was procedurally invalid. How we handle 
> that is, as always, a matter for community decision making.
> 
> [1] how this helps isn’t entirely clear
> 
>> On 31 Oct 2023, at 17:08, Paulo Motta  wrote:
>> 
>> 
>> Even if it was not formally prescribed as far as I understand, we have been 
>> following the "only merge on Green CI" custom as much as possible for the 
>> past several years. Is the proposal to relax this rule for 5.0?
>> 
>> On Tue, Oct 31, 2023 at 1:02 PM Jeremiah Jordan > > wrote:
>>> You are free to argue validity.  I am just stating what I see on the 
>>> mailing list and in the wiki.  We had a vote which was called passing and 
>>> was not contested at that time.  The vote was on a process which includes 
>>> as #3 in the list:
>>> 
>>> Before a merge, a committer needs either a non-regressing (i.e. no new 
>>> failures) run of circleci with the required test suites (TBD; see below) or 
>>> of ci-cassandra.
>>> Non-regressing is defined here as "Doesn't introduce any new test failures; 
>>> any new failures in CI are clearly not attributable to this diff"
>>> (NEW) After merging tickets, ci-cassandra runs against the SHA and the 
>>> author gets an advisory update on the related JIRA for any new errors on 
>>> CI. The author of the ticket will take point on triaging this new failure 
>>> and either fixing (if clearly reproducible or related to their work) or 
>>> opening a JIRA for the intermittent failure and linking it in butler 
>>> (https://butler.cassandra.apache.org/#/)
>>> 
>>> Which clearly says that before merge we ensure there are no known new 
>>> regressions to CI.
>>> 
>>> The allowance for releases without CI being green, and merges without the 
>>> CI being completely green are from the fact that our trunk CI has rarely 
>>> been completely green, so we allow merging things which do not introduce 
>>> NEW regressions, and we allow releases with known regressions that are 
>>> deemed acceptable.
>>> 
>>> We can indeed always vote to override it, and if it comes to that we can 
>>> consider that as an option.
>>> 
>>> -Jeremiah
>>> 
>>> On Oct 31, 2023 at 11:41:29 AM, Benedict >> > wrote:
 That vote thread also did not reach the threshold; it was incorrectly 
 counted, as committer votes are not binding for procedural changes. I 
 counted at most 8 PMC +1 votes. 
 
 The focus of that thread was also clearly GA releases and merges on such 
 branches, since there was a focus on releases being failure-free. But this 
 predates the more general release lifecycle vote that allows for alphas to 
 have failing tests - which logically would be impossible if nothing were 
 merged with failing or flaky tests.
 
 Either way, the vote and discussion specifically allow for this to be 
 overridden.
 
 路‍♀️
 
> On 31 Oct 2023, at 16:29, Jeremiah Jordan  > wrote:
> 
> 
> I never said there was a need for green CI for alpha.  We do have a 
> requirement for not merging things to trunk that have known regressions 
> in CI.
> Vote here: 
> https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9
> 
> 
> 
> On Oct 31, 2023 at 3:23:48 AM, Benedict  > wrote:
>> There is no requirement for green CI on alpha. We voted last year to 
>> require running all tests before commit and to require green CI for beta 
>> releases. This vote was invalid because it didn’t reach the vote floor 
>> for a procedural change but anyway is not inconsistent with knowingly 
>> and selectively merging work without green CI.
>> 
>> If we reach the summit we should take a look at the state of the PRs and 
>> make a decision about if they are alpha quality; if so, and we want a 
>> release, we should simply merge it and release. Making up a new release 
>> type when the work meets alpha standard to avoid an arbitrary and not 
>> mandated commit bar seems the definition of silly.
>> 
>>> On 31 Oct 2023, at 04:34, J. D. Jordan >> > wrote:
>>> 
>>> 
>>> That is my understanding as well. If the TCM and Accord based on TCM 
>>> branches are ready to commit by ~12/1 we can 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

No, if I understand it correctly we’re in weird hypothetical land where people are inventing new release types (“preview”) to avoid merging TCM[1] in the event we want to cut a 5.1 release from the PR prior to the summit if there’s some handful of failing tests in the PR. This may or may not be a waste of everyone’s time.Jeremiah, I’m not questioning: it was procedurally invalid. How we handle that is, as always, a matter for community decision making.[1] how this helps isn’t entirely clearOn 31 Oct 2023, at 17:08, Paulo Motta  wrote:Even if it was not formally prescribed as far as I understand, we have been following the "only merge on Green CI" custom as much as possible for the past several years. Is the proposal to relax this rule for 5.0?On Tue, Oct 31, 2023 at 1:02 PM Jeremiah Jordan  wrote:
You are free to argue validity.  I am just stating what I see on the mailing list and in the wiki.  We had a vote which was called passing and was not contested at that time.  The vote was on a process which includes as #3 in the list:Before a merge, a committer needs either a non-regressing (i.e. no new failures) run of circleci with the required test suites (TBD; see below) or of ci-cassandra.Non-regressing is defined here as "Doesn't introduce any new test failures; any new failures in CI are clearly not attributable to this diff"(NEW) After merging tickets, ci-cassandra runs against the SHA and the author gets an advisory update on the related JIRA for any new errors on CI. The author of the ticket will take point on triaging this new failure and either fixing (if clearly reproducible or related to their work) or opening a JIRA for the intermittent failure and linking it in butler (https://butler.cassandra.apache.org/#/)Which clearly says that before merge we ensure there are no known new regressions to CI.The allowance for releases without CI being green, and merges without the CI being completely green are from the fact that our trunk CI has rarely been completely green, so we allow merging things which do not introduce NEW regressions, and we allow releases with known regressions that are deemed acceptable.We can indeed always vote to override it, and if it comes to that we can consider that as an option.-Jeremiah


On Oct 31, 2023 at 11:41:29 AM, Benedict  wrote:

That vote thread also did not reach the threshold; it was incorrectly counted, as committer votes are not binding for procedural changes. I counted at most 8 PMC +1 votes. The focus of that thread was also clearly GA releases and merges on such branches, since there was a focus on releases being failure-free. But this predates the more general release lifecycle vote that allows for alphas to have failing tests - which logically would be impossible if nothing were merged with failing or flaky tests.Either way, the vote and discussion specifically allow for this to be overridden.路‍♀️On 31 Oct 2023, at 16:29, Jeremiah Jordan  wrote:
I never said there was a need for green CI for alpha.  We do have a requirement for not merging things to trunk that have known regressions in CI.Vote here: https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9


On Oct 31, 2023 at 3:23:48 AM, Benedict  wrote:

There is no requirement for green CI on alpha. We voted last year to require running all tests before commit and to require green CI for beta releases. This vote was invalid because it didn’t reach the vote floor for a procedural change but anyway is not inconsistent with knowingly and selectively merging work without green CI.If we reach the summit we should take a look at the state of the PRs and make a decision about if they are alpha quality; if so, and we want a release, we should simply merge it and release. Making up a new release type when the work meets alpha standard to avoid an arbitrary and not mandated commit bar seems the definition of silly.On 31 Oct 2023, at 04:34, J. D. Jordan  wrote:That is my understanding as well. If the TCM and Accord based on TCM branches are ready to commit by ~12/1 we can cut a 5.1 branch and then a 5.1-alpha release.Where “ready to commit” means our usual things of two committer +1 and green CI etc.If we are not ready to commit then I propose that as long as everything in the accord+tcm Apache repo branch has had two committer +1’s, but maybe people are still working on fixes for getting CI green or similar, we cut a 5.1-preview  build from the feature branch to vote on with known issues documented.  This would not be the preferred path, but would be a way to have a voted on release for summit.-Jeremiah On Oct 30, 2023, at 5:59 PM, Mick Semb Wever  wrote:Hoping we can get clarity on this.The proposal was, once TCM and Accord merges to trunk,  then immediately branch cassandra-5.1 and cut an immediate 5.1-alpha1 release.This was 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Andrés de la Peña]

I'd add that even if we commit running CI to verify that we are not
introducing new test failures, we can always inadvertently introduce new
flakies. Those flakies can be hit long after the original commit,
for example while trying to make a release.

On Tue, 31 Oct 2023 at 17:08, Paulo Motta  wrote:

> Even if it was not formally prescribed as far as I understand, we have
> been following the "only merge on Green CI" custom as much as possible for
> the past several years. Is the proposal to relax this rule for 5.0?
>
> On Tue, Oct 31, 2023 at 1:02 PM Jeremiah Jordan 
> wrote:
>
>> You are free to argue validity.  I am just stating what I see on the
>> mailing list and in the wiki.  We had a vote which was called passing and
>> was not contested at that time.  The vote was on a process which includes
>> as #3 in the list:
>>
>>
>>1. Before a merge, a committer needs either a non-regressing (i.e. no
>>new failures) run of circleci with the required test suites (TBD; see
>>below) or of ci-cassandra.
>>   1. Non-regressing is defined here as "Doesn't introduce any new
>>   test failures; any new failures in CI are clearly not attributable to 
>> this
>>   diff"
>>   2. (NEW) After merging tickets, ci-cassandra runs against the SHA
>>   and the author gets an advisory update on the related JIRA for any new
>>   errors on CI. The author of the ticket will take point on triaging 
>> this new
>>   failure and either fixing (if clearly reproducible or related to their
>>   work) or opening a JIRA for the intermittent failure and linking it in
>>   butler (https://butler.cassandra.apache.org/#/)
>>
>>
>> Which clearly says that before merge we ensure there are no known new
>> regressions to CI.
>>
>> The allowance for releases without CI being green, and merges without the
>> CI being completely green are from the fact that our trunk CI has rarely
>> been completely green, so we allow merging things which do not introduce
>> NEW regressions, and we allow releases with known regressions that are
>> deemed acceptable.
>>
>> We can indeed always vote to override it, and if it comes to that we can
>> consider that as an option.
>>
>> -Jeremiah
>>
>> On Oct 31, 2023 at 11:41:29 AM, Benedict  wrote:
>>
>>> That vote thread also did not reach the threshold; it was incorrectly
>>> counted, as committer votes are not binding for procedural changes. I
>>> counted at most 8 PMC +1 votes.
>>>
>>> The focus of that thread was also clearly GA releases and merges on such
>>> branches, since there was a focus on releases being failure-free. But this
>>> predates the more general release lifecycle vote that allows for alphas to
>>> have failing tests - which logically would be impossible if nothing were
>>> merged with failing or flaky tests.
>>>
>>> Either way, the vote and discussion specifically allow for this to be
>>> overridden.
>>>
>>> 路‍♀️
>>>
>>> On 31 Oct 2023, at 16:29, Jeremiah Jordan 
>>> wrote:
>>>
>>> 
>>> I never said there was a need for green CI for alpha.  We do have a
>>> requirement for not merging things to trunk that have known regressions in
>>> CI.
>>> Vote here:
>>> https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9
>>>
>>>
>>>
>>> On Oct 31, 2023 at 3:23:48 AM, Benedict  wrote:
>>>
 There is no requirement for green CI on alpha. We voted last year to
 require running all tests before commit and to require green CI for beta
 releases. This vote was invalid because it didn’t reach the vote floor for
 a procedural change but anyway is not inconsistent with knowingly and
 selectively merging work without green CI.

 If we reach the summit we should take a look at the state of the PRs
 and make a decision about if they are alpha quality; if so, and we want a
 release, we should simply merge it and release. Making up a new release
 type when the work meets alpha standard to avoid an arbitrary and not
 mandated commit bar seems the definition of silly.

 On 31 Oct 2023, at 04:34, J. D. Jordan 
 wrote:

 
 That is my understanding as well. If the TCM and Accord based on TCM
 branches are ready to commit by ~12/1 we can cut a 5.1 branch and then a
 5.1-alpha release.
 Where “ready to commit” means our usual things of two committer +1 and
 green CI etc.

 If we are not ready to commit then I propose that as long as everything
 in the accord+tcm Apache repo branch has had two committer +1’s, but maybe
 people are still working on fixes for getting CI green or similar, we cut a
 5.1-preview  build from the feature branch to vote on with known issues
 documented.  This would not be the preferred path, but would be a way to
 have a voted on release for summit.

 -Jeremiah

 On Oct 30, 2023, at 5:59 PM, Mick Semb Wever  wrote:

 

 Hoping we can get clarity on this.

 The proposal was, once TCM and Accord 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Paulo Motta]

Even if it was not formally prescribed as far as I understand, we have been
following the "only merge on Green CI" custom as much as possible for the
past several years. Is the proposal to relax this rule for 5.0?

On Tue, Oct 31, 2023 at 1:02 PM Jeremiah Jordan 
wrote:

> You are free to argue validity.  I am just stating what I see on the
> mailing list and in the wiki.  We had a vote which was called passing and
> was not contested at that time.  The vote was on a process which includes
> as #3 in the list:
>
>
>1. Before a merge, a committer needs either a non-regressing (i.e. no
>new failures) run of circleci with the required test suites (TBD; see
>below) or of ci-cassandra.
>   1. Non-regressing is defined here as "Doesn't introduce any new
>   test failures; any new failures in CI are clearly not attributable to 
> this
>   diff"
>   2. (NEW) After merging tickets, ci-cassandra runs against the SHA
>   and the author gets an advisory update on the related JIRA for any new
>   errors on CI. The author of the ticket will take point on triaging this 
> new
>   failure and either fixing (if clearly reproducible or related to their
>   work) or opening a JIRA for the intermittent failure and linking it in
>   butler (https://butler.cassandra.apache.org/#/)
>
>
> Which clearly says that before merge we ensure there are no known new
> regressions to CI.
>
> The allowance for releases without CI being green, and merges without the
> CI being completely green are from the fact that our trunk CI has rarely
> been completely green, so we allow merging things which do not introduce
> NEW regressions, and we allow releases with known regressions that are
> deemed acceptable.
>
> We can indeed always vote to override it, and if it comes to that we can
> consider that as an option.
>
> -Jeremiah
>
> On Oct 31, 2023 at 11:41:29 AM, Benedict  wrote:
>
>> That vote thread also did not reach the threshold; it was incorrectly
>> counted, as committer votes are not binding for procedural changes. I
>> counted at most 8 PMC +1 votes.
>>
>> The focus of that thread was also clearly GA releases and merges on such
>> branches, since there was a focus on releases being failure-free. But this
>> predates the more general release lifecycle vote that allows for alphas to
>> have failing tests - which logically would be impossible if nothing were
>> merged with failing or flaky tests.
>>
>> Either way, the vote and discussion specifically allow for this to be
>> overridden.
>>
>> 路‍♀️
>>
>> On 31 Oct 2023, at 16:29, Jeremiah Jordan 
>> wrote:
>>
>> 
>> I never said there was a need for green CI for alpha.  We do have a
>> requirement for not merging things to trunk that have known regressions in
>> CI.
>> Vote here:
>> https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9
>>
>>
>>
>> On Oct 31, 2023 at 3:23:48 AM, Benedict  wrote:
>>
>>> There is no requirement for green CI on alpha. We voted last year to
>>> require running all tests before commit and to require green CI for beta
>>> releases. This vote was invalid because it didn’t reach the vote floor for
>>> a procedural change but anyway is not inconsistent with knowingly and
>>> selectively merging work without green CI.
>>>
>>> If we reach the summit we should take a look at the state of the PRs and
>>> make a decision about if they are alpha quality; if so, and we want a
>>> release, we should simply merge it and release. Making up a new release
>>> type when the work meets alpha standard to avoid an arbitrary and not
>>> mandated commit bar seems the definition of silly.
>>>
>>> On 31 Oct 2023, at 04:34, J. D. Jordan 
>>> wrote:
>>>
>>> 
>>> That is my understanding as well. If the TCM and Accord based on TCM
>>> branches are ready to commit by ~12/1 we can cut a 5.1 branch and then a
>>> 5.1-alpha release.
>>> Where “ready to commit” means our usual things of two committer +1 and
>>> green CI etc.
>>>
>>> If we are not ready to commit then I propose that as long as everything
>>> in the accord+tcm Apache repo branch has had two committer +1’s, but maybe
>>> people are still working on fixes for getting CI green or similar, we cut a
>>> 5.1-preview  build from the feature branch to vote on with known issues
>>> documented.  This would not be the preferred path, but would be a way to
>>> have a voted on release for summit.
>>>
>>> -Jeremiah
>>>
>>> On Oct 30, 2023, at 5:59 PM, Mick Semb Wever  wrote:
>>>
>>> 
>>>
>>> Hoping we can get clarity on this.
>>>
>>> The proposal was, once TCM and Accord merges to trunk,  then immediately
>>> branch cassandra-5.1 and cut an immediate 5.1-alpha1 release.
>>>
>>> This was to focus on stabilising TCM and Accord as soon as it lands,
>>> hence the immediate branching.
>>>
>>> And the alpha release as that is what our Release Lifecycle states it to
>>> be.
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>>>
>>> My understanding is that there 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Jeremiah Jordan]

 You are free to argue validity.  I am just stating what I see on the
mailing list and in the wiki.  We had a vote which was called passing and
was not contested at that time.  The vote was on a process which includes
as #3 in the list:


   1. Before a merge, a committer needs either a non-regressing (i.e. no
   new failures) run of circleci with the required test suites (TBD; see
   below) or of ci-cassandra.
  1. Non-regressing is defined here as "Doesn't introduce any new test
  failures; any new failures in CI are clearly not attributable to
this diff"
  2. (NEW) After merging tickets, ci-cassandra runs against the SHA and
  the author gets an advisory update on the related JIRA for any new errors
  on CI. The author of the ticket will take point on triaging this new
  failure and either fixing (if clearly reproducible or related to their
  work) or opening a JIRA for the intermittent failure and linking it in
  butler (https://butler.cassandra.apache.org/#/)


Which clearly says that before merge we ensure there are no known new
regressions to CI.

The allowance for releases without CI being green, and merges without the
CI being completely green are from the fact that our trunk CI has rarely
been completely green, so we allow merging things which do not introduce
NEW regressions, and we allow releases with known regressions that are
deemed acceptable.

We can indeed always vote to override it, and if it comes to that we can
consider that as an option.

-Jeremiah

On Oct 31, 2023 at 11:41:29 AM, Benedict  wrote:

> That vote thread also did not reach the threshold; it was incorrectly
> counted, as committer votes are not binding for procedural changes. I
> counted at most 8 PMC +1 votes.
>
> The focus of that thread was also clearly GA releases and merges on such
> branches, since there was a focus on releases being failure-free. But this
> predates the more general release lifecycle vote that allows for alphas to
> have failing tests - which logically would be impossible if nothing were
> merged with failing or flaky tests.
>
> Either way, the vote and discussion specifically allow for this to be
> overridden.
>
> 路‍♀️
>
> On 31 Oct 2023, at 16:29, Jeremiah Jordan 
> wrote:
>
> 
> I never said there was a need for green CI for alpha.  We do have a
> requirement for not merging things to trunk that have known regressions in
> CI.
> Vote here:
> https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9
>
>
>
> On Oct 31, 2023 at 3:23:48 AM, Benedict  wrote:
>
>> There is no requirement for green CI on alpha. We voted last year to
>> require running all tests before commit and to require green CI for beta
>> releases. This vote was invalid because it didn’t reach the vote floor for
>> a procedural change but anyway is not inconsistent with knowingly and
>> selectively merging work without green CI.
>>
>> If we reach the summit we should take a look at the state of the PRs and
>> make a decision about if they are alpha quality; if so, and we want a
>> release, we should simply merge it and release. Making up a new release
>> type when the work meets alpha standard to avoid an arbitrary and not
>> mandated commit bar seems the definition of silly.
>>
>> On 31 Oct 2023, at 04:34, J. D. Jordan  wrote:
>>
>> 
>> That is my understanding as well. If the TCM and Accord based on TCM
>> branches are ready to commit by ~12/1 we can cut a 5.1 branch and then a
>> 5.1-alpha release.
>> Where “ready to commit” means our usual things of two committer +1 and
>> green CI etc.
>>
>> If we are not ready to commit then I propose that as long as everything
>> in the accord+tcm Apache repo branch has had two committer +1’s, but maybe
>> people are still working on fixes for getting CI green or similar, we cut a
>> 5.1-preview  build from the feature branch to vote on with known issues
>> documented.  This would not be the preferred path, but would be a way to
>> have a voted on release for summit.
>>
>> -Jeremiah
>>
>> On Oct 30, 2023, at 5:59 PM, Mick Semb Wever  wrote:
>>
>> 
>>
>> Hoping we can get clarity on this.
>>
>> The proposal was, once TCM and Accord merges to trunk,  then immediately
>> branch cassandra-5.1 and cut an immediate 5.1-alpha1 release.
>>
>> This was to focus on stabilising TCM and Accord as soon as it lands,
>> hence the immediate branching.
>>
>> And the alpha release as that is what our Release Lifecycle states it to
>> be.
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>>
>> My understanding is that there was no squeezing in extra features into
>> 5.1 after TCM+Accord lands, and there's no need for a "preview" release –
>> we move straight to the alpha, as our lifecycle states.  And we will
>> describe all usability shortcomings and bugs with the alpha, our lifecycle
>> docs permit this, if we feel the need to.
>>
>> All this said, if TCM does not merge before the Summit, and we want to
>> get a release into user hands, it 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

That vote thread also did not reach the threshold; it was incorrectly counted, as committer votes are not binding for procedural changes. I counted at most 8 PMC +1 votes. The focus of that thread was also clearly GA releases and merges on such branches, since there was a focus on releases being failure-free. But this predates the more general release lifecycle vote that allows for alphas to have failing tests - which logically would be impossible if nothing were merged with failing or flaky tests.Either way, the vote and discussion specifically allow for this to be overridden.路‍♀️On 31 Oct 2023, at 16:29, Jeremiah Jordan  wrote:
I never said there was a need for green CI for alpha.  We do have a requirement for not merging things to trunk that have known regressions in CI.Vote here: https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9


On Oct 31, 2023 at 3:23:48 AM, Benedict  wrote:

There is no requirement for green CI on alpha. We voted last year to require running all tests before commit and to require green CI for beta releases. This vote was invalid because it didn’t reach the vote floor for a procedural change but anyway is not inconsistent with knowingly and selectively merging work without green CI.If we reach the summit we should take a look at the state of the PRs and make a decision about if they are alpha quality; if so, and we want a release, we should simply merge it and release. Making up a new release type when the work meets alpha standard to avoid an arbitrary and not mandated commit bar seems the definition of silly.On 31 Oct 2023, at 04:34, J. D. Jordan  wrote:That is my understanding as well. If the TCM and Accord based on TCM branches are ready to commit by ~12/1 we can cut a 5.1 branch and then a 5.1-alpha release.Where “ready to commit” means our usual things of two committer +1 and green CI etc.If we are not ready to commit then I propose that as long as everything in the accord+tcm Apache repo branch has had two committer +1’s, but maybe people are still working on fixes for getting CI green or similar, we cut a 5.1-preview  build from the feature branch to vote on with known issues documented.  This would not be the preferred path, but would be a way to have a voted on release for summit.-Jeremiah On Oct 30, 2023, at 5:59 PM, Mick Semb Wever  wrote:Hoping we can get clarity on this.The proposal was, once TCM and Accord merges to trunk,  then immediately branch cassandra-5.1 and cut an immediate 5.1-alpha1 release.This was to focus on stabilising TCM and Accord as soon as it lands, hence the immediate branching.And the alpha release as that is what our Release Lifecycle states it to be.https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle My understanding is that there was no squeezing in extra features into 5.1 after TCM+Accord lands, and there's no need for a "preview" release – we move straight to the alpha, as our lifecycle states.  And we will describe all usability shortcomings and bugs with the alpha, our lifecycle docs permit this, if we feel the need to.All this said, if TCM does not merge before the Summit, and we want to get a release into user hands, it has been suggested we cut a preview release 5.1-preview1 off the feature branch.  This is a different scenario, and only a mitigation plan.  On Thu, 26 Oct 2023 at 14:20, Benedict  wrote:The time to stabilise is orthogonal to the time we branch. Once we branch we stop accepting new features for the branch, and work to stabilise.My understanding is we will branch as soon as we have a viable alpha containing TCM and Accord. That means pretty soon after they land in the project, which we expect to be around the summit.If this isn’t the expectation we should make that clear, as it will affect how this decision is made.On 26 Oct 2023, at 10:14, Benjamin Lerer  wrote:
Regarding the release of 5.1, I 
understood the proposal to be that we cut an actual alpha, thereby 
sealing the 5.1 release from new features. Only features merged before 
we cut the alpha would be permitted, and the alpha should be cut as soon
 as practicable. What exactly would we be waiting for? The problem I believe is about expectations. It seems that your expectation is that a release with only TCM and Accord will reach GA quickly. Based on the time it took us to release 4.1, I am simply expecting more delays (a GA around end of May, June). In which case it seems to me that we could be interested in shipping more stuff in the meantime (thinking of CASSANDRA-15254 or CEP-29 for example).I do not have a strong opinion, I just want to make sure that we all share the same understanding and fully understand what we agree upon.    

Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a écrit :
I am surprised this needs to be said, 
but - especially for long-running CEPs - you must involve 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Jeremiah Jordan]

 I never said there was a need for green CI for alpha.  We do have a
requirement for not merging things to trunk that have known regressions in
CI.
Vote here: https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9



On Oct 31, 2023 at 3:23:48 AM, Benedict  wrote:

> There is no requirement for green CI on alpha. We voted last year to
> require running all tests before commit and to require green CI for beta
> releases. This vote was invalid because it didn’t reach the vote floor for
> a procedural change but anyway is not inconsistent with knowingly and
> selectively merging work without green CI.
>
> If we reach the summit we should take a look at the state of the PRs and
> make a decision about if they are alpha quality; if so, and we want a
> release, we should simply merge it and release. Making up a new release
> type when the work meets alpha standard to avoid an arbitrary and not
> mandated commit bar seems the definition of silly.
>
> On 31 Oct 2023, at 04:34, J. D. Jordan  wrote:
>
> 
> That is my understanding as well. If the TCM and Accord based on TCM
> branches are ready to commit by ~12/1 we can cut a 5.1 branch and then a
> 5.1-alpha release.
> Where “ready to commit” means our usual things of two committer +1 and
> green CI etc.
>
> If we are not ready to commit then I propose that as long as everything in
> the accord+tcm Apache repo branch has had two committer +1’s, but maybe
> people are still working on fixes for getting CI green or similar, we cut a
> 5.1-preview  build from the feature branch to vote on with known issues
> documented.  This would not be the preferred path, but would be a way to
> have a voted on release for summit.
>
> -Jeremiah
>
> On Oct 30, 2023, at 5:59 PM, Mick Semb Wever  wrote:
>
> 
>
> Hoping we can get clarity on this.
>
> The proposal was, once TCM and Accord merges to trunk,  then immediately
> branch cassandra-5.1 and cut an immediate 5.1-alpha1 release.
>
> This was to focus on stabilising TCM and Accord as soon as it lands, hence
> the immediate branching.
>
> And the alpha release as that is what our Release Lifecycle states it to
> be.
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> My understanding is that there was no squeezing in extra features into 5.1
> after TCM+Accord lands, and there's no need for a "preview" release – we
> move straight to the alpha, as our lifecycle states.  And we will describe
> all usability shortcomings and bugs with the alpha, our lifecycle docs
> permit this, if we feel the need to.
>
> All this said, if TCM does not merge before the Summit, and we want to get
> a release into user hands, it has been suggested we cut a preview release
> 5.1-preview1 off the feature branch.  This is a different scenario, and
> only a mitigation plan.
>
>
>
>
> On Thu, 26 Oct 2023 at 14:20, Benedict  wrote:
>
>> The time to stabilise is orthogonal to the time we branch. Once we branch
>> we stop accepting new features for the branch, and work to stabilise.
>>
>> My understanding is we will branch as soon as we have a viable alpha
>> containing TCM and Accord. That means pretty soon after they land in the
>> project, which we expect to be around the summit.
>>
>> If this isn’t the expectation we should make that clear, as it will
>> affect how this decision is made.
>>
>> On 26 Oct 2023, at 10:14, Benjamin Lerer  wrote:
>>
>> 
>>
>>> Regarding the release of 5.1, I understood the proposal to be that we
>>> cut an actual alpha, thereby sealing the 5.1 release from new features.
>>> Only features merged before we cut the alpha would be permitted, and the
>>> alpha should be cut as soon as practicable. What exactly would we be
>>> waiting for?
>>
>>
>> The problem I believe is about expectations. It seems that your
>> expectation is that a release with only TCM and Accord will reach GA
>> quickly. Based on the time it took us to release 4.1, I am simply expecting
>> more delays (a GA around end of May, June). In which case it seems to me
>> that we could be interested in shipping more stuff in the meantime
>> (thinking of CASSANDRA-15254 or CEP-29 for example).
>> I do not have a strong opinion, I just want to make sure that we all
>> share the same understanding and fully understand what we agree upon.
>>
>> Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a
>> écrit :
>>
>>> I am surprised this needs to be said, but - especially for long-running
 CEPs - you must involve yourself early, and certainly within some
 reasonable time of being notified the work is ready for broader input and
 review. In this case, more than six months ago.
>>>
>>>
>>> It is unfortunately more complicated than that because six month ago
>>> Ekaterina and I were working on supporting Java 17 and dropping Java 8
>>> which was needed by different ongoing works. We both missed the
>>> announcement that TCM was ready for review and anyway would not have been
>>> available at that time. Maxim has asked me ages ago 

Fwd: Upcoming Community Meetings

[Melissa Logan]

Today is the monthly Cassandra contributor meeting at 10:00 PT / 13:00 ET /
17:00 UTC / 22:30 IST.

Piotr Kołaczkowski will share details about CEP-29: CQL Not operator

and
how to use and contribute.

How to join:
https://us02web.zoom.us/j/88568089250?pwd=M1dudnhDajUwbk5UWmkzYWE2MjlsUT09
Meeting ID: 885 6808 9250
Passcode: 182504

Copy the invite from the public Cassandra Community Meeting Calendar:
https://calendar.google.com/calendar/b/1?cid=a2w5cHVoZ2s3cXRkdXFhdHRlOHRmZDVtcHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

See you soon!

-- Forwarded message -
From: Hugh Lashbrooke 
Date: Mon, Oct 23, 2023 at 3:01 PM
Subject: Upcoming Community Meetings
To: 


Hi all,

There are two Apache Cassandra community events coming up this week and
next:

*October Town Hall
* - this month
we'll be hearing from Patrick Lee
 at Walmart about the
interesting things they're doing with Apache Cassandra at scale. This is
happening this week Thursday, October 26 at 8am PT. Find out more and register
here .

*Check out past Town Halls on the YouTube
playlist: 
https://www.youtube.com/playlist?list=PLqcm6qE9lgKKpeO7AgGWcLB6dsz0vS4y1
*


*October Contributor Meeting
* - this month's
Contributor meeting will be a deep dive into CEP-29: CQL Not operator

 with Piotr Kołaczkowski  giving
insight into how the development of this feature for Apache Cassandra 5.0
has been going and what we can expect to see. This is happening next week
Thursday, October 31 at 10am PT. Find out more and register here
.

*Check out past Contributor Meetings on the YouTube **playlist**:
https://www.youtube.com/playlist?list=PLqcm6qE9lgKKls90MlpejceYUU_0qVnWa
*


Hope to see folks there!

Re: Immediately Deprecated Code

[Andrew Weaver]

Skipping versions on upgrade is absolutely something that happens in the
real world.  This is particularly highlighted by the discussion around
5.0/5.1 that's been happening - 5.0 has been described as a potential
"ghost version" which I completely understand.

Getting rid of some of the old cruft that seems unnecessary (and strictly
speaking is unnecessary) is not without its downsides.  In this case, that
cruft improves the user experience.

On Tue, Oct 31, 2023 at 5:56 AM Miklosovic, Stefan via dev <
dev@cassandra.apache.org> wrote:

> Do I understand it correctly that this is basically the case of
> "deprecated on introduction" as we know that it will not be necessary the
> very next version?
>
> I think that not everybody is upgrading from version to version as they
> appear. If somebody upgrades from 4.0 to 5.1 (which we seem to support) (1)
> and you would have introduced the deprecation in 4.0 with intention to
> remove it in 5.0 and somebody jumps to 5.1 straight away, is not that a
> problem? Because they have not made the move via 5.0 where you upgrade
> logic was triggered.
>
> (1)
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L97-L108
>
> 
> From: Claude Warren, Jr via dev 
> Sent: Tuesday, October 31, 2023 10:57
> To: dev
> Cc: Claude Warren, Jr
> Subject: Immediately Deprecated Code
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> I was thinking about code that is used to migrate from one version to
> another.  For example the code that rewrote the order of the hash values
> used for Bloom filters.  That code was necessary for the version it was
> coded in.  But the next version does not need that code because the next
> version is not going to read the data from 2 versions prior to itself.  So
> the code could be removed for verson+1.
>
> So, would it have made sense to annotate those methods (and variables) as
> deprecated since the version they were written in so the methods/variables
> can be removed in the next version?
>
> If so, what I propose is that all transitional methods and variable be
> marked as deprecated with the version in which they were introduced.
>
>

-- 
Andrew Weaver

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

[Claude Warren, Jr via dev]

@henrik,  Have you made any progress on this?  I would like to help drive
it forward but I am waiting to see what your code looks like and figure out
what I need to do.  Any update on timeline would be appreciated.

On Mon, Oct 23, 2023 at 9:07 PM Jon Haddad 
wrote:

> I think this is a great more generally useful than the two scenarios
> you've outlined.  I think it could / should be possible to use an object
> store as the primary storage for sstables and rely on local disk as a cache
> for reads.
>
> I don't know the roadmap for TCM, but imo if it allowed for more stable,
> pre-allocated ranges that compaction will always be aware of (plus a bunch
> of plumbing I'm deliberately avoiding the details on), then you could
> bootstrap a new node by copying s3 directories around rather than streaming
> data between nodes.  That's how we get to 20TB / node, easy scale up /
> down, etc, and always-ZCS for non-object store deployments.
>
> Jon
>
> On 2023/09/25 06:48:06 "Claude Warren, Jr via dev" wrote:
> > I have just filed CEP-36 [1] to allow for keyspace/table storage outside
> of
> > the standard storage space.
> >
> > There are two desires  driving this change:
> >
> >1. The ability to temporarily move some keyspaces/tables to storage
> >outside the normal directory tree to other disk so that compaction can
> >occur in situations where there is not enough disk space for
> compaction and
> >the processing to the moved data can not be suspended.
> >2. The ability to store infrequently used data on slower cheaper
> storage
> >layers.
> >
> > I have a working POC implementation [2] though there are some issues
> still
> > to be solved and much logging to be reduced.
> >
> > I look forward to productive discussions,
> > Claude
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-36%3A+A+Configurable+ChannelProxy+to+alias+external+storage+locations
> > [2] https://github.com/Claudenw/cassandra/tree/channel_proxy_factory
> >
>

Re: Immediately Deprecated Code

[Claude Warren, Jr via dev]

Good point.  When I was thinking about this originally I did realize that
the deprecated tag would need a since = v+1 but I neglected to note that in
my original post.
So in your example the code would be maked as deprecated since v5.0 even
though the code base it is being written in is 4.0.  Thus the code would
not be a candidate for removal until 6.0
I think that this make it easier to remember all those bits that can be
deleted later.

On Tue, Oct 31, 2023 at 11:57 AM Miklosovic, Stefan via dev <
dev@cassandra.apache.org> wrote:

> Do I understand it correctly that this is basically the case of
> "deprecated on introduction" as we know that it will not be necessary the
> very next version?
>
> I think that not everybody is upgrading from version to version as they
> appear. If somebody upgrades from 4.0 to 5.1 (which we seem to support) (1)
> and you would have introduced the deprecation in 4.0 with intention to
> remove it in 5.0 and somebody jumps to 5.1 straight away, is not that a
> problem? Because they have not made the move via 5.0 where you upgrade
> logic was triggered.
>
> (1)
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L97-L108
>
> 
> From: Claude Warren, Jr via dev 
> Sent: Tuesday, October 31, 2023 10:57
> To: dev
> Cc: Claude Warren, Jr
> Subject: Immediately Deprecated Code
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> I was thinking about code that is used to migrate from one version to
> another.  For example the code that rewrote the order of the hash values
> used for Bloom filters.  That code was necessary for the version it was
> coded in.  But the next version does not need that code because the next
> version is not going to read the data from 2 versions prior to itself.  So
> the code could be removed for verson+1.
>
> So, would it have made sense to annotate those methods (and variables) as
> deprecated since the version they were written in so the methods/variables
> can be removed in the next version?
>
> If so, what I propose is that all transitional methods and variable be
> marked as deprecated with the version in which they were introduced.
>
>

Re: Immediately Deprecated Code

[Miklosovic, Stefan via dev]

Do I understand it correctly that this is basically the case of "deprecated on 
introduction" as we know that it will not be necessary the very next version?

I think that not everybody is upgrading from version to version as they appear. 
If somebody upgrades from 4.0 to 5.1 (which we seem to support) (1) and you 
would have introduced the deprecation in 4.0 with intention to remove it in 5.0 
and somebody jumps to 5.1 straight away, is not that a problem? Because they 
have not made the move via 5.0 where you upgrade logic was triggered.

(1) 
https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L97-L108


From: Claude Warren, Jr via dev 
Sent: Tuesday, October 31, 2023 10:57
To: dev
Cc: Claude Warren, Jr
Subject: Immediately Deprecated Code

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



I was thinking about code that is used to migrate from one version to another.  
For example the code that rewrote the order of the hash values used for Bloom 
filters.  That code was necessary for the version it was coded in.  But the 
next version does not need that code because the next version is not going to 
read the data from 2 versions prior to itself.  So the code could be removed 
for verson+1.

So, would it have made sense to annotate those methods (and variables) as 
deprecated since the version they were written in so the methods/variables can 
be removed in the next version?

If so, what I propose is that all transitional methods and variable be marked 
as deprecated with the version in which they were introduced.

Immediately Deprecated Code

[Claude Warren, Jr via dev]

I was thinking about code that is used to migrate from one version to
another.  For example the code that rewrote the order of the hash values
used for Bloom filters.  That code was necessary for the version it was
coded in.  But the next version does not need that code because the next
version is not going to read the data from 2 versions prior to itself.  So
the code could be removed for verson+1.

So, would it have made sense to annotate those methods (and variables) as
deprecated since the version they were written in so the methods/variables
can be removed in the next version?

If so, what I propose is that all transitional methods and variable be
marked as deprecated with the version in which they were introduced.

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

There is no requirement for green CI on alpha. We voted last year to require running all tests before commit and to require green CI for beta releases. This vote was invalid because it didn’t reach the vote floor for a procedural change but anyway is not inconsistent with knowingly and selectively merging work without green CI.If we reach the summit we should take a look at the state of the PRs and make a decision about if they are alpha quality; if so, and we want a release, we should simply merge it and release. Making up a new release type when the work meets alpha standard to avoid an arbitrary and not mandated commit bar seems the definition of silly.On 31 Oct 2023, at 04:34, J. D. Jordan  wrote:That is my understanding as well. If the TCM and Accord based on TCM branches are ready to commit by ~12/1 we can cut a 5.1 branch and then a 5.1-alpha release.Where “ready to commit” means our usual things of two committer +1 and green CI etc.If we are not ready to commit then I propose that as long as everything in the accord+tcm Apache repo branch has had two committer +1’s, but maybe people are still working on fixes for getting CI green or similar, we cut a 5.1-preview  build from the feature branch to vote on with known issues documented.  This would not be the preferred path, but would be a way to have a voted on release for summit.-Jeremiah On Oct 30, 2023, at 5:59 PM, Mick Semb Wever  wrote:Hoping we can get clarity on this.The proposal was, once TCM and Accord merges to trunk,  then immediately branch cassandra-5.1 and cut an immediate 5.1-alpha1 release.This was to focus on stabilising TCM and Accord as soon as it lands, hence the immediate branching.And the alpha release as that is what our Release Lifecycle states it to be.https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle My understanding is that there was no squeezing in extra features into 5.1 after TCM+Accord lands, and there's no need for a "preview" release – we move straight to the alpha, as our lifecycle states.  And we will describe all usability shortcomings and bugs with the alpha, our lifecycle docs permit this, if we feel the need to.All this said, if TCM does not merge before the Summit, and we want to get a release into user hands, it has been suggested we cut a preview release 5.1-preview1 off the feature branch.  This is a different scenario, and only a mitigation plan.  On Thu, 26 Oct 2023 at 14:20, Benedict  wrote:The time to stabilise is orthogonal to the time we branch. Once we branch we stop accepting new features for the branch, and work to stabilise.My understanding is we will branch as soon as we have a viable alpha containing TCM and Accord. That means pretty soon after they land in the project, which we expect to be around the summit.If this isn’t the expectation we should make that clear, as it will affect how this decision is made.On 26 Oct 2023, at 10:14, Benjamin Lerer  wrote:
Regarding the release of 5.1, I 
understood the proposal to be that we cut an actual alpha, thereby 
sealing the 5.1 release from new features. Only features merged before 
we cut the alpha would be permitted, and the alpha should be cut as soon
 as practicable. What exactly would we be waiting for? The problem I believe is about expectations. It seems that your expectation is that a release with only TCM and Accord will reach GA quickly. Based on the time it took us to release 4.1, I am simply expecting more delays (a GA around end of May, June). In which case it seems to me that we could be interested in shipping more stuff in the meantime (thinking of CASSANDRA-15254 or CEP-29 for example).I do not have a strong opinion, I just want to make sure that we all share the same understanding and fully understand what we agree upon.    

Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a écrit :
I am surprised this needs to be said, 
but - especially for long-running CEPs - you must involve yourself 
early, and certainly within some reasonable time of being notified the 
work is ready for broader input and review. In this case, more than six 
months ago.It is unfortunately more complicated than that because six month ago Ekaterina and I were working on supporting Java 17 and dropping Java 8 which was needed by different ongoing works. We both missed the announcement that TCM was ready for review and anyway would not have been available at that time. Maxim has asked me ages ago for a review of 
CASSANDRA-15254  more than 6 months ago and I have not been able to help him so far. We all have a limited bandwidth and can miss some announcements.    

The project has grown and a lot of things are going on in parallel. There are also more interdependencies between the different projects. In my opinion what we are lacking is a global overview of the different things going on in the project and some rough ideas of the status of the different significant pieces. It would allow