Merge strategy going forward

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:

  1. No more merges or pushes to master other than trying to fix the problem.
  2. If you can’t fix the problem rather quick:
    1. Back out the changes
    2. Get a green build/test
    3. Allow merge/push again

What do you think?

1 Like

@mark, @smattr: See ^^

Now the pipeline is green again. Thank a bunch @mark.

Do you have any particular merge request that you think should prioritize before the others?

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:

The rest are pretty small-change cleanups, which might be an easy review.

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 :wink: