Re: [DISCUSS] putting versions into Deprecated annotations

[Miklosovic, Stefan]

If we want to use some description (of type String), we would need to introduce 
a brand new annotation instead of java.lang.Deprecated as that one does not 
have it.

I am in favor of custom annotation instead of using Javadocs for this kind of 
technical documentation. An annotation seems to be more succinct, even it is a 
custom one, rather that using comments for it.

On the other hand, I am not sure how we ensure that developers use this custom 
annotation instead of the in-built one. java.lang package is not a package to 
be imported so we can not have a checkstyle rule for it.


From: Francisco Guerrero 
Sent: Saturday, October 7, 2023 0:54
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] putting versions into Deprecated annotations

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.




> Might be nice to support a 3rd param that's a String for the reason it's 
> deprecated.

Javadocs offers this natively

/**
 * @deprecated Use instance method {@link #newMethod(Param1, Param2...)} 
instead.
 */
@Deprecated

So we could leverage javadocs for this purpose

On 2023/10/06 11:49:52 Josh McKenzie wrote:
> Might be nice to support a 3rd param that's a String for the reason it's 
> deprecated. i.e. "Replaced by X",  "Unmaintained", "Obsolete", "See 
> CASSANDRA-N", link to a dev ML thread on pony mail, etc. That way if 
> someone comes across it in the codebase they have some context to follow up 
> on if it's the shape of a thing they need w/out having to go full-bore w/git 
> blame and JQL.
>
> On Fri, Oct 6, 2023, at 4:43 AM, Miklosovic, Stefan wrote:
> > Hi list,
> >
> > I have a ticket to discuss (1).
> >
> > When we deprecate APIs / methods etc, what I want to suggest is that we 
> > might start to explicitly add the version when that happened. For example, 
> > if you deprecated something which goes to 5.0, would you be so nice to do 
> > this?
> >
> > @Deprecated(since = "5.0")
> >
> > Similarly, that annotation offers one more field - forRemoval, so using it 
> > like this:
> >
> > @Deprecated(since = "5.0", forRemoval = true)
> >
> > means that this is eligible to be deleted in Cassandra 6.0.
> >
> > With this information, it is way more comfortable to just "grep" where we 
> > are at when it comes to deprecations eligible to be deleted in the next 
> > version. Currently, we basically have to go one by one and figure out if it 
> > is not old enough to remove. I believe this would bring more transparency 
> > into what is planned to be removed and when as well it will be clearly 
> > visible what should be removed in the next version and it is not.
> >
> > Tangential question to this is if everything we deprecated is eligible for 
> > removal? In other words, are there any cases when forRemoval would be 
> > false? Could you elaborate on that and give such examples or do you all 
> > think that everything which is deprecated will be eventually removed?
> >
> > (1) https://issues.apache.org/jira/browse/CASSANDRA-18912
> >
> > Thanks and regards
>

Re: [DISCUSS] Gossip shutdown may corrupt peers making it so the cluster never converges, and a small protocol change to fix

[David Capwell]

> Won't the replacement have a newer generation?

The replacement is a different instance.  I performs a shadow round with its 
seeds and if they are impacted by this issue then they are missing tokens, so 
we fail the host replacement… you can work around this by changing the seeds to 
nodes that know the token.

> I don't think it is, this is just fixing a gossip bug, and we should do so in 
> all affected versions.

Right now we sent NoPayload which is 0 bytes, but with the change we send 
GossipShutdown which contains the whole EndpointState… I “feel” like 4.x can 
not handle this but worth a test (after deserializing the message we have extra 
bytes… won’t we get mad about that?)… the gossip handler doesn’t look at the 
payload so as long as 4.x serialization can support this, then it won’t be hard 
to back port to 4.x


> On Oct 6, 2023, at 3:57 PM, Brandon Williams  wrote:
> 
> On Fri, Oct 6, 2023 at 5:50 PM David Capwell  wrote:
>> Lets say you now need to host replace node1
> 
> Won't the replacement have a newer generation?
> 
>> avoid peers mutating endpoint states they don’t own
> 
> This sounds reasonable to me.
> 
>> This would be a protocol change, so would need to make sure everyone is cool 
>> with me doing this in 5.0.>
> 
> I don't think it is, this is just fixing a gossip bug, and we should
> do so in all affected versions.
> 
> Kind Regards,
> Brandon

