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

[Benedict]

Why are we still debating build tooling? I think you’re wrong, but I’ve 
conceded - on the assumption that we can get enough volunteers willing to adopt 
responsibility for the new world order.

I suggest five long term contributors nominate themselves as the build file 
maintainers, and collectively manage a safe and painless migration for the rest 
of us - and agree to maintain and develop the new build file going forwards, 
and support the community as they adopt it.

On the topic of over-exuberant linting I will continue to push back. I think 
linting our brace rules could make sense since they are atypical, but more 
formatting rules than this likely just leads to atrophying style. Authorship 
involves thinking about how to present your code; I don’t want to either 
encourage lazy authorship or prevent experimentation with presentation. Both 
would be bad, and I expect we would struggle to evolve our style guide again in 
future as the language evolves. Our brace rules are a good example everyone 
unilaterally ignored when lambdas arrived, as we all recognised they materially 
harmed the brevity benefits, and we eventually codified this.

On migration: auto formatters applied to code that was not written with the 
rules in mind will almost unerringly be made a mess of, so having a tool do 
this is not acceptable IMO.

The idea of checkstyle being the source of truth continues to be untenable and 
anyone still pushing for this should please engage with my earlier points on 
this.


> On 30 Nov 2022, at 04:06, Patrick McFadin  wrote:
> 
> 
> I'm going to +1 what Stefan has said. I've heard on many occasions from 
> newcomers to the project that having to use Ant is a deterrent. As a matter 
> of fact, a few weeks ago, I spent a Sunday afternoon helping somebody trying 
> to build Cassandra and Ant caused a ton of problems. "Ok. ant really super 
> clean this time"
> 
> Sure it still works for people that have been doing this for years. I drive a 
> 20 year old Toyota truck, but I'm reminded by my kids often that it's not 
> cool. So in that spirit, I feel my saying we need to keep Ant is like saying 
> "You kids get off my lawn!" If it's something that will help attract new 
> contributors, I'm all for it. 
> 
> Patrick
> 
>> On Fri, Nov 25, 2022 at 2:22 AM Miklosovic, Stefan 
>>  wrote:
>> I agree with what you wrote. How I understand it is that migrating to 
>> Maven/Gradle makes the project more "attractive" for newcomers. If a project 
>> is built on "that old un-cool Ant", it might be a little bit off-putting and 
>> questionable if we are "stuck in the past on build systems and not 
>> progressing".
>> 
>> So in that sense I agree this is more "marketing" rather than technological 
>> question but on the other hand, does not Maven/Gradle allow us to modularize 
>> the project better? Maybe we would like to modularize but nobody is up to 
>> that because build system makes it impossible or at least quite inconvenient 
>> to do so. Do you really think there are not any significant benefits to 
>> switch even if it "just works" now?
>> 
>> 
>> From: Benedict 
>> Sent: Friday, November 25, 2022 11:07
>> 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.
>> 
>> 
>> 
>> 
>> There’s always a handful of people asking for it, but notably few if any of 
>> the full time contributors doing the majority of the core development of 
>> Cassandra. It strikes me as something very appealing to others, but less so 
>> to those wanting to get on with development.
>> 
>> I never really see a good argument articulated for the migration, besides 
>> general hand waving that ant is old, and people like newer build systems. 
>> Ant is working fine, so there isn’t a strong technical reason to replace it, 
>> and there are good organisational reasons not to.
>> 
>> Why do you consider a migration inevitable?
>> 
>> 
>> 
>> > On 25 Nov 2022, at 09:58, Miklosovic, Stefan 
>> >  wrote:
>> >
>> > Interesting take on Ant / no-Ant, Benedict. I am very curious how this 
>> > unfolds. My long-term perception is that changing it to something else is 
>> > more or less inevitable but if there is a broader consensus to not do that 
>> >  well.
>> >
>> > 
>> > From: Benedict 
>> > Sent: Friday, November 25, 2022 10:52
>> > 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.
>> >
>> >
>> >
>> >
>> > I was in a bit of a rush last night. I should say that I’m of course +1 a 
>> > general endeavour to clean t

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

[Miklosovic, Stefan]

I again agree with Benedict when it comes to the code formatters. It will 
certainly bring a lot of mess to the code base and for what benefit? I think I 
am looking into the Cassandra code long enough to see that we are progressively 
making it look better. It seems to me that over last few years there was the 
influx of top-notch developers to the project (not saying the previous 
generation was less "talented", that is not my point at all) and I feel that we 
are taking great care of how the code looks like while doing reviews and so on. 
I feel like, lets say, 8 years ago, the development was way more "wild" and 
"how it looks" was more of an afterthought rather than something inherently 
considerate during reviews / contribution. One can feel the difference when 
looking into the newer subsystems almost immediately.

