That is how I see it and how I personally understood you, Blake! Thanks! Also, Jon, appreciate your point of view too. I would support it for a new project though, Cassandra codebase is too big, too old, and too active IMHO for such a lift. Also, from my experience being around for about 5 years already - easy wide-spread changes normally bring the most friction. I burnt myself with that in the past. Thus my position, being extra cautious.
Though if the majority of the people see it in a different way - I am open to change position following the right arguments and I am not going to stay on the way. Thank you all. Curious to hear more points of view. On Sat, 18 Jan 2025 at 15:56, Blake Eggleston <beggles...@apple.com> wrote: > Just to be clear, I do think it would be good for the project to conform > to a more standard java style. I just think that the contributor friction > from this issue is pretty small, and the impact to work in progress would > be pretty severe. If the goal is to reduce contributor friction, there's > probably lower hanging fruit that's less disruptive. > > > On Jan 18, 2025, at 12:43 PM, Jon Haddad <j...@rustyrazorblade.com> wrote: > > + .9 for me. > > I think it would be a good thing for the project in the long run to > conform to a more standard Java style, but I'm unable to provide any time > to make it happen. I don't think it's reasonable to impose this burden on > anyone if I'm not willing to take it on myself, so this is why I'm not a +1. > > > https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions > > > > > On Sat, Jan 18, 2025 at 12:32 PM Ekaterina Dimitrova < > e.dimitr...@gmail.com> wrote: > >> I also do not see huge benefit in switching the style, honestly. And I >> see risks more than benefits. >> >> I also share Blake’s opinion that this would be more suitable for a new >> project. >> >> On Sat, 18 Jan 2025 at 15:27, Blake Eggleston <beggles...@apple.com> >> wrote: >> >>> I lean pretty strongly towards -1 on this. If we were starting a new >>> project, then yeah it would make sense. As an older project though, I don’t >>> see any clear benefits for switching the style at this point, and can >>> foresee it causing a lot of pain. Even if we were to wait for accord before >>> going forward, and address any issues with git blame, there are a lot of >>> other in-flight projects that would have to deal with this, there are a lot >>> of tickets waiting for review that would be affected. >>> >>> >>> On Jan 18, 2025, at 9:40 AM, Štefan Miklošovič <smikloso...@apache.org> >>> wrote: >>> >>> I agree with Benedict wholeheartedly. >>> >>> Yes, I am happy where the braces currently are and I don't understand >>> that placing braces and the whole "problematic" is such a big topic for >>> other people. >>> >>> 99% of problems with braces are caused by people not having their >>> formatter in IDEA (or any IDE of their choosing) set up correctly. Setting >>> up a formatter in your IDE is a perfectly normal thing to do. >>> >>> I am trying to figure out how to set this up automatically so when >>> people hit formatting shortcuts, the braces would be put where they should >>> be. >>> >>> I do not think that "well but I need to think about formatting and >>> hitting that shortcut!" is a valid point. Come on folks ... one shortcut >>> away and your code is formatted as it should be. >>> >>> If somebody has very special requirements for placing braces for very >>> specific scenarios for better readability (one-liners, lambdas ...) we >>> should enable them to do so. >>> >>> On Sat, Jan 18, 2025 at 4:25 PM Benedict <bened...@apache.org> wrote: >>> >>>> This is a mad idea that I can’t believe anyone is seriously >>>> entertaining. -1. >>>> >>>> On 18 Jan 2025, at 13:17, Josh McKenzie <jmcken...@apache.org> wrote: >>>> >>>> >>>> Trying to break out discussions here to keep things moving - see thread >>>> "Checkstyle as style contract for Cassandra >>>> <https://lists.apache.org/thread/8lzlc4x6g6yx766w738grxdcmqgwds7l>" >>>> >>>> One topic that came up on the thread was whether we were collectively >>>> happy with our current newline bracing style and, if not, what we might do >>>> about it. The following points came up: >>>> >>>> 1. We would do this post-accord merging so as not to cause >>>> significant rebase pains for the branch (unless active accord devs >>>> advocate >>>> for otherwise) >>>> 2. re: git history pollution, Abe pointed out that we can use a >>>> --ignore-revs-file option in git to switch bracing style in one go and >>>> keep >>>> our history. >>>> 3. Caleb advocated for limiting ourselves to trunk only. Given only >>>> bugfixes go to older branches this would limit our surface area of >>>> change >>>> quite a bit. >>>> 4. Mick seconded raised concerns about forks absorbing pain. We >>>> have multiple fork owners on the thread in favor of making the change, >>>> but >>>> it's worth keeping in mind. >>>> >>>> In general, sentiment was clearly skewed towards changing our bracing >>>> style on trunk to have braces on the same line as preceding control flow >>>> statement, closing braces on newline. >>>> >>>> >>> >
