We have a lot of great merge requests in the queue. Even though it would be great to get them all in right now, I propose to take them one at the time and let the pipeline go green before merging the next so we don’t have to engage in forensics trying to figure out what caused what errors and how to fix them. If something goes wrong, I suggest using the stop-the-line principle. Basically:
No more merges or pushes to master other than trying to fix the problem.
Fantastic. Yep, if the CI is red, the first and only thing to do is to get it not red (as you say, strongly prefer rolling back the change that caused it to go red if at all possible).
I think you should prioritize Matthew’s changes over mine, given they’re fixes for potential security issues/crashes.
After that, the most useful changes to review would be:
I would like @erg@scnorth or @Ellson to review the actual code changes since I don’t feel comfortable to do that. I’ll pick some of the others while we’re waiting.
That listed policy sounds good to me. Thanks for putting it together! My merge requests are not urgent, so if there are other things to prioritize ahead of them please go ahead. I was waiting until my current requests had been dealt with before submitting more to let the maintainers somewhat rate limit my bug hacking
