ascheman commented on issue #1430: URL: https://github.com/apache/tooling-trusted-releases/issues/1430#issuecomment-5037453129
@sbp First, to place my perspective: I'm not (yet) a release manager — I'm a committer who joined the ATR alpha out of interest and hit this while verifying an RC, so take my "requirements" as an interested bystander's, not a PMC's release workflow. Thanks for the context (I hadn't seen #199 / the existing Compose-tab "RAT source excludes" field). For the immediate false positive that field already solves it, so no objection to closing this in favour of the existing mechanism if you prefer. On what I'd actually prefer, now that I've thought about it: the thing I'd most want to avoid is maintaining the same exclude list twice — and especially maintaining it through a UI rather than something derivable. A project already declares its RAT excludes once (pom apache-rat-plugin config, over the maven-parent defaults); they're reviewed, versioned in git, and travel with the source. Re-typing them in the ATR web UI per project is duplication that can drift from what the project's own `apache-rat:check` uses. So if the excludes can be *derived from the project*, I'd prefer that over any hand-maintained path — which again points at the atr-maven-plugin side (#78) doing the deriving. The one reason I can see *against* deriving-from-project is trust: excludes that come from (or ship inside) the release are controlled by the release itself, and a verification tool arguably shouldn't fully trust the artifact it's checking to tell it what to skip. If that's your concern, it's a fair one — and maybe the sweet spot is: the plugin emits the derived excludes as a *proposal*, and a committer still confirms/edits them in ATR (pre-filling your existing ignores instead of blank-slate typing). That kills the double-*authoring* without ATR blindly trusting the archive. To target #78 correctly, two questions: 1. Which consumption path should the plugin feed — an in-archive file (exact path/name: `.rat-excludes` at root? `.atr/...`?), or your API/DB ignores (as a pre-fill)? 2. Per-file globs enough, or do you also want a reason/scope per entry? I've no strong opinion on your internal storage (DB vs archive vs compose dir) — you know the cache-key/sync and trust implications far better. Happy to run a quick sweep across apache/maven-* to quantify how much projects rely on project-specific RAT excludes beyond your standard sets, if that helps judge whether the auto-emit is worth it. -- 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]
