Gentoo Archives: gentoo-dev

From: Alexis Ballier <aballier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
Date: Fri, 06 Dec 2019 10:50:54
Message-Id: 20191206115042.11621fd0@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template by Tim Harder
1 On Fri, 6 Dec 2019 04:33:36 -0500
2 Tim Harder <radhermit@g.o> wrote:
3
4 > On 2019-12-06 Fri 04:03, Alexis Ballier wrote:
5 > > it's not just like repoman and cvs since repoman commit did push ;)
6 > > it will never be perfect but i really like repoman commit to refuse
7 > > to even commit if there's something obviously wrong
8 >
9 > I'm more of the opinion (and am working towards that practicality in
10 > terms of runtime speed) that a subset of QA checks should be run as a
11 > git hook which would cause push failures on certain classes of bad
12 > commits.
13
14
15 There should be both. Amending the 23rd commit message because one
16 mistyped a semicolon is kind of a PITA.
17
18 > > as you write below, it's just a matter of checking exit status and
19 > > using git, which can be done by scripting, but the script is
20 > > standard (*) and mandated to be part of the workflow
21 >
22 > > it also allows to check or templatize commit messages to follow
23 > > policy
24 >
25 > Technically pkgcheck supports more git-related checks than repoman
26 > last I checked, i.e. result keywords including BadCommitSummary,
27 > DirectStableKeywords, DroppedUnstableKeywords, DroppedStableKeywords,
28 > DirectNoMaintainer, and MissingSignOff; with possible future additions
29 > such as warning when modifying deps in an ebuild without revbumping.
30 >
31 > Futhermore, one can scan against all commits in parallel via `pkgcheck
32 > scan --commits` which will enable potential commit results that are
33 > otherwise skipped.
34
35 All this seems post-commit, not pre-commit.
36
37 > Anyway, my main point is that if someone really wants commit
38 > functionality it's semi-trivial to script something similar to what
39 > repoman does (assuming exit status/api support exists) and if it's
40 > decent enough quality (including tests) I'd probably consider adding
41 > it to the pkgcheck repo.
42
43 It doesn't necessarily have to live in the pkgcheck repo, but it should
44 definitely not be "meh, script it yourself, it's trivial" since that
45 will probably lead to several scripts with varying degrees of quality
46 and brokeness.

Replies