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 > <mailto: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 >> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>>>> <mailto: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: >>>>>> 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) >>>>>> 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. >>>>>> 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. >>>>>> 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. >>>>>> >>>
