CI system maintainability

[Johannes Zarl-Zierl]

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...

  Johannes

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