Re: [DISCUSS] Gossip shutdown may corrupt peers making it so the cluster never converges, and a small protocol change to fix

[Brandon Williams]

On Fri, Oct 6, 2023 at 5:50 PM David Capwell  wrote:
> Lets say you now need to host replace node1

Won't the replacement have a newer generation?

> avoid peers mutating endpoint states they don’t own

This sounds reasonable to me.

> This would be a protocol change, so would need to make sure everyone is cool 
> with me doing this in 5.0.>

I don't think it is, this is just fixing a gossip bug, and we should
do so in all affected versions.

Kind Regards,
Brandon

Re: [DISCUSS] putting versions into Deprecated annotations

[Francisco Guerrero]

> Might be nice to support a 3rd param that's a String for the reason it's 
> deprecated.

Javadocs offers this natively

/**
 * @deprecated Use instance method {@link #newMethod(Param1, Param2...)} 
instead.
 */
@Deprecated

So we could leverage javadocs for this purpose

On 2023/10/06 11:49:52 Josh McKenzie wrote:
> Might be nice to support a 3rd param that's a String for the reason it's 
> deprecated. i.e. "Replaced by X",  "Unmaintained", "Obsolete", "See 
> CASSANDRA-N", link to a dev ML thread on pony mail, etc. That way if 
> someone comes across it in the codebase they have some context to follow up 
> on if it's the shape of a thing they need w/out having to go full-bore w/git 
> blame and JQL.
> 
> On Fri, Oct 6, 2023, at 4:43 AM, Miklosovic, Stefan wrote:
> > Hi list,
> > 
> > I have a ticket to discuss (1). 
> > 
> > When we deprecate APIs / methods etc, what I want to suggest is that we 
> > might start to explicitly add the version when that happened. For example, 
> > if you deprecated something which goes to 5.0, would you be so nice to do 
> > this?
> > 
> > @Deprecated(since = "5.0") 
> > 
> > Similarly, that annotation offers one more field - forRemoval, so using it 
> > like this: 
> > 
> > @Deprecated(since = "5.0", forRemoval = true) 
> > 
> > means that this is eligible to be deleted in Cassandra 6.0. 
> > 
> > With this information, it is way more comfortable to just "grep" where we 
> > are at when it comes to deprecations eligible to be deleted in the next 
> > version. Currently, we basically have to go one by one and figure out if it 
> > is not old enough to remove. I believe this would bring more transparency 
> > into what is planned to be removed and when as well it will be clearly 
> > visible what should be removed in the next version and it is not. 
> > 
> > Tangential question to this is if everything we deprecated is eligible for 
> > removal? In other words, are there any cases when forRemoval would be 
> > false? Could you elaborate on that and give such examples or do you all 
> > think that everything which is deprecated will be eventually removed?
> > 
> > (1) https://issues.apache.org/jira/browse/CASSANDRA-18912
> > 
> > Thanks and regards
> 

[DISCUSS] Gossip shutdown may corrupt peers making it so the cluster never converges, and a small protocol change to fix

[David Capwell]

Just filed https://issues.apache.org/jira/browse/CASSANDRA-18913 (Gossip NPE 
due to shutdown event corrupting empty statuses) which is where I saw this 
issue..

When we do gossip shutdown we send a message GOSSIP_SHUTDOWN which then gets 
handled by this method org.apache.cassandra.gms.Gossiper#markAsShutdown… there 
is a issue with the current implementation; the peers mutate the state for the 
node shutting down, which cause pending gossip events to get ignored!

Simple example of an issue here is the following

Node1 starts up and starts bootstrapping
Node1 joins the ring
Node1 disables gossip (or halts)

In this case some nodes in the cluster will see the joining of the ring, and 
others won’t.  Now, the ones who have seen the gossip shutdown will set the 
version to Integer.MAX_VALUE which will have gossip not sync any unseen states…

Why is this a problem?  Lets say you now need to host replace node1… and the 
seeds you are using didn’t see the join ring event… you then get the following 
error during the host replacement "Could not find tokens for %s to replace”

