@GrahamcOfBorg test nextcloud.with-postgresql-and-redis nextcloud.with-mysql-and-memcached nextcloud.basic

Cherry picking commits should be done from the master branch. Or else we get dangling commit refs.

commit in the commit message looks correct to me.

Ah, the commit became part of master since the other PR was merged as is (and without rebase). It seems safer to me to start with a master commit than to assume the commit will be part of master in the future.

I think as a merger its always safe, when one knows they also merged the other PR before instead of using rebase/squash.

@bjornfor Having to wait for the merge of the other commit into master before starting this PR would have been a waste of time.
This way I could open two PRs to fix both branches within 5 minutes and I had no further action after starting the process.
Having to wait for the first PR would have meant that right now I'd be opening the 2nd PR and would probably have to wait another week to get this one merged, effectively doubling the turnaround time and being a bigger hassle for reviewers and mergers that need to act twice instead of just getting two notifications for the same time.

It only ever gets a problem if you would change your master PR after creating the backport.