Laughs in object

Interesting perspective I hadn’t considered before, thanks for sharing. Also, not sure where the Java 7 thing comes from, but I run Java 17 with gradle/kotlin non-android, works very well in IntelliJ, outside of consuming a million gigs of ram lol

I believe in GitHub branch protection rules, you can set required review by a code owner, as well as set an amount of reviews required.

You are also able to structure codeowner files and assign codeowners to certain paths within the repo that they “own”, rather than all or nothing.

You are able to set bypass rules for certain individuals, and as repo admin there is a little checkbox on PRs that will appear by default to allow you to ignore the requirements, although it is generally not recommended, but I won’t harp on the reasons others have already pointed out.

disclaimer: I mainly work on a GHES instance, which may be function slightly different than public GH

I think JetBrains has fully bought into Gradle. I think Maven support has been less and less over time, which shouldn’t be a surprise. Gradle supports native Kotlin build scripts (i.e. build.gradle.kts), as well as putting a lot of work into ensuring their tools fit well within the Gradle ecosystem (exhibit A: https://github.com/JetBrains/intellij-platform-plugin-template). I think it only natural for the creator/owner/maintainer of Kotlin to go full in on the build system that supports the language!

controversial take: who still uses maven? who would prefer xml files over build scripts? (ok… fine, big timers like RedHat definitely do, or at least, have never taken/don’t want to take the time to upgrade lol)

AutheNtication vs. AuthoriZation, I believe

I rebase my dev branches on main to get rid of garbage commit messages due to me being lazy.

Squash and merge PRs into main, no merge commits allowed.

I think there are reasonable arguments for allowing rebase and merge to main, but it often doesn’t apply for me.

Merge commits in main will break a lot of out of the box GitOps tools.

not production ready vs. production ready