CI system maintainability

Tomaz Canabrava tcanabrava at
Thu Mar 28 09:17:18 GMT 2019

On Thu, Mar 28, 2019 at 10:09 AM Luca Beltrame <lbeltrame at> wrote:
> In data giovedì 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scritto:
> > I'd argue we're loosing more with the current state of PIM than we'd loose
> > with mandatory reviews.
> Perhaps, instead of an all-or-nothing approach, why not a minimal set of
> "requirements" that would require a review? Yes, it requires more discipline
> from those involved, but at least it will help people getting "ingrained" with
> the concept without being a wall.
> Examples:
> - No review: typo fixes, compile errors, version bumps (internal)
> - Review: build system adjustments (perhaps CC some people knowledgeable in
> this case), non-trivial changes like patches
> - "Deprecation" removals (as in the casus belli here) - review if touching
> more than a handful of files / multiple repos
> (list made by someone who has a passing knowledge of C++, so feel free to rip
> me to shreds)
> Pre-commit CI (i.e. once the switch to GitLab occurs) and perhaps direct
> mailing to the user (as I suggested earlier) in case of continuous failures
> will also help.
> If this thing works, one can gradually ramp up the requirements of things that
> go through review when the "muscle memory" is formed.

The problem is that a git comit is a git commit, there's no way that a
typo will be treated differently then another commit.
I strongly advocate for "reviews always", but since I was outvoted a
few times on this I would at least say "can we at least have reviews
for non project members" ?

> --
> Luca Beltrame
> GPG key ID: A29D259B

More information about the kde-core-devel mailing list