Re: [Committer/reviewer needed] Request for Review of Cassandra PRs

I have added you as a reviewer of CASSANDRA-11303, you can do that for CASSANDRA− 20097 by yourself. guo Maxwell 于2025年1月17日周五 14:10写道： > Hi Wang, > I think Runtian should change the ti

Re: [Committer/reviewer needed] Request for Review of Cassandra PRs

Hi Wang, I think Runtian should change the ticket 's status ,submit a pr , then you can add yourself as a reviewer. Cheng Wang via dev 于2025年1月17日周五 14:05写道： > I can review the CASSANDRA-19248 first since it looks straight forward. > For CASSANDRA−11303 and CASSANDRA− >

Re: [Committer/reviewer needed] Request for Review of Cassandra PRs

I can review the CASSANDRA-19248 first since it looks straight forward. For CASSANDRA−11303 and CASSANDRA− 20097 I will try but can't promise anything yet. How to add myself as a reviewer?

Re: Checkstyle as style contract for Cassandra

If breaking blame is a concern, we can address that with the ignore-revs-file flag in git and GitHub blame viewers: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-and-understanding-files#ignore-commits-in-the-blame-viewOn Jan 16, 2025, at 18:11, Cheng Wang via dev w

Re: [Committer/reviewer needed] Request for Review of Cassandra PRs

Thanks for this message Runtian. I realized I was previously assigned as reviewer for CASSANDRA−11303 but I will not be able to review it at this time. There's also CASSANDRA-19248 that is waiting for review in case someone has cycles to review it. Reviewing community patches is a great way to l

[Committer/reviewer needed] Request for Review of Cassandra PRs

Hi all, I hope you are doing well. I would like to request your review of two pull requests I've submitted earlier: 1. *Inbound stream throttler* [CASSANDRA− 11303 ] 2. *Clear

Re: Checkstyle as style contract for Cassandra

I am personally in favor of more automatic code linting and enforcement than worrying about the code style. On Thu, Jan 16, 2025 at 1:56 PM Josh McKenzie wrote: > I merely remember Josh saying > > I say a lot of things. :D And I reserve the right to change my mind in the > face of better thought

Re: Checkstyle as style contract for Cassandra

> I merely remember Josh saying I say a lot of things. :D And I reserve the right to change my mind in the face of better thought through arguments. > It could just be done in trunk, after any huge outstanding feature branches > are merged, and eventually it would just be a memory. I'm receptiv

Re: Checkstyle as style contract for Cassandra

oh well, I was wrong, they were all big bangs: here we avoided star import everywhere and updated IDE configuration around that https://github.com/apache/cassandra/pull/2041 here we sorted imports https://github.com/apache/cassandra/pull/2108 https://lists.apache.org/thread/d3s3ghkb81f7mbb6t09

Re: Checkstyle as style contract for Cassandra

> It would definitely have its costs, but it also wouldn't be a lot of toil if timed and executed surgically. It could just be done in trunk, after any huge outstanding feature branches are merged, and eventually it would just be a memory. There are forks out there, of course, and they would be af

Re: Checkstyle as style contract for Cassandra

All seasoned contributors already "got it" and there are no issues as far as I can tell. The "wrong" braces are most often happening for one-off patches and in that situation it just does not make sense to explain that to people. In that case I sometimes fix that on commmit, yes. For multi-branch

Re: Checkstyle as style contract for Cassandra

> likely provide merge pain Is there anyone that actually does merge commits w/adjustments to code for any non-trivial patches, or does everyone else have to "-s ours" with per-branch bespoke implementations and a --amend to the merge commit the way I have to? Not to pile on project frustrations

Re: Checkstyle as style contract for Cassandra

Hi Stefan, > It is somewhere in Settings -> Editor -> Code Style -> Java -> Wrapping and Braces and there you can fiddle with it endlessly. Maybe putting that into some xml as part of generate-idea-files would do it? Ah yes, good point, that evidentally does work well. Code > Reformat File, does

Re: Checkstyle as style contract for Cassandra

Couldn't say it better. My position is that I do not mind too much where the braces are (new line or not). I do mind that it is / would be inconsistent. At this point, I think we keep putting them on new lines just because the majority of that already is and nobody wants to break the consistency.

