sbp commented on issue #1430: URL: https://github.com/apache/tooling-trusted-releases/issues/1430#issuecomment-5038230650
@ascheman Thank you for the detailed reply! This is very helpful. > 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 So ideally we'd use the POM directly, but since that depends on Maven resolution I suppose it can't easily be moved into RAT. > 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. I think that's okay, because that's what the PMC vote is for, and ATR can never remove the need for the vote. All voters are required to check the integrity of the release, including these details specifically. Having the information in the release files is also probably more convenient for the voters than having to go into ATR and check the release policy in there. > 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) Despite what I said above, this could still be useful. Composing a release, through ATR or otherwise, is effectively an integrity problem, and we can never prove the absence of bugs or issues. We try to come as close to that as possible by having carefully defined policies, release procedures, and lots of automated tooling and manual analysis of the release artifacts. Some kind of page to show which ignores were applied and which files they were applied to, e.g. how many files matched each ignore in each archive, with links to be able to view the files, might therefore be useful. > exact path/name: `.rat-excludes` at root? For the existing mechanism of files inside the archive it has to be at the root of the source tree, inside the single top level directory, next to `LICENSE` and `NOTICE`, e.g. `apache-example-1.2.3/.rat-excludes`. I think that would be what we would consider standard at present for releases composed through ATR, but we can always change it if there is compelling reason to do so. > 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. That would be fantastic data if it's not too much trouble. -- 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]
