[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: CI system maintainability
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2019-03-29 19:54:54
Message-ID: CA+XidOH6tqBRrxvwvUOKCxT=6SmyGJGAFDxa9DjGTkK++m9o4A () mail ! gmail ! com
[Download RAW message or body]

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

Hi,

>
> (Sorry for top-posting)
>
> I fear that a mandatory reviews would add too juch strain on smaller team=
s. 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. ma=
ndatory 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=C3=A4rz 2019 10:17:18 MEZ schrieb Tomaz Canabrava <tcanabrava@kd=
e.org>:
> >On Thu, Mar 28, 2019 at 10:09 AM Luca Beltrame <lbeltrame@kde.org>
> >wrote:
> >>
> >> In data gioved=C3=AC 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scrit=
to:
> >> > 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
[prev in list] [next in list] [prev in thread] [next in thread]