+1 for the concept as a whole. I am certain I could find nits to pick if I looked deeply.
@mck -- I did have a problem with Cassandra + Eclipse + Java11 (Classpath). I gave up and am spending time trying to learn IntelliJ. I also mentioned it in one of the discussion areas. Claude On Thu, Nov 24, 2022 at 8:55 PM Mick Semb Wever <m...@apache.org> wrote: > Thank you for a solid write up Maxim. And welcome to Cassandra, it's > very positive to see you here. > > I whole-heartedly agree with nearly everything you write. Some input > and questions inline. > > > > > > As you may know, the infrastructure team has disabled public sign-up > > to ASF JIRA (the GitHub issues are recommended instead). > > > > > I suspect (based on chatter in general, but not on dev@ AFAIK) is to > avoid GH issues and stick with jira. The sign-up hurdle we will > document on the website: CASSANDRA-18064 > > > > > == 1. Make the checkstyle config a single point of truth for the > > source code style. == > > > > The checkstyle is already used and included in the Cassandra project > > build lifecycle (ant command line, Jenkins, CircleCI). There is no > > need to maintain code style configurations for different types of IDEs > > (e.g. IntelliJ inspections configuration) since the checkstyle.xml > > file can be directly imported to IDE used by a developer. This is fair > > for Intellij Idea, NetBeans, and Eclipse. > > > Big +1 > > > > So, I propose to focus on the checks themselves and checking pull > > requests with automation scripts, rather than maintaining these > > integrations. The benefits here are avoiding all issues with > > maintaining configurations for different IDEs. Another good advantage > > of this approach would be the ability to add new checkstyle rules > > without touching IDE configuration - and such tickets will be LFH and > > easy to commit. > > > > The actions points here are: > > > > - create an umbrella JIRA ticket for all checkstyle issues e.g. [8] > > (or label checkstyle); > > - add checkstyle to GitHub pull requests using GitHub actions (execute > > ant command); > > > Instead of custom GHA scripting, please use our existing > cassandra-artifact.sh (which should already include all such checks). > > Something like > https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:cassandra:mck/github-actions/3.11 > > > > > == 3. Enable pushing backwards build results for both Jenkins and > > CircleCI to GitHub pull requests. == > > > > The goal here is to have a "green checkbox" for those GitHub pull > > requests that have corresponding Jenkins/CircleCI runs. According to > > the following links, it is completely possible to have those. > > > > https://github.com/jenkinsci/github-branch-source-plugin > > https://circleci.com/docs/enable-checks/ > > > > Moreover, the GitHub Branch Source Plugin is already enabled for the > > Cassandra project [16]. The same seems should work the same way for > > CirleCI, but I have faced the infrastructure team comment [17] that > > describes admin permissions are required for that, so the question is > > still open here. I could dig a bit more once we've agreed on it. > > > > The actions points here are: > > - enable Jenkins integration for GitHub pull requests; > > - enable CircleCI integration for GitHub pull requests; > > > Some folk use CircleCI, some use ci-cassandra. The green checkbox idea > is great, so long as it's optional. We don't want PRs triggering the > runs either (there are other mechanisms for triggering for now). > > > > The actions points here are: > > > > - initiate a wide survey for user and dev lists, to get to know about > > the usages; > > - remove those configurations that are not used anymore; > > - force migration from Ant to Gradle/Maven; > > > Let's leave this out for now. There's too many unknowns here. If > there's an IDE configuration that's broken, no one has reported it for > ages, and no one is around to fix it, then I say we should raise the > discussion to remove it. > > The Gradle/Maven migration is a hot one, contribute to that discussion > but let's not tangle this work up with it, IMHO. > > Totally agree that IDE project files should be as light weight as possible. > > > > Summarizing everything proposed above I think it is possible to > > simplify adding small contributions easier to the codebase as well as > > save a bunch of committer's time. > > > > So, > > WDYT about the things described above? > > Should I create a CEP for this? > > > I see no need for a CEP here. An epic and tickets will work. > Again, thanks for the input Maxim! >
