skipmerge experience report

[xmo-odoo]

Since I used skipmerge for odoo/odoo#198500 and odoo/odoo#198537 (because I had the opportunity) I got to experience some of their issues.

1. Spams the fuck out of you because of the resyncs, but there's not much to be done about it because gh just sucks: any time a PR gets updated, never followup (forward port) then gets updated in turn, which triggers a notification because Github is fucking stupid.

   There's not much that can be done, aside from suppressing the initial (@) notification even in case of conflict such that you're not a follower of all the PRs immediately?

2. If the batches have multiple PRs, and one of the PRs has to be updated, the updates / followups are created from their respective bases at the time of the update. This means *every single batch following the update is now desynchronised on the runbot (mege base matched check), and you have to go update the sibling branch in order to resync things.

   I guess we should fix this by creating followup updates across the entire batch, not just the PR that got manually updated. This increases traffic, but doesn't increase work for the runbot, and keeps our ports in sync. Except for those which have already been detached and don't auto-update anymore anyway...

3. If there are conflicts or followup updates to perform (e.g. removing some method call, there are so many calls in branch A, and there are 5 additional calls in branch B, but 3 removed in C, etc...) the forward ports are detached, which per the current law of forward port approval requires repeating on every detachment.

   Options:

   • Accept that as the cost of doing business.

   • Special case skipmerge sources such that approval goes through the entire thing even if some PRs are detached.

   • Don't detach skipmerge forward ports on explicit updates.

     This is alluring in the sense that it avoids special casing commands handling (which is already complicated), however it means if you go backwards in updating PRs the earlier update will now overwrite the later ones, which may be undesirable.

     Then again I don't understand why you'd want to fix things up backwards.

   OTOH if (2) is fixed it should reduce this issue significantly, as there won't be "parasite" PR detachment after every manual updates?