Comment 11 for bug 1959757

IIUC, SRU team members are reluctant to risk regressing this package today in order to fix the FTBFS now. And the security team are reluctant to leave it as-is because that makes a potential future security update difficult, and are wondering about risking that same regression in the security pocket instead.

But it strikes me that these two considerations don't directly oppose one another. What if we (SRU team) accept this into the proposed pocket today, and then stage it there without releasing it?

A future security update would then be easy, and at that stage the regression risk would be justified by the need for it.

In the meantime, users will have plenty of "notice" to alert us about regressions in advance. If they don't, and get a regression at the time of the security update anyway, then it doesn't really change the risk to them since the security update would have required us to take the risk anyway.

One catch: users may prefer to take the risk now, rather than at the time of the security update, since then if it goes wrong then they can revert without also being security-exposed by doing so.

But anyway, maybe worth considering? Or maybe the catch is significant and so we should take the risk now?

If the security team decide they want to release all the way to the security+update pockets right now for security reasons, then we should let them take the lead and make decisions on this but push it through the SRU process for better visibility. So if you choose to do that, please fully review to the extent you think appropriate, and then give your security +1 to accept this into -proposed (and later into -updates if you want), and I'll just do that wearing my SRU hat but without any further consideration or review. I say this because you (very appropriately) have the decision making power and authority to push this into the security pocket anyway, but in this case doing it through proposed/updates would probably be better for everyone.