CI system maintainability

[Ben Cooksley]

On Fri, Mar 29, 2019 at 6:45 AM Johannes Zarl-Zierl
<johannes at zarl-zierl.at> wrote:
>
> Hi,

Hi,

>
> (Sorry for top-posting)
>
> I fear that a mandatory reviews would add too juch strain on smaller teams. If there's just one person with an intimate knowledge of the code-base, plus two co-developers, then who should do the reviews?
>
> How about a distinction based on importance of a project instead? I.e. mandatory reviews for frameworks and any app that wants to be included in KDE apps releases. Non-mandatory reviews can then also come with a "price" to pay: if CI errors are not dealt with in a timely manner, you should be free to disable the CI for administrative reasons...

While this does seem like a nice solution, unfortunately for many
repositories it isn't a case of disabling CI coverage for it, but also
CI coverage for everything that depends on it. In the case of
KContacts, this would also impact on parts of Extragear and Calligra
(who depending on their exact requirements would either lose a
dependency being available, or lose all of their CI coverage).

This is why i've not pursued this as an option in the past, because
it's not fair on other projects that don't have anything to do with
another project aside from being a user of it's interfaces to lose
their coverage, simply because the project they depend on is broken.

>
>   Johannes

Cheers,
Ben

>
> Am 28. März 2019 10:17:18 MEZ schrieb Tomaz Canabrava <tcanabrava at kde.org>:
> >On Thu, Mar 28, 2019 at 10:09 AM Luca Beltrame <lbeltrame at kde.org>
> >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