Comment 1 for bug 1929999

This is a bit of a tricky situation I think. Let me elaborate.

We allow new upstream releases for certain projects because of a certain trust shift - for upstream projects that have a sufficient quality assurance story and clear bugfix policy, we allow updating the whole version instead of requiring testing of every single change separately. Basically this is this section of the policy, even though it's a bit vague:
https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases

In this case, when the upstream branch of libreoffice is EOL and us switching to an unofficial branch with fixes, I think we no longer fit this policy. We can put certain level of trust to upstream developers preparing upstream releases, by shifting trust to upstream we can skip certain parts of our SRU review and verification, simply assuming that - for instance - the bugfixes listed in the changes are accurate with what's actually in the tarball. I don't think we can say the same thing about a version that is officially EOL in the mind of upstream. We certainly can't blindly trust what's in that codebase, and therefore just running the usual 'autopkgtests' + usual test-case won't work from the SRU perspective, sadly.

In this case, I think I only see two options:
a) Switching users of focal to a non-EOL version of libreoffice. This would of course require much more testing (maybe even a call for testing from other users), but as you already mentioned on IRC: there is risk that user extensions would be broken by this. And I think regressing existing users might be a breach of policy as well... so I'm not sure we can pull this off.
b) Cherry-picking *single fixes* from the aforementioned MIMO branch, each fix having a separate test-case i.e. following the regular per-bugfix SRU policy.

I know this situation is not ideal, but I don't think we can realistically do much more. We can pull in more SRU members for comment though, maybe someone would have a better idea.