QgsBinaryWidgetWrapper: fix focus-related crash

[rouault]

Fixes #30210

[nyalldawson]

This new class could be used for the resource widget too, right?

[rouault]

This new class could be used for the resource widget too, right?

probably. Didn't want to go too far before checking if this approach was acceptable.

[rouault]

This new class could be used for the resource widget too, right?

PR implementing this in #36734

[rouault]

Question w.r.t backport bot: as this PR is made of several commits, which merge option should I use ?

[nyalldawson]

It doesn't really matter - I've started manually collecting backports in #36718 , where they wait until the next LTR release before merge. This way they get a full month in a stable release to avoid regressions in the LTR patch releases.

I personally prefer a linear git history with no merges, but @m-kuhn will fight me on that!

[rouault]

I've started manually collecting backports in #36718 , where they wait until the next LTR release before merge

hum, is this is a new general policy ? Should I still tag this PR with "backport release-3_10" ? Or if I do it, then the backport PR shouldn't be merged right away ?

[nyalldawson]

It's an informal policy @m-kuhn and I developed. I need to file a QEP and get it formally accepted.

The rough process is:

• make a backport pr (via the bot or not)
• tag it as "not for merge" and let the CI run over it
• when accepted, i'll either pick it up and move it to the general pending PR (to keep the queue clean), or just leave it in the "not for merge" state until the next LTR patch release occurs, at which stage all the pending ones will be merged

[rouault]

It's an informal policy @m-kuhn and I developed

ok, got it

[m-kuhn]

Technically it should be totally doable to create a fully working backport bot (a modernized version of the original one - the one we have grown to like so much - as github action), including cross-repository pull request support.