Re: Checkstyle as style contract for Cassandra

> Isn't that what ant generate-idea-files does automatically? (that it sets code style like that) Unless i'm not doing something right (very possible), I don't think it does this automatically with generate-idea-files. I've gotten in the habit of updating my Checkstyle plugin to pull in .build/ch

Re: Checkstyle as style contract for Cassandra

I think we inherited brace-on-newline, nobody has ever liked it (stockholm syndrome aside.) As I recall we decided against changing it in the past because it would be a huge patch and likely provide merge pain for a long time, unless we do it in all the branches. Kind Regards, Brandon On Thu, Ja

Re: Checkstyle as style contract for Cassandra

I think we are in strong agreement Stefan. It’s more convenient because we took the time to make it automatic and not require human effort. Yet it’s still imperfect as Bernardo pointed out. And as Caleb pointed out, had we taken a more convenential Java project approach it would’ve been even bett

Re: Checkstyle as style contract for Cassandra

_ The burden shouldn’t be on humans to place or check that every curly brace is on its own line._ Who is actually doing this? It is one shortcut in IDEA and it all places them correctly. I don't even know what the shortcut is, I never think about that consciously anymore. Isn't that what ant gene

Re: Checkstyle as style contract for Cassandra

> “why have we chosen a style guide that is hard to implement in these tools?” This has bothered me since I first looked at this code 14 years ago. How hard would it be to just stop doing the newline braces and be like nearly every other large Java project in existence? On Thu, Jan 16, 2025 at 1:

Re: Checkstyle as style contract for Cassandra

IMO the more we can enforce the style guide programmatically the better. It was a big improvement when we got parts of it in IntelliJ. It saves time and reduces friction. The burden shouldn’t be on humans to place or check that every curly brace is on its own line. And if we say don’t check during

Re: [DISCUSS] CEP-45: Mutation Tracking

I’m not sure Josh. Jon brought up paging and the documentation around it because our docs say we provide mutation level atomicity, but we also provide drivers that page transparently. So from the user’s perspective, a single “query” breaks this guarantee unpredictably. Occasional exceptions with

Re: [DISCUSS] CEP-45: Mutation Tracking

Thanks Jake! Honestly I’m not familiar with the Aurora paper, but will check it out. The CEP doesn’t prefer to reconcile on read, but read reconciliation is a requirement so that’s outlined there. There is also a background process that continuously reconciles writes between peers and maintain

Re: [DISCUSS] CEP-45: Mutation Tracking

> The other issue is that there isn’t a time bound on the paging payload, so if > the application is taking long enough between pages that the log has been > truncated, we’d have to throw an exception. My hot-take is that this relationship between how long you're taking to page, how much data yo

Re: [DISCUSS] CEP-45: Mutation Tracking

This is very cool! I have done a POC that was similar but more akin to Aurora paper whereby the commitlog itself would repair itself from peers proactively using the seekable commitlog. Can you explain the reason you prefer to reconcile on read? Having a consistent commitlog would solve so many

Re: [DISCUSS] CEP-45: Mutation Tracking

I’ve been thinking about the paging atomicity issue. I think it could be fixed with mutation tracking and without having to support full on MVCC. When we reach a page boundary, we can send the highest mutation id we’ve seen for the partition we reached the paging boundary on. When we request ano

Re: Checkstyle as style contract for Cassandra

> Perhaps a “Review Guide” is what we need to make sure we keep review > primarily focused on the core contribution, and to help avoid folk getting > bogged down in style sniping. I recall reading through / offering this guide in the past as a starting point for an org I was managing at the time

Re: Checkstyle as style contract for Cassandra

I can imagine that it might cause some frustrating review interactions people would like to avoid, but for solving that I’d prefer we take a more social approach. Review shouldn’t spend much time on minor style points, and these should normally be framed as suggestions. Obviously newer contributors

Re: Checkstyle as style contract for Cassandra

Right now our codebase is pretty consistent, especially for not having a linter enforcing this kind of thing. Are we trying to solve for codebase consistency, education of new contributors, both? Neither? If just solving for consistency I'd argue we're good. If educating new contributors, the C