maintenance burden

[Pankraz76]

This isn’t about blame — it’s about survival.

Good habits have a price. Bad habits have a cost. Either way, you pay.

We need to start this discussion, as the development team may not be aware that in some rare cases the majority of Quarkus code appears obsolete, as evidenced by:

issue:

• Fix divider in rotated access log for DefaultAccessLogReceiver #48398
• Fix divider in rotated access log for DefaultAccessLogReceiver #48398 (comment)
  • Drop unused members of VertxHttpProcessor #48473
  • Drop unused members of DefaultAccessLogReceiver #48449

legacy (cost of carry):

• Apply Spotless changes to the whole codebase #48092
• Bump spotless-maven-plugin to 2.44.4 #48063
• Avoid wildcard * import #46124
• [S1161] Add missing @Override to overriding and implementing methods #48345
• consolidate root config for formatter-maven-plugin and impsort-maven-plugin #48372
  • integrate Eclipse Formatter Profile into Maven Spotless Plugin #48047
    • (re)activate maven.compiler.release thus consolidate spotless-maven-plugin, impsort-maven-plugin, and PMD to fix UnnecessaryImport #48414
    • consolidate spotless-maven-plugin, formatter-maven-plugin, and impsort-maven-plugin #48394
  • use PMD to prevent EmptyControlStatement #48407
  • PoC: Remove unused imports #48050

Good catch

• Avoid wildcard * import #45599
• Avoid wildcard * import #45599 (review)

This is the direct result of a lack of discipline, which is actively degrading quality.

Core Problems:

1. Code Obsolescence:

   • No effective audit or removal of dead code (e.g., DefaultAccessLogReceiver)
   • Tools like Spotless (with removeUnusedImports) exist but aren’t fully enforced
   • Yet tools with only ~300 stars are used, while Spotless—despite having 5k+ stars—is ignored. This seems questionable, especially given that the problems Spotless solves are already confirmed in this context.

2. Scale Magnifies Failures:

   • 1000+ submodules make manual consistency impossible
   • Small issues (like unused imports) left unfixed signal larger systemic problems
   • Endless PR debates over trivial flaws waste valuable energy

3. Execution Gap:

   • "Stop starting, start finishing" — half-done solutions create chaos
   • Proper tooling exists but remains unimplemented or incomplete

Solutions:

1. Strict Enforcement:

   • Zero tolerance for basic violations (like unused imports)
   • Enforce automated code health metrics in CI

2. Structural Changes:

   • Dead code audit: delete first, ask questions later
   • Maintainer-approved roadmap to fully complete essential tooling

3. Culture Shift:

   • No more exceptions — discipline in small things prevents major failures
   • Community and maintainers must align around non-negotiable quality standards

This isn’t about blame — it’s about quarkus.

cost of carry > price of fix(refactor)ing.

n1 > 1.

[maxandersen]

Hi @Pankraz76

Thank you for the time and energy you've invested in reviewing and contributing to Quarkus. I can see you're passionate about code quality and consistency, and that’s appreciated in principle.

That said, we want to clarify how we prioritize contributions in the Quarkus project.

We operate at a scale and maturity level where small cosmetic or low-impact cleanups (such as removing unused fields or adjusting formatting) often introduce more overhead than benefit:

• Every PR, no matter how small, requires time for review, CI runs, and possible backport evaluations.
• Superficial changes can increase the risk of conflicts and slow down work on features and bugfixes that materially benefit users.
• We're cautious about enforcing blanket rules, especially when the tools or rules in question have trade-offs or may not align with our existing setup and practices.

Additionally, long issues or discussions made up mostly of links, headers, and slogans — without concrete, actionable proposals or context — are difficult to engage with. It takes significant time and effort to extract meaning or relevance from such posts, which reduces the likelihood of productive discussion or response. Please keep future discussions concise and focused, ideally tied to specific, high-impact improvements.

We ask that future contributions focus on:

• Actual bugs or misbehavior that affect users.
• Performance or memory improvements that are measurable.
• Refactorings that unblock features or solve real complexity, ideally linked to issues or discussion with maintainers.

We're currently not prioritizing mass cleanup, Spotless integration, or aggressive dead-code removal unless it's directly tied to a larger issue or refactor.

