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, followups (forward port) get updated, 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 (fails matching merge base 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... (but in that case we probably want to not do the update and warn the user)

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?

4. (xdo) skipmerge on a merged PR could be useful because it forces over conflicts, which skipci doesn't do, so if you realise after the fact that you have conflicts you may want to "post-generate" every forward port in order to look at the entire thing (in which case it would probably need to work from the last PR in the chain, which it currently likely doesn't do because in normal situations we don't want to port conflicts)