CI system maintainability

[Luca Beltrame]

In data giovedì 28 marzo 2019 15:15:23 CET, Nate Graham ha scritto:

> In this case, it seems like the problem is that there are certain
> individuals or teams that are pushing risky, breaking changes without code
> review, and then ignoring failures in the CI. I think we might do well to
> try to answer the question of why that's happening before we create a new
> rule aimed at stopping it.

Well put. Review or not review, clearly something in the process has failed, 
and I suspect "friction" rather than actual bad-faith ignorance of the CI 
results. 

So, perhaps to force myself out of the bikeshedding (mea culpa) on reviews, 
I'll steal Friedrich's points from another mail and put them here 
synthetically:

- Why are the CI mails ignored / filtered? Too many, hard to parse, difficult 
to interpret?
- What can be done to have people look at them and make sure they don't 
overlook breakage?

At least for the second point, as I mentioned earlier in the thread, probably 
having the committer being mailed in case of failure (GitLab does this IIRC) 
might be better than just on the mailing list. The second approach is what we 
use in openSUSE, where I usually don't subscribe to failure notifications 
(almost 300 packages is overkill) but a bot starts pestering me with mails the 
moment build failures go unfixed (granted, the time scale is different). 

For the first, I'd like people more involved in the development to say their 
word.

-- 
Luca Beltrame
GPG key ID: A29D259B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20190328/d724258c/attachment.sig>