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
signature.asc
Description: This is a digitally signed message part.
