On Fri, 6 Dec 2019 04:33:36 -0500 Tim Harder <radher...@gentoo.org> wrote:
> On 2019-12-06 Fri 04:03, Alexis Ballier wrote: > > it's not just like repoman and cvs since repoman commit did push ;) > > it will never be perfect but i really like repoman commit to refuse > > to even commit if there's something obviously wrong > > I'm more of the opinion (and am working towards that practicality in > terms of runtime speed) that a subset of QA checks should be run as a > git hook which would cause push failures on certain classes of bad > commits. There should be both. Amending the 23rd commit message because one mistyped a semicolon is kind of a PITA. > > as you write below, it's just a matter of checking exit status and > > using git, which can be done by scripting, but the script is > > standard (*) and mandated to be part of the workflow > > > it also allows to check or templatize commit messages to follow > > policy > > Technically pkgcheck supports more git-related checks than repoman > last I checked, i.e. result keywords including BadCommitSummary, > DirectStableKeywords, DroppedUnstableKeywords, DroppedStableKeywords, > DirectNoMaintainer, and MissingSignOff; with possible future additions > such as warning when modifying deps in an ebuild without revbumping. > > Futhermore, one can scan against all commits in parallel via `pkgcheck > scan --commits` which will enable potential commit results that are > otherwise skipped. All this seems post-commit, not pre-commit. > Anyway, my main point is that if someone really wants commit > functionality it's semi-trivial to script something similar to what > repoman does (assuming exit status/api support exists) and if it's > decent enough quality (including tests) I'd probably consider adding > it to the pkgcheck repo. It doesn't necessarily have to live in the pkgcheck repo, but it should definitely not be "meh, script it yourself, it's trivial" since that will probably lead to several scripts with varying degrees of quality and brokeness.