To solve this and clean things up, I would like to send the state from the node 
shutting down and avoid peers mutating endpoint states they don’t own; with 
this the cluster should eventually converge!  This would be a protocol change, 
so would need to make sure everyone is cool with me doing this in 5.0.

Re: [DISCUSS] putting versions into Deprecated annotations

[Doug Rohrer]

+1 on reason string, especially some way to indicate what replaces a method if 
it’s being moved into some other class/new method with more parameters/etc. 
I’ve found lots of cases (in code bases in general, not C* in particular) where 
something is marked as Deprecated but there’s no mention of a replacement even 
when there is one.

As someone who has spent a bunch of time using parts of Cassandra as a library, 
this would be hugely beneficial, but it would also clearly be useful for 
maintainers of the core codebase.

Doug

> On Oct 6, 2023, at 7:49 AM, Josh McKenzie  wrote:
> 
> Might be nice to support a 3rd param that's a String for the reason it's 
> deprecated. i.e. "Replaced by X",  "Unmaintained", "Obsolete", "See 
> CASSANDRA-N", link to a dev ML thread on pony mail, etc. That way if 
> someone comes across it in the codebase they have some context to follow up 
> on if it's the shape of a thing they need w/out having to go full-bore w/git 
> blame and JQL.
> 
> On Fri, Oct 6, 2023, at 4:43 AM, Miklosovic, Stefan wrote:
>> Hi list,
>> 
>> I have a ticket to discuss (1). 
>> 
>> When we deprecate APIs / methods etc, what I want to suggest is that we 
>> might start to explicitly add the version when that happened. For example, 
>> if you deprecated something which goes to 5.0, would you be so nice to do 
>> this?
>> 
>> @Deprecated(since = "5.0") 
>> 
>> Similarly, that annotation offers one more field - forRemoval, so using it 
>> like this: 
>> 
>> @Deprecated(since = "5.0", forRemoval = true) 
>> 
>> means that this is eligible to be deleted in Cassandra 6.0. 
>> 
>> With this information, it is way more comfortable to just "grep" where we 
>> are at when it comes to deprecations eligible to be deleted in the next 
>> version. Currently, we basically have to go one by one and figure out if it 
>> is not old enough to remove. I believe this would bring more transparency 
>> into what is planned to be removed and when as well it will be clearly 
>> visible what should be removed in the next version and it is not. 
>> 
>> Tangential question to this is if everything we deprecated is eligible for 
>> removal? In other words, are there any cases when forRemoval would be false? 
>> Could you elaborate on that and give such examples or do you all think that 
>> everything which is deprecated will be eventually removed?
>> 
>> (1) https://issues.apache.org/jira/browse/CASSANDRA-18912
>> 
>> Thanks and regards

Re: [VOTE] Accept java-driver

[J. D. Jordan]

The software grant agreement covers all donated code.  The ASF does not need any historical agreements. The agreement giving the ASF copyright etc is the Software Grant Agreement. Yes, any future work done after donation needs to be covered by ASF CLAs.But happy to see someone ask legal@ to confirm this so we can move forward.On Oct 6, 2023, at 3:33 AM, Benedict  wrote:Are we certain about that? It’s unclear to me from the published guidance; would be nice to get legal to weigh in to confirm to make sure we aren’t skipping any steps, as we haven’t been involved until now so haven’t the visibility. At the very least it reads to me that anyone expected to be maintaining the software going forwards should have a CLA on file with ASF, but I’d have expected the ASF to also want a record of the historic CLAs.On 6 Oct 2023, at 09:28, Mick Semb Wever  wrote:On Thu, 5 Oct 2023 at 17:50, Jeremiah Jordan  wrote:
I think this is covered by the grant agreement?https://www.apache.org/licenses/software-grant-template.pdf2. Licensor represents that, to Licensor's knowledge, Licensor is
legally entitled to grant the above license. Licensor agrees to notify
the Foundation of any facts or circumstances of which Licensor becomes
aware and which makes or would make Licensor's representations in this
License Agreement inaccurate in any respect.