Massively formatting the code would just bring unnecessary big-bang effect for 
what benefit actually ... Lets just do this naturally. It is something 
different to fix unused imports or order them the same way, same as introducing 
spotbugs. But I am big -1 for formatting the code as a whole in one go if that 
is what we are contemplating about to do as well as I am against to try to 
change the current code and / or make build-time rules about how the code 
should look like. I doubt we will ever introduce a reasonable set of rules 
without changing a lot of already existing code in order to comply with that 
policy.

When it comes to build systems, what I would like to see is to do some 
"feasability-study" - how much time it would take, what has to change, how 
Jenkins would look like ... basically what effort we are talking about there. 
Maybe it could be as simple as trying to have compillable Maven / Gradle 
project and nothing else so people could gradually add to that. And maybe once 
we will flip the switch, who knows.


From: Benedict 
Sent: Wednesday, November 30, 2022 10: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.



Why are we still debating build tooling? I think you’re wrong, but I’ve 
conceded - on the assumption that we can get enough volunteers willing to adopt 
responsibility for the new world order.

I suggest five long term contributors nominate themselves as the build file 
maintainers, and collectively manage a safe and painless migration for the rest 
of us - and agree to maintain and develop the new build file going forwards, 
and support the community as they adopt it.

On the topic of over-exuberant linting I will continue to push back. I think 
linting our brace rules could make sense since they are atypical, but more 
formatting rules than this likely just leads to atrophying style. Authorship 
involves thinking about how to present your code; I don’t want to either 
encourage lazy authorship or prevent experimentation with presentation. Both 
would be bad, and I expect we would struggle to evolve our style guide again in 
future as the language evolves. Our brace rules are a good example everyone 
unilaterally ignored when lambdas arrived, as we all recognised they materially 
harmed the brevity benefits, and we eventually codified this.

On migration: auto formatters applied to code that was not written with the 
rules in mind will almost unerringly be made a mess of, so having a tool do 
this is not acceptable IMO.

The idea of checkstyle being the source of truth continues to be untenable and 
anyone still pushing for this should please engage with my earlier points on 
this.


On 30 Nov 2022, at 04:06, Patrick McFadin  wrote:


I'm going to +1 what Stefan has said. I've heard on many occasions from 
newcomers to the project that having to use Ant is a deterrent. As a matter of 
fact, a few weeks ago, I spent a Sunday afternoon helping somebody trying to 
build Cassandra and Ant caused a ton of problems. "Ok. ant really super clean 
this time"

Sure it still works for people that have been doing this for years. I drive a 
20 year old Toyota truck, but I'm reminded by my kids often that it's not cool. 
So in that spirit, I feel my saying we need to keep Ant is like saying "You 
kids get off my lawn!" If it's something that will help attract new 
contributors, I'm all for it.

Patrick

On Fri, Nov 25, 2022 at 2:22 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
I agree with what you wrote. How I understand it is that migrating to 
Maven/Gradle makes the project more "attractive" for newcomers. If a project is 
built on "that old un-cool Ant", it might be a little bit off-putting and 
questionable if we are "stuck in the past on build systems and not progressing".

So in that sense I agree this is more "marketing" rather than technological 
question but on the other hand, does not Maven

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

[Patrick McFadin]

Why are we still debating build tooling? I think you’re wrong, but I’ve
conceded - on the assumption that we can get enough volunteers willing to
adopt responsibility for the new world order.

Not debating. I am just throwing in my support since I have been in the
Camp of Ant.

On Wed, Nov 30, 2022 at 1:29 AM Benedict  wrote:

