Problem: Runtime upgrades block pipelined high stakes proposals

[bedeho]

Background

The way high stakes proposals, such as changing max validator count or runtime upgrades, are made safe, is through having a high constitutionality (e.g. 4). The problem is that runtime upgrades in particular have the behavior of always emptying the proposal pool whenever they are executed, this means that any other high stakes proposal , such as another upgrade that was submitted after, will be removed, and thus fail. This means such proposals cannot be pipelined, but have to be run in sequence - one proposal is created after another has been executed. This will contribute very badly to latency in managing the system in a sensible way.

Proposal

Here are just a list of superficial ideas, deeper thinking is required to better understand whether each is sound, and what the tradeoffs are, and what other alternatives exist.

• Remove automated cleanup behaviour of runtime upgrades.
• Change proposal system to allow proposals to be marked as "not to be removed" by runtime upgrade cleanup.
• Runtime upgrade migration logic does the migration of proposals manually? (does this even work, unclear to me)
• All proposals are instead "disabled", some new state where they are just idle, and they have to be actively reactiveated.

[bwhm]

Comment moved to Issue #4655

[traumschule]

Please remind me what is the technical reason to auto-reject proposals on a new term?
By giving up on the current cleanup logic and allowing long-standing proposals to slip into a next term the first Council may keep a decision open for the second to decide. Would that be at all desirable?
This would also suggest longer lifetime for other types like Signals. According to my experience 3 days can be too short for a well-researched decision.