Forward-port without even merging

[xmo-odoo]

That's a pretty serious workflow / modelling change but...

Currently the initial PR needs to be merged before forwardbot starts operating. Once that's the case, the fwbot can ignore CI and update PRs (e.g. given PR A merged. A1, A2 and A3 are forward ports, if A1 gets updated then that update will be applied to A2 and A3 automatically).

A proposal is that the forwardbot wouldn't need or assume that the source PR has been merged, it could be told to immediately create the forward-ports (possibly requiring passing statuses unless skipci is set?), and would automatically replicates updates onto the FP PRs.

NOTES:

• the reminder for outstanding PRs currently pretty much assumes the source has been merged, this likely would need fixing (e.g. by grouping by p.source_id or p, which would group a source with its descendants)

/cc @nim-odoo your team seems like the most likely to have any interest in this feature as you're the most commonly in need of forward-porting across many branches. Feedback? Thoughts?

[nim-odoo]

I think the only use case where that could be useful is when a tests fails in a version n+1, implying that the original commit is not correct. But in practice, that's a very uncommon situation.

What is way more common is a failed cherry pick. In this case, I think creating the PR in advance is likely to bring more confusing than anything else, e.g.:

1. Create a PR in version N
2. Trigger the forward-port
3. The cherry-pick fails in version N+1
4. Modify the PR in version N so that the cherry-pick doesn't fail anymore, it goes up to N+3
5. Modify the PR in version N so that the cherry-pick fails in version N+2

So not sure of the added value, except for use case such as forward-ports between 14.0 and master (shortly after the release, when there is no conflict at cherry pick)

[xmo-odoo]

So not sure of the added value

Well I guess there's the value that you could craft the initial such that all forward ports succeed rather than discover the issue later on?

[nim-odoo]

As usual, it depends on how people use it. At the moment very few people use skipci (maybe they don't know about it), so I'm not sure it would be used a lot.

Btw, if you go for it, I think you must make sure the original PR is merged before any of the forward-port is merged, otherwise it can become a mess.

[xmo-odoo]

There's a new request for this from the runbot team, in order to better handle exceptions and batched exceptions: currently it's difficult to know whether a non-trivial commit to stable (non-trivial as in modifying the models schema, which ends up being less of a bugfix thing, and more of an accounting / l10n thing) needs an upgrade script.

The ability to immediately create the entire sequence of pull requests would allow overviewing the entire process, looking at conflicts, upgrade requirements, etc... and on the runbot side it would allow for creating cross-version validation (meta-bundles across the forward ports).