On Oct 5, 2023 at 4:35:08 AM, Benedict  wrote:

Surely it needs to be shared with the foundation and the PMC so we can verify? Or at least have ASF legal confirm they have received and are satisfied with the tarball? It certainly can’t be kept private to DS, AFAICT.Of course it shouldn’t be shared publicly but not sure how PMC can fulfil its verification function here without itCorrect, thanks JD.These are CLAs that were submitted to DS, not to ASF.It is DS's legal responsibility to ensure what they are donating they have the right to (i.e. have the copyright), when submitting the SGA.  It's not on the ASF or the PMC to verify this.  Here we're simply demonstrating that we (DS) have done that due diligence, and are keeping record of it. 

Hacktoberfest?

[German Eichberger via dev]

All,

It's that time of year where the Hacktoberfest happens 
again:https://hacktoberfest.com/participation/#maintainers

We would need to mark our repo and also review the contributions timely so the 
participants can earn their T-Shirt (?). As Ekaterina pointed out October is 
also the month were we are crunched for time due to the release but I wanted to 
bring this up to the community anyway to discuss.

Thanks,
German
[https://www.bing.com/th?id=OVP.sZvFxTzWLuCCxgiYyScldQEsCW=Api]
Participation | Hacktoberfest 
2023
Hacktoberfest: a month-long celebration of open-source projects, their 
maintainers, and the entire community of contributors.
hacktoberfest.com

[https://hacktoberfest.com/_next/static/media/opengraph.e5fafe07.png]
Hacktoberfest 2023
Hacktoberfest: a month-long celebration of open-source projects, their 
maintainers, and the entire community of contributors.
hacktoberfest.com

Re: [DISCUSS] putting versions into Deprecated annotations

[Josh McKenzie]

Might be nice to support a 3rd param that's a String for the reason it's 
deprecated. i.e. "Replaced by X",  "Unmaintained", "Obsolete", "See 
CASSANDRA-N", link to a dev ML thread on pony mail, etc. That way if 
someone comes across it in the codebase they have some context to follow up on 
if it's the shape of a thing they need w/out having to go full-bore w/git blame 
and JQL.

On Fri, Oct 6, 2023, at 4:43 AM, Miklosovic, Stefan wrote:
> Hi list,
> 
> I have a ticket to discuss (1). 
> 
> When we deprecate APIs / methods etc, what I want to suggest is that we might 
> start to explicitly add the version when that happened. For example, if you 
> deprecated something which goes to 5.0, would you be so nice to do this?
> 
> @Deprecated(since = "5.0") 
> 
> Similarly, that annotation offers one more field - forRemoval, so using it 
> like this: 
> 
> @Deprecated(since = "5.0", forRemoval = true) 
> 
> means that this is eligible to be deleted in Cassandra 6.0. 
> 
> With this information, it is way more comfortable to just "grep" where we are 
> at when it comes to deprecations eligible to be deleted in the next version. 
> Currently, we basically have to go one by one and figure out if it is not old 
> enough to remove. I believe this would bring more transparency into what is 
> planned to be removed and when as well it will be clearly visible what should 
> be removed in the next version and it is not. 
> 
> Tangential question to this is if everything we deprecated is eligible for 
> removal? In other words, are there any cases when forRemoval would be false? 
> Could you elaborate on that and give such examples or do you all think that 
> everything which is deprecated will be eventually removed?
> 
> (1) https://issues.apache.org/jira/browse/CASSANDRA-18912
> 
> Thanks and regards

Re: [DISCUSSION] Cassandra's code style and source code analysis

[Maxim Muzafarov]

Hello everyone,

Some updates.
There are issues that we have put on hold, waiting for the CEPs to be
finalized. The java imports are one of these issues, let's do not
forget them ^^

I've created a label to track it:
https://issues.apache.org/jira/issues/?jql=labels%20%3D%20code-polishing

On Tue, 1 Aug 2023 at 10:46, Miklosovic, Stefan
 wrote:
>
> I think we might wait for Accord and transactional metadata as the last big 
> contributions in 5.0 (if I have not forgotten something) and then we can just 
> polish it all just before the release. There will be still some room to do 
> the housekeeping like this after these patches lend. It is not like Accord 
> will be in trunk on Monday and we release Tuesday ...
>
> 
> From: Maxim Muzafarov 
> Sent: Monday, July 31, 2023 23:05
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>
> 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.
>
>
>
>
> Hello everyone,
>
>
> It's been a long time since the last discussion about the import order
> code style, so I want to give these changes a chance as all the major
> JIRA issues have already landed on the release branch so we won't
> affect anyone. I'd be happy to find any reviewers who are interested
> in helping with the next steps :-) I've updated the changes to reflect
> the latest checkstyle work, so here they are:
>
> https://issues.apache.org/jira/browse/CASSANDRA-17925
> https://github.com/apache/cassandra/pull/2108
>
>
> The changes look scary at first glance, but they're actually quite
> simple and in line with what we've discussed above. In short, we can
> divide all the affected files into two parts: the update of the code
> style configuration files (checkstyle + IDE configs), and the update
> of all the sources to match the code style.
>
> In short:
>
> - "import order" hotkey will work regardless of which IDE you are using;
> - updated checkstyle configuration, and IDEA, Eclipse, NetBeans
> configurations have been updated;
> - AvoidStarImport checkstyle rule applied as well;
>
> The import order we've agreed upon:
>
> java.*
> [blank line]
> javax.*
> [blank line]
> com.*
> [blank line]
> net.*
> [blank line]
> org.*
> [blank line]
> org.apache.cassandra.*
> [blank line]
> all other imports
> [blank line]
> static all other imports
>
> On Mon, 27 Feb 2023 at 13:26, Maxim Muzafarov  wrote:
> >
> > > I suppose it can be easy for the existing feature branches if they have a 
> > > single commit. Don't we need to adjust each commit for multi-commit 
> > > feature branches?
> >
> > It depends on how feature branches are maintained and developed, I
> > guess. My thoughts here are that the IDE's hotkeys should just work to
> > resolve any code-style issues that arise during rebase/maintenance.
> > I'm not talking about enforcing all our code-style rules but giving
> > developers good flexibility. The classes import order rule might be a
> > good example here.
> >
> > On Wed, 22 Feb 2023 at 21:27, Jacek Lewandowski
> >  wrote:
> > >
> > > I suppose it can be easy for the existing feature branches if they have a 
> > > single commit. Don't we need to adjust each commit for multi-commit 
> > > feature branches?
> > >
> > > śr., 22 lut 2023, 19:48 użytkownik Maxim Muzafarov  
> > > napisał:
> > >>
> > >> Hello everyone,
> > >>
> > >> I have created an issue CASSANDRA-18277 that may help us move forward
> > >> with code style changes. It only affects the way we store the IntelliJ
> > >> code style configuration and has no effect on any current (or any)
> > >> releases, so it should be safe to merge. So, once the issue is
> > >> resolved, every developer that checkouts a release branch will use the
> > >> same code style stored in that branch. This in turn makes rebasing a
> > >> big change like the import order [1] a really straightforward matter
> > >> (by pressing Crtl + Opt + O in their local branch to organize
> > >> imports).
> > >>
> > >> See:
> > >>
> > >> Move the IntelliJ Idea code style and inspections configuration to the
> > >> project's root .idea directory
> > >> https://issues.apache.org/jira/browse/CASSANDRA-18277
> > >>
> > >>
> > >>
> > >> [1] https://issues.apache.org/jira/browse/CASSANDRA-17925
> > >>
> > >> On Wed, 25 Jan 2023 at 13:05, Miklosovic, Stefan
> > >>  wrote:
> > >> >
> > >> > Thank you Maxim for doing this.
> > >> >
> > >> > It is nice to see this effort materialized in a PR.
> > >> >
> > >> > I would wait until bigger chunks of work are committed to trunk (like 
> > >> > CEP-15) to not collide too much. I would say we can postpone doing 
> > >> > this until the actual 5.0 release, last weeks before it so we would 
> > >> > not clash with any work people would like to include in 5.0. This can 
> > >> > go in anytime, basically.
> > >> >
> > >> > Are people on the same page?
> > >> >
> 

[DISCUSS] putting versions into Deprecated annotations

[Miklosovic, Stefan]

Hi list,

I have a ticket to discuss (1). 

When we deprecate APIs / methods etc, what I want to suggest is that we might 
start to explicitly add the version when that happened. For example, if you 
deprecated something which goes to 5.0, would you be so nice to do this?

@Deprecated(since = "5.0") 

Similarly, that annotation offers one more field - forRemoval, so using it like 
this: 

@Deprecated(since = "5.0", forRemoval = true) 

means that this is eligible to be deleted in Cassandra 6.0. 

With this information, it is way more comfortable to just "grep" where we are 
at when it comes to deprecations eligible to be deleted in the next version. 
Currently, we basically have to go one by one and figure out if it is not old 
enough to remove. I believe this would bring more transparency into what is 
planned to be removed and when as well it will be clearly visible what should 
be removed in the next version and it is not. 

Tangential question to this is if everything we deprecated is eligible for 
removal? In other words, are there any cases when forRemoval would be false? 
Could you elaborate on that and give such examples or do you all think that 
everything which is deprecated will be eventually removed?

(1) https://issues.apache.org/jira/browse/CASSANDRA-18912

Thanks and regards

Re: [VOTE] Accept java-driver

[Benedict]

Are we certain about that? It’s unclear to me from the published guidance; would be nice to get legal to weigh in to confirm to make sure we aren’t skipping any steps, as we haven’t been involved until now so haven’t the visibility. At the very least it reads to me that anyone expected to be maintaining the software going forwards should have a CLA on file with ASF, but I’d have expected the ASF to also want a record of the historic CLAs.On 6 Oct 2023, at 09:28, Mick Semb Wever  wrote:On Thu, 5 Oct 2023 at 17:50, Jeremiah Jordan  wrote:
I think this is covered by the grant agreement?https://www.apache.org/licenses/software-grant-template.pdf2. Licensor represents that, to Licensor's knowledge, Licensor is
legally entitled to grant the above license. Licensor agrees to notify
the Foundation of any facts or circumstances of which Licensor becomes
aware and which makes or would make Licensor's representations in this
License Agreement inaccurate in any respect.



On Oct 5, 2023 at 4:35:08 AM, Benedict  wrote:

Surely it needs to be shared with the foundation and the PMC so we can verify? Or at least have ASF legal confirm they have received and are satisfied with the tarball? It certainly can’t be kept private to DS, AFAICT.Of course it shouldn’t be shared publicly but not sure how PMC can fulfil its verification function here without itCorrect, thanks JD.These are CLAs that were submitted to DS, not to ASF.It is DS's legal responsibility to ensure what they are donating they have the right to (i.e. have the copyright), when submitting the SGA.  It's not on the ASF or the PMC to verify this.  Here we're simply demonstrating that we (DS) have done that due diligence, and are keeping record of it. 

Re: [VOTE] Accept java-driver

[Mick Semb Wever]

On Thu, 5 Oct 2023 at 17:50, Jeremiah Jordan 
wrote:

> I think this is covered by the grant agreement?
>
> https://www.apache.org/licenses/software-grant-template.pdf
>
> 2. Licensor represents that, to Licensor's knowledge, Licensor is
> legally entitled to grant the above license. Licensor agrees to notify
> the Foundation of any facts or circumstances of which Licensor becomes
> aware and which makes or would make Licensor's representations in this
> License Agreement inaccurate in any respect.
>
>
>
> On Oct 5, 2023 at 4:35:08 AM, Benedict  wrote:
>
>> Surely it needs to be shared with the foundation and the PMC so we can
>> verify? Or at least have ASF legal confirm they have received and are
>> satisfied with the tarball? It certainly can’t be kept private to DS,
>> AFAICT.
>>
>> Of course it shouldn’t be shared publicly but not sure how PMC can fulfil
>> its verification function here without it
>>
>

Correct, thanks JD.

These are CLAs that were submitted to DS, not to ASF.

It is DS's legal responsibility to ensure what they are donating they have
the right to (i.e. have the copyright), when submitting the SGA.  It's not
on the ASF or the PMC to verify this.  Here we're simply demonstrating that
we (DS) have done that due diligence, and are keeping record of it.