Re: [DISCUSS] Bracing style on trunk

2025-01-20 Thread Caleb Rackliffe
I never should have mentioned this in the other thread in the first place. Just old/deep annoyance verbalized in an ultimately unhelpful way. It’s 15 years too late.On Jan 20, 2025, at 11:16 AM, Benedict wrote:These proposed refinements simply relax the wording of the style guide. That is, all cu

Re: [DISCUSS] Snapshots outside of Cassandra data directory

2025-01-20 Thread Francisco Guerrero
I think we should evaluate the benefits of the feature you are proposing independently on how it might be used by Sidecar or other tools. As it is, it already sounds like a useful functionality to have in the core of the Cassandra process. Tooling around Cassandra, including Sidecar, can then leve

stalled PR #3585 (CASSANDRA-14098: integer overflow fix)

2025-01-20 Thread Danny Faught
Hi! New contributor to the project here. I opened PR 3585 (CASSANDRA-14098: integer overflow fix) last September to address a Jira ticket that has been open for quite some time ( https://issues.apache.org/jira/browse/CASSANDRA-14098). I can imagine i

Re: [DISCUSS] Bracing style on trunk

2025-01-20 Thread Benedict
These proposed refinements simply relax the wording of the style guide. That is, all current automated formatting would remain consistent with the style guide - though I would support also updating these, and wouldn’t mind helping to produce an update to our IntelliJ templateOn 20 Jan 2025, at 17:0

Re: [DISCUSS] Bracing style on trunk

2025-01-20 Thread Jordan West
While on the surface I would like to change the rules going forward, the special or hybrid rules sound like a nightmare for lingers. I’m -1 unless the change comes with functional changes to e.g. the idea files etc. if someone wants to take that on I’m all for modernizing the style guide. Jordan

Re: [DISCUSS] Bracing style on trunk

2025-01-20 Thread Benedict
I think if we want to we can refine the rules a little while we’re all here discussing it anyway.We could for instance just stipulate the specific scenarios where it must happen, ie: multi-line if or loop blocks, and class or method declarations. This is the main actual historical style requirement

Re: [DISCUSS] Bracing style on trunk

2025-01-20 Thread Brandon Williams
On Mon, Jan 20, 2025 at 8:30 AM Josh McKenzie wrote: > So at least from my perspective w/the information I have, my opinion is we're > kind of stuck with what we have. I agree, -1 on changing this.. Kind Regards, Brandon

Re: [DISCUSS] Bracing style on trunk

2025-01-20 Thread Josh McKenzie
There was 2 things from the initial thread that I conflated upon review. 1: Are we happy with our current bracing style formatting (general sentiment summates to "no"), and 2: were we to effect change, would doing it en masse be the way or gradually over time (far less sentiment expressed on thi

Re: [DISCUSS] Bracing style on trunk

2025-01-20 Thread Marcus Eriksson
Same, -1 On Mon, Jan 20, 2025 at 01:48:37PM GMT, Alex Petrov wrote: > I agree that switching bracing style is not something worth entertaining. -1 > from me, too. > > On Sun, Jan 19, 2025, at 1:34 AM, Maxim Muzafarov wrote: > > I'm leaning toward not changing the bracing style we already have >

Re: [DISCUSS] Bracing style on trunk

2025-01-20 Thread Alex Petrov
I agree that switching bracing style is not something worth entertaining. -1 from me, too. On Sun, Jan 19, 2025, at 1:34 AM, Maxim Muzafarov wrote: > I'm leaning toward not changing the bracing style we already have > unless there's a powerful reason (hard to imagine what it could be). > So curre