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

[Miklosovic, Stefan]

Should the source code obey the AvoidStarImport rule?

yes

 Should we implement AvoidStarImport and CustomImportOrder in a
single pull request or do it one by one?

Technically it can be two commits which would be merged / pushed at once.

One thing which needs extra care for ordering imports is that if you order it 
in IDEA by right-clicking on a package and choosing organising imports, it will 
remove special comments which are put at the end of the import statement. We 
need to be sure you put them back.  Look at changes in CASSANDRA-17055. We need 
to preserve this.

Also, we need to be sure that the importing style can be (roughly) set in each 
major IDE. (eclipse / netbeans / idea) so if we require some import style it 
can be set in IDE like that. I do not know if we have any strong preference 
when it comes to this but it definitely does not hurt.

Also, I see that the current import style is

java
[blank line]
com.google.common
org.apache.commons
org.junit
org.slf4j
[blank line]
everything else alphabetically

I think this is a great time to revisit this ordering. I am not particularly 
persuaded on this order and why it was choosen. Where has that decision come 
from?


From: Maxim Muzafarov 
Sent: Wednesday, December 7, 2022 18:29
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.




Dear community,


I have created the epic with code-style activities to track the progress:
https://issues.apache.org/jira/browse/CASSANDRA-18090

In my understanding, there is no need to format whole the code base at
once according to the code style described on the page [1], and the
best strategy here is to go forward with small evolutionary changes.
Thus eventually we will come up with a set of rules convenient for all
members of the community. In my mind, having one commit per an added
code style rule should be easy to look at for a reviewer, the git
commits history as well as rebasing/merging other pull requests that
may be affected by the new rules.


I want to raise one more question related to class imports and the
classses import order for a wider discussion. The import order is well
described on the code style page [1], but using wildcard imports is
not mentioned at all. The wildcard imports with their drawbacks has
has already been raised in the JIRA issue [2] and didn't get enough
attention.

The checkstyle has the rules we are interested in for import control
and they must be considered together. We can implement them in a
single pull request or one by one, or use only the last one:
- AvoidStarImport
- CustomImportOrder

But still, I think that wildcard imports have more disadvantages
(class names conflicts e.g. java.util.*, java.sql.* or a new version
of a library has name clashes) than advantages and such problems will
be found in later CI cycles.
Currently, I've implemented the AvoidStarImport checkstyle rule in a
dedicated pull request [3][4], so you will be able to see all amount
of the changes with removing wildcard imports. The changes are made
for the checkstyle configuration as well as for code style
configurations for different IDEs we supported.

So, the open questions here are:

- Should the source code obey the AvoidStarImport rule [3]? (I think yes);
- Should we implement AvoidStarImport and CustomImportOrder in a
single pull request or do it one by one?


Anyway, I will fix the result of the agreement over the
AvoidStarImport rule on the documentation page [1].



[1] https://cassandra.apache.org/_/development/code_style.html
[2] https://issues.apache.org/jira/browse/CASSANDRA-17925
[3] https://issues.apache.org/jira/browse/CASSANDRA-18089
[4] https://github.com/apache/cassandra/pull/2041

On Thu, 1 Dec 2022 at 11:55, Claude Warren, Jr via dev
 wrote:
>
> The last time I worked on a project that tried to implement a coding style 
> across the project it was "an education".  The short story is that trying to 
> "mitigate" the code base, with respect to style, is either a massive change 
> or a long slow process.
>
> Arguments here have stated that earlier attempts to have the tooling reformat 
> the code did not go well.  What we ended up doing was turned on the style 
> checker and looked at the number of issues across the project.  When new code 
> was accepted the number of issues could not rise.  Eventually most of the 
> code was clean, with a few well coded legacy bits still not up to standard.  
> We could do something similar here.  Much like code coverage, you can't 
> perform a merge unless the number of style errors remains the same or 
> decreases.
>
> As with all software rules, this is a strong recommendation as I am certain 
> that there are edge/corner case exceptions to be found.
>
>
>
>
> On Wed, Nov 30, 2022 at 3:30 PM 

Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

[Mick Semb Wever]

>
> Could we defer the close of this vote til Monday, December 12th after 6pm
> Pacific Time?
>


Yes.

Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

[Abe Ratnofsky]

Sorry - responded on the take1 thread:

Could we defer the close of this vote til Monday, December 12th after 6pm 
Pacific Time?

Jon Meredith and I have been working thru an issue blocking streaming on 4.1 
for the last couple months, and are now testing a promising fix. We're 
currently working on a write-up, and we'd like to hold the release until the 
community is able to review our findings.

Thanks,
Abe

> On Dec 9, 2022, at 4:11 PM, guo Maxwell  wrote:
> 
> +1
> 
> Jeremiah D Jordan  >于2022年12月10日 周六上午5:59写道：
> +1 nb
> 
> 
>> On Dec 7, 2022, at 3:40 PM, Mick Semb Wever > > wrote:
>> 
>> 
>> Proposing the (second) test build of Cassandra 4.1.0 for release.
>> 
>> sha1: f9e033f519c14596da4dc954875756a69aea4e78
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative
>>  
>> 
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1282/org/apache/cassandra/cassandra-all/4.1.0/
>>  
>> 
>> 
>> 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.1.0/ 
>> 
>> 
>> The vote will be open for 96 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.1.0-tentative
>>  
>> 
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.1.0-tentative
>>  
>> 
> 
> -- 
> you are the apple of my eye !

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

[Abe Ratnofsky]

Could we defer the close of this vote til Monday, December 12th after 6pm 
Pacific Time?

Jon Meredith and I have been working thru an issue blocking streaming on 4.1 
for the last couple months, and are now testing a promising fix. We're 
currently working on a write-up, and we'd like to hold the release until the 
community is able to review our findings.

Thanks,
Abe

> On Dec 9, 2022, at 5:13 AM, Marianne Lyne Manaog  
> wrote:
> 
> Hi everyone, 
> 
> Matt and I finished running all the tests for V2 with the bug fixes from 
> CASSANDRA-18086  and 
> the results for the 100 partitions are definitely better than V1. For the 
> larger partitions (1000, 1), the results for V2 are comparable and 
> overall V2 did not have any performance regression.
> 
> On Thu, Dec 8, 2022 at 11:58 AM Marianne Lyne Manaog 
> mailto:marianne.man...@ieee.org>> wrote:
> Hi everyone, 
> 
> Matt and I finished running all the tests for V2 with the bug fixes from 
> CASSANDRA-18086  and 
> the results for the 100 partitions are definitely better than V1. For the 
> larger partitions (1000, 1), the results for V2 are comparable and 
> overall V2 did not have any performance regression.
> 
> On Tue, Dec 6, 2022 at 4:49 PM Marianne Lyne Manaog  > wrote:
> Here is CASSANDRA-18097 
>  with the bug fix for 
> the performance regression encountered with 100 partitions in V2.
> 
> On Mon, Dec 5, 2022 at 2:05 PM Marianne Lyne Manaog  > wrote:
> Following on what Matt said:
>   - Here is the link to the Cassandra repo with the bugfix of wait time 
> from ms to ns: 
> https://github.com/apache/cassandra/compare/trunk...marianne-manaog:cassandra:bugfix/wait-from-ms-to-ns
>  
> 
>   - the Paxos configuration used is:
>   paxos_contention_wait_randomizer: uniform
>   paxos_contention_min_wait: 0
>   paxos_contention_max_wait: 100ms
> 
>   - V1 and V2 have the same configurations except for paxos_variant: 
> which changes accordingly
> 
>   Results: V1 (100 partitions)
>   - Average read: 28948
>   - Standard Deviation: 416.271
>   - Coefficient of variance: 1.44%
>   - Average write: 19248
>   - Standard Deviation:158.595
>   - Coefficient of variance:0.82%
> 
>   Results: V2 (100 partitions)
>   - Average read: 12307
>   - Standard Deviation: 2367.473
>   - Coefficient of variance: 19.24%
>   - Average write: 5780
>   - Standard Deviation: 1154.261
>   - Coefficient of variance: 19.97%
> 
> 
> On Mon, Dec 5, 2022 at 1:50 PM Matt Fleming  > wrote:
> Me and Marianne are also still chasing a performance issue with Paxos v2 when 
> compared with v1. We
> see way more contention on v2 for a LOCAL_SERIALIZABLE workload that 
> writes/reads to only 100 
> partitions (v2 performs better for higher partition counts). We're still 
> investigating what's going
> on.
> 
> Should that be a -1 vote? I'm not sure :)
> 
> On Mon, 5 Dec 2022 at 11:37, Benedict  > wrote:
> -0 
> 
> CASSANDRA-18086 should probably be fixed and merged first, as Paxos v2 will 
> be unlikely to work well for users without it. Either that or we need to 
> update NEWS.txt to mention it.
> 
>> On 5 Dec 2022, at 11:01, Aleksey Yeshchenko > > wrote:
>> 
>> +1
>> 
>>> On 5 Dec 2022, at 10:17, Benjamin Lerer >> > wrote:
>>> 
>>> +1
>>> 
>>> Le lun. 5 déc. 2022 à 11:02, Berenguer Blasi >> > a écrit :
>>> +1
>>> 
>>> On 5/12/22 10:53, guo Maxwell wrote:
 +1 
 
 Mick Semb Wever mailto:m...@apache.org>>于2022年12月5日 
 周一下午5:33写道：
 
 Proposing the test build of Cassandra 4.1.0 GA for release.
 
 sha1: b807f97b37933fac251020dbd949ee8ef245b158
 Git: 
 https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative
  
 
 Maven Artifacts: 
 https://repository.apache.org/content/repositories/orgapachecassandra-1281/org/apache/cassandra/cassandra-all/4.1.0/
  
 
 
 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.1.0/ 
 
 
 The vote will be open for 72 hours (longer if needed). Everyone who has 
 tested the build is invited to vote. Votes by PMC