sigee commented on issue #8585: URL: https://github.com/apache/storm/issues/8585#issuecomment-4472473373
Hi @GGraziadei, @rzo1, I'd like to suggest a phased migration strategy that addresses the reviewability concern while still making progress: **Phase 1: Bump the Checkstyle plugin version only** Upgrade the plugin to the target version (e.g., 12.3.1) while keeping `storm_checkstyle.xml` completely unchanged. This isolates any hard breakage — rules that have been renamed or removed in Checkstyle 10+ — into a single, small PR. No code files are touched, so it's easy to review. **Phase 2: Modernize `storm_checkstyle.xml` with `severity="warning"`** Introduce new and updated rules into the config, but set them to `severity="warning"` rather than `"error"`. The build stays green, nothing regresses, and reviewers only see config changes — not a flood of code fixes mixed in. **Phase 3: Fix warnings incrementally** Address the warnings module by module (or I would say rule by rule), exactly as suggested above. Each PR remains small and reviewable. The core idea is to decouple the *tooling upgrade*, the *rule configuration*, and the *code fixes* into three clearly separated concerns. This keeps every step reviewable and avoids the "touches almost every file" problem that makes both Strategy 1 and Strategy 2 hard to justify as a single effort. One caveat for Phase 1: a small number of config fixups may still be needed if any currently-used rules have been removed or renamed in the new version, but that should be minimal and scoped entirely to `storm_checkstyle.xml`. What do you think? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