> Why are we still debating build tooling? I think you’re wrong, but I’ve
> conceded - on the assumption that we can get enough volunteers willing to
> adopt responsibility for the new world order.
>
> I suggest five long term contributors nominate themselves as the build
> file maintainers, and collectively manage a safe and painless migration for
> the rest of us - and agree to maintain and develop the new build file going
> forwards, and support the community as they adopt it.
>
> On the topic of over-exuberant linting I will continue to push back. I
> think linting our brace rules could make sense since they are atypical, but
> more formatting rules than this likely just leads to atrophying style.
> Authorship involves thinking about how to present your code; I don’t want
> to either encourage lazy authorship or prevent experimentation with
> presentation. Both would be bad, and I expect we would struggle to evolve
> our style guide again in future as the language evolves. Our brace rules
> are a good example everyone unilaterally ignored when lambdas arrived, as
> we all recognised they materially harmed the brevity benefits, and we
> eventually codified this.
>
> On migration: auto formatters applied to code that was not written with
> the rules in mind will almost unerringly be made a mess of, so having a
> tool do this is not acceptable IMO.
>
> The idea of checkstyle being the source of truth continues to be untenable
> and anyone still pushing for this should please engage with my earlier
> points on this.
>
>
> On 30 Nov 2022, at 04:06, Patrick McFadin  wrote:
>
> 
> I'm going to +1 what Stefan has said. I've heard on many occasions from
> newcomers to the project that having to use Ant is a deterrent. As a matter
> of fact, a few weeks ago, I spent a Sunday afternoon helping somebody
> trying to build Cassandra and Ant caused a ton of problems. "Ok. ant really
> super clean this time"
>
> Sure it still works for people that have been doing this for years. I
> drive a 20 year old Toyota truck, but I'm reminded by my kids often that
> it's not cool. So in that spirit, I feel my saying we need to keep Ant is
> like saying "You kids get off my lawn!" If it's something that will help
> attract new contributors, I'm all for it.
>
> Patrick
>
> On Fri, Nov 25, 2022 at 2:22 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
>> I agree with what you wrote. How I understand it is that migrating to
>> Maven/Gradle makes the project more "attractive" for newcomers. If a
>> project is built on "that old un-cool Ant", it might be a little bit
>> off-putting and questionable if we are "stuck in the past on build systems
>> and not progressing".
>>
>> So in that sense I agree this is more "marketing" rather than
>> technological question but on the other hand, does not Maven/Gradle allow
>> us to modularize the project better? Maybe we would like to modularize but
>> nobody is up to that because build system makes it impossible or at least
>> quite inconvenient to do so. Do you really think there are not any
>> significant benefits to switch even if it "just works" now?
>>
>> 
>> From: Benedict 
>> Sent: Friday, November 25, 2022 11:07
>> 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.
>>
>>
>>
>>
>> There’s always a handful of people asking for it, but notably few if any
>> of the full time contributors doing the majority of the core development of
>> Cassandra. It strikes me as something very appealing to others, but less so
>> to those wanting to get on with development.
>>
>> I never really see a good argument articulated for the migration, besides
>> general hand waving that ant is old, and people like newer build systems.
>> Ant is working fine, so there isn’t a strong technical reason to replace
>> it, and there are good organisational reasons not to.
>>
>> Why do you consider a migration inevitable?
>>
>>
>>
>> > On 25 Nov 2022, at 09:58, Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com> wrote:
>> >
>> > Interesting take on Ant / no-Ant, Benedict. I am very curious how this
>> unfolds. My long-term perception is that changing it to something else is
>> more or less inevitable but if there is a broader consensus to not do that
>>  well.
>> >
>> > 
>> > From: Benedict 
>> > Sent: Friday, November 25, 2022 10:52
>> > To: dev@cassandra.apache.org
>> > Subject: Re

Re: Cassandra Summit CFP update

[Scott Hirleman]

To come over the top on this, speaking can be great for your career and
company. And Patrick will help you find a great topic. And you only have to
deal with him for 15min, which is _mostly_ doable ;p

If you need help getting internal approvals - communications or potentially
even budget -, we have a CFP Concierge that can partner with you to try to
get you over the line.

Since these lists are mostly technical people, a talk can be a great chance
to partner with someone in your organization on the business and/or
engineering exec side to tell the story of something awesome you built
enabled by Cassandra. So leverage it to get some visibility internally for
the awesome work you are doing.

Again, you can easily grab time with Patrick to find a topic that would
make a great talk. He loves doing this stuff. So if you are on the fence,
why not submit? If you aren't sure if you'll get approved, is there a harm
in submitting what would be an awesome talk? Maybe a 30min harm to your
schedule at most?

Patrick 15min CFP consult (seriously, take advantage, he'll get you excited
about your topic):
https://calendly.com/patrick-mcfadin/15-minute-cassandra-summit-cfp-consult

On Tue, Nov 29, 2022 at 12:53 PM Patrick McFadin  wrote:

>
>
>
>
>
>
>
>
>
> *Hi everyone,An update on the current CFP process for Cassandra
> Summit. There are currently 23 talk submissions which are far behind what
> we need. Two days of tracks mean we need 60 approved talks. Ideally, we
> need over 100 submitted to ensure we have a good pool of quality talks. We
> already have quite a few vendor pitches that have nothing to do with
> Cassandra. Think of it as like CFP
> spam. https://events.linuxfoundation.org/cassandra-summit/program/cfp/
> The
> deadline is December 11th. That is 12 days! If you are assuming that will
> get pushed out, don’t. We have a tight schedule before March 13th. Speakers
> must be notified of talk acceptance by the beginning of January to book
> travel in time. The full schedule will be published by mid-January. That
> being said, I have talked to quite a few people that are working on a
> submission. Thank you for being willing to create a talk! How can I help
> you get it completed? Again, here is my Calendly link if you need to talk
> it over:
> https://calendly.com/patrick-mcfadin/15-minute-cassandra-summit-cfp-consult
> This
> is our conference! Let’s make it a festival of the database we love and the
> things we build with it. One more thing. We need sponsors! If your employer
> can, this is a great opportunity to get your brand out in front of people
> building the future. I’ll be back. Go submit a talk. You’ll be happy you
> did! Patrick*
>