Your current strategy of opening lots of issues touching alot of code and to be honest looks ai generated is very noisy and every time reduces the likelihood of the fixes to be merged. Even if they come with good intentions.

For now, we kindly ask you to pause PRs aimed at minor stylistic cleanups or low-impact refactors. If you’d like to propose structural or tooling changes, we’re happy to discuss them — ideally after consensus with core maintainers is reached in an issue or discussion thread first.

Thanks for understanding.

[Pankraz76]

numbers

numbers dont lie. prefer zero over hero, is kind of sad. Resulting in CUSTOMER FACING BUGS, you talk about again and again.

Spring bounces me off for the very same reasons but they have at least a minimum baseline in quality assuring tools, meaning static code analysis, resulting in even proprietary impl. in checkstyle https://github.com/spring-io/spring-javaformat.

[Pankraz76]

Resulting in CUSTOMER FACING BUGS.

[maxandersen]

you mean having to delete 50% in order to fix 1 LOC. ?

No idea what you refer to. Deleting code to fix a bug seems fine to me.

yes, we agree on quantity being prior, assuming quality does not matter all all. Arguing about tests bring obsolete or trivial.

Again, I do not understand what you are referring to.

The only thing obsolete, seems the business logic implemented impossible to ever work as expected.

Please be specific - otherwise its a waste of both our time.

[maxandersen]

Spring bounces me off for the very same reasons

Please take a moment to reflect on that sentence. If Spring, OpenRewrite, Maven, and Quarkus all reject a large number of your PRs — maybe it’s time to consider whether there’s a pattern. These are independent projects with different goals and processes, yet you're encountering similar feedback across all of them.

but they have at least a minimum baseline in quality assuring tools, meaning static code analysis, resulting in even proprietary impl. in checkstyle https://github.com/spring-io/spring-javaformat.

That’s great, and yes — we’re also interested in tools that improve consistency and quality. But implementation doesn’t come from overwhelming maintainers with dozens even hundreds of loosely argued PRs, scattered links, and vague accusations. It creates stress, not progress.

If your goal is to help, please understand: this high-volume, low-signal approach is having the opposite effect. Progress requires clarity, coordination, and empathy for the team maintaining the work.

[Pankraz76]

overwhelming maintainers with dozens even hundreds of loosely argued PRs, scattered links, and vague accusations. It creates stress, not progress.

agree.

We on the same page, only me being short in communicating well.

Im sure we can overcome this, as you guys very smart in general.

whether

this is not a question anymore but a fact. May i dont like this but as im the fact man need to accept this as well and adapt.

Its the missing guidance and moderation leading to such frequent changes. Ive done and learned a lot when refactoring and improving the project.

I admit im wrong how im doing it, making the what im doing obsolete as well.

Lets focus in the baseline and increment there.

[Pankraz76]

no test = no security.

• PanacheEntityResource not propagating javax.annotation.security #28995

[maxandersen]

please stop commenting without enough context.

[Pankraz76]

so important even make it a third time:

Resulting in CUSTOMER FACING BUGS can not fix due to techical dept. just like the clean code book tells. its so funny and sad at the same time.

[maxandersen]

You mentioned Clean Code — an interesting book with solid suggestions on how to write clearer, more maintainable code. But please remember: clean code is just one aspect of many in software development. It should guide, not become dogma.

In fact, Clean Code emphasizes more than just fixing technical debt. It stresses the importance of writing with clarity, communicating with intent, and working professionally with your team.

Blaming "customer-facing bugs" on technical debt while flooding the project with unreviewable PRs, vague discussions, or test cases that don’t meaningfully test anything runs counter to the very principles the book promotes — and ultimately does more harm than good.

If your goal is to contribute meaningfully, remember: influence comes not just from what you propose or write, but how you communicate and collaborate.

[Pankraz76]

how

yes thats obviously my big weak point, please excuse.

unreviewable PRs

its about PoC.

I deliver PR´s everybody will agree on even, quarkus like it, but then do not merge after approve. Wasting everybody´s time:

• consolidate root config for formatter-maven-plugin and impsort-maven-plugin #48372

Its like saying yes you are right, but we dont like you.

I dont care why like how?

Im a guy about facts not about feelings.

test cases

AI test find the bugs. Why care about these tests if they, looking onto the bare numbers, fullfull their exact purpose.

[Pankraz76]

Im not asking for anything new, but only to be consequent, complete the effort on unused imports.

It seems inconsequent, not be able to choose the best tool (facts by finding existing flaws) not the tool someone likes (opinion).

And not its not about imports its about being strict, thats the real deal because this is the same with tests and everything else.

Why not closing the broken window effect?

[maxandersen]

how

yes thats obviously my big weak point, please excuse.

Example on where you are making it hard to understand - you are quoting a single word and replying - i have to guess now what you actually refer to.

unreviewable PRs

its about PoC.

What is about proof of concept ? Your don't present your PRs proof of concepts or suggestions.

I deliver PR´s everybody will agree on even, quarkus like it, but then do not merge after approve. Wasting everybody´s time:

• consolidate root config for formatter-maven-plugin and impsort-maven-plugin #48372

Its like saying yes you are right, but we dont like you.

I'm not the one closing but if I should take a guess it was closed because you bombarded with comments and issues everywhere else and we just had enough trying to handle it and go for fixing real user facing issues.

I dont care why like how?

Im a guy about facts not about feelings.

You have opened dozens of issues and comments in the last week that generates way more noise than value.

That is why.

test cases

AI test find the bugs. Why care about these tests if they, looking onto the bare numbers, fullfull their exact purpose.

Again - i really have a hard time understand what you mean. IF what you mean is that reaching 100% coverage is more important than the tests actually being meaningfull to humans then we just have to agree to disagree.

Having 100% coverage for unrelevant or hard to understand is worse than having 80% coverage with meaningfull tests.

[Pankraz76]

Example on where you are making it hard to understand - you are quoting a single word and replying - i have to guess now what you actually refer to.

yes sorry even i can not tell anymore.

agree to disagree

im just overstating this, of course meaning full code is first premiss. We agree to agree on baseline, personally will always try to push beyond.

Having 100% coverage for unrelevant or hard to understand is worse than having 80% coverage with meaningfull tests.

yes, test wont change anymore, until the business does. Assumin need to change production code is more likely. So trade off between bad test with good coverage, over no tests, seems simple.

[Pankraz76]

I am stupid just as AI.

We still can tell code is wrong.

[Pankraz76]

Please see this nifty test, showing whats wrong.

I see you dont like generated code, for same reason i do. Maintenance is first premiss, despite the recent discoveries.

Assuming we underestimate the potential, as im never able to deliver such high coverage when doing it by hand. Quality then comes by refactoring which is a very normal part of the game.

Testing is the kind of work computer was made to do, speaking of brute force calculations.

In ideal: its time to debate the actual tests, only when coverage reached 100%. Everything else meaning blindspots therefore bugs. This first premiss to prevent then code quality matters. Stability and functionality comes fist, this the reason I get rejected all the time.

Test begin a second security layer for impl. Assuming the current state it SSOT, as we not on greenfeeld anymore.

When computer not able to test code is unreachable/impossible, like discovered as well.

The impl. changed the test can tell instantly.

[cwansart]

its time to debate the actual tests, only when coverage reached 100%. Everything else meaning blindspots therefore bugs.

No, that is simply wrong. Wasting time to test meaningless things is not helping, in fact, it makes things worse. There may tests that will break when structure change, even if there is nothing meaningful to test, it will take time to adjust and it will take more time to run the full CI pipeline -- even now it takes a lot of time.

You mentioned Clean Code before, please also read Unit Testing by Vladimir Khorikov, it will help you understand why 100 % coverage is not a desirable state.

[Pankraz76]

Thanks for the feedback. Checkstyle advocates for 100% test coverage—including mutation testing—and I share that belief.

Do they still have bugs? Absolutely. Everything made by humans is inherently flawed. Given that reality, static code analysis remains one of the few reliable safeguards.

At least Checkstyle avoids dead and impossible code—unlike some issues I’ve encountered in Quarkus while debugging real problems.

Of course, every approach has trade-offs, so finding the sweet spot is never easy.

[maxandersen]

I'm closing and locking this issue. It is non-productive.