entropic-dev/entropic

Trying something new: "Merge queue"

chrisdickinson opened this issue · 4 comments

Hi folks! You might have seen me adding a new "merge queue" label to PRs.

This specifically changes how we land PRs. The idea is that we batch up 1-5 PRs that are ready to land in a merge queue, and the next available maintainer can apply them locally, one at a time, making sure they work (Passes tests, runs in docker-compose, & the CLI works.) If a merge queue PR fails to merge, if we can write a quick fix to get things upright again, we'll do so and commit it and move on to the next item. If we can't get it to work, we'll take the merge queue label off the PR and request changes. The goal is that we have less churn due to bugs introduced while we're adding tests.

I'm doing a test run of this to see if it helps out! If it does, we'll formalize the process in a document. Thanks for your patience, all ❤️

fetis commented

they work (Passes tests, runs in docker-compose, & the CLI works)

i see tests run automatically for every branch.
what about to automate the last two if it's not yet?

for me it looks like you make an integration branch locally and if it's green your merge it to master. what about to automate this as well? pr labeled merge queue are auto-merged in integration branch once a day, let's say.

@fetis I think we just need to create tests for the last two items. this might be a good help wanted issue

I have an issue for:

CLI tests against the registry are a bit more open ended for now

So, after a couple of rounds of this (one informally, sans labels):

  • I like that this disconnects "I intend to merge this" from "I'm merging it"
  • I like that that this makes me pull down the code & test it locally. More automation would be better, however I think automation would be a confidence booster vs. a straight-up replacement for this flow.
  • This also lets me "fix up" those PRs that are a few inches away from completion, but for which a full-back-and-forth on the tracker seems like it would be asking too much of the contributor. git commit --amend FTW.

EMOREDATANEEDED:

  • Thus far it's just been me adding the label and merging, so I'm not sure how well this extends from 1 maintainer to N.