-- 
Scott Hirleman
scott.hirle...@gmail.com

Cassandra project status update 2022-11-30

[Josh McKenzie]

The Cassandra 4.1-rc1 is out - give it a whirl and see how things go: 
https://downloads.apache.org/cassandra/4.1-rc1/

Top level, I want to call attention to the CFP for the Cassandra Summit. 
Patrick McFadin and Scott Hirleman reached out about proposing a talk; we're at 
23 submissions with a target of over 100 to get sufficient volume to fill the 
two days of tracks. Deadline is December 11th, so please take a bit to put 
together a CFP if you're planning on attending the summit and have something 
you'd be interested in sharing with the community: 
https://lists.apache.org/thread/sbn6q6pop537l69vvrj0vz9j6xt6w24w

In terms of work in flight and where we need some help, we have a few tickets 
that need committer attention: 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20resolution%20%3D%20unresolved%20and%20status%20%3D%20%22Needs%20Committer%22

CASSANDRA-17997: Improve git branch handling for CircleCI generate.sh
CASSANDRA-17861: Update Python test framework from nose to pytest in CCM
CASSANDRA-14930: decommission may cause timeout because messaging backlog is 
cleared

If you're a committer with some spare minutes please take a look at one of the 
above and see if you can help unstick them.

In terms of 4.1 status, we're in RC so ideally nothing will get merged and 
we'll go to GA in the near future. Great work everyone!

And in other tickets that could use some attention, we have a number of tickets 
(19 on 4.0.x and 36 on 4.x) that could use reviewers - either they're patch 
available with no reviewer or in progress without one: 
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&selectedIssue=CASSANDRA-17251&quickFilter=2259


[New Contributors Getting Started]
We have a curated list of tickets on the core Cassandra codebase we've flagged 
as being good starter tickets - we currently have 12 of them unassigned on our 
current patch release version and the link can be found here: 
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2162&quickFilter=2454&quickFilter=2160

Another good option if you're looking to engage with the ecosystem, we have the 
official Cassandra Sidecar JIRA and open issues can be found here: 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRASC%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20assignee%20DESC%2C%20priority%20DESC%2C%20updated%20DESC.
 You can expect this codebase to be considerably smaller and easier to get 
started on than Cassandra proper, so depending on your appetite and/or 
expertise this might be a good starting point as well.

The project can be cloned from the github repo here: 
https://github.com/apache/cassandra-sidecar

If you want to just peruse the backlog of open and unassigned tickets on our 
most recent releases, you can find these tickets here: 
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2160.
 49 issues unassigned in 4.0.x (bugfix or improvement only) and 313 open 
unassigned in 4.x, so there's a lot to choose from.

We hang out in #cassandra-dev on https://the-asf.slack.com and there's a 
@cassandra_mentors alias you can use to reach a bunch of us that have 
volunteered to help newcomers get situated. If you need an invite to the slack 
channel feel free to reply to just me on this email and I'll get you set up.

Here's reference explaining the various types of contribution: 
https://cassandra.apache.org/_/community.html#how-to-contribute
An overview of the C* architecture: 
https://cassandra.apache.org/doc/latest/cassandra/architecture/overview.html
The getting started contributing guide: 
https://cassandra.apache.org/_/development/index.html


[Dev list Digest]
https://lists.apache.org/list?dev@cassandra.apache.org:lte=23d:
23 days instead of the previous 26; the Thanksgiving US holiday week kind of 
set things off by a week for me. :)

Maxim Muzafarov reached out about a fairly broad collection of hygiene, 
linting, and build-related topics here: 
https://lists.apache.org/thread/11j0hrv2bkx60xk7zvlgqgjwo982qv6h. There's been 
a lot of good discussion on this thread - check it out!

Benjamin Lerer proposed the addition of the Big-Math library to the project 
here: https://lists.apache.org/thread/k3q4f2fdmr5j4vjx1drqct4075sv38xt. 
Small/early consensus appears to be acceptance w/acknowledgement that we may 
have to take on maintenance of it down the road someday if it gets abandoned, 
but the license, quality, and current state of the library looks solid.

Branimir opened up CEP-25, Big Trie-indexed SSTable format, for discussion: 
https://lists.apache.org/thread/3dpdg6dgm3rqxj96cyhn58b50g415dyh.

We had some interesting back and forth about default GC, how we validate them, 
and when during our release cycle we validate them. While G1 didn't make the 
cut for 4.1 due to timing, it looks like a topic we're going to revisit for our 
next feature release: 
https://lists.apache.org/thread/j3gwc09ffxg2tyylgs2fr