Benjamin Kampmann
c78c2892a4
* mark template and utils as non-publish * switch to development version for testing * activate unleash check * maybe if I disable all rules... * Fix isolated compilation of `max-encoded-len-derive` with `syn` error[E0369]: binary operation `==` cannot be applied to type `syn::Path` --> src/lib.rs:88:29 | 88 | .filter(|attr| attr.path == parse_quote!(max_encoded_len_crate)) | --------- ^^ ----------------------------------- _ | | | syn::Path error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. Error: could not compile `max-encoded-len-derive` * WIP: bump changes crates since v3 tag to next breaking cargo unleash version bump-breaking --changed-since v3.0.0 cargo unleash version set-pre dev --changed-since v3.0.0 FIXME: Don't modify crates that are not yet released, e.g. `max-encoded-len-derive` * Update lockfile * WIP: Bump sp-transaction-pool as well * WIP: Bump sp-offchain as well * WIP: Bump frame-system-rpc-runtime-api as well * WIP: Bump sp-authority-discovery as well * Manually deactivate dev-deps before `cargo unleash check` Otherwise we run into `Cycle detected` error. * Bump sp-consensus-slots * Add missing Cargo.lock change * Bump sp-consensus-vrf as well * Bump sp-keyring as well * Bump sp-consensus-pow as well * Try to speed up the `unleash-check` job Previously, the job took 106 minutes - let's see if explicitly specifying a `CARGO_TARGET_DIR` will help * fixup: Ensure the temp target dir exists for unleash check * Bump pallet-transaction-payment-rpc-runtime-api as well Needed for Polkadot * Bump pallet-transaction-payment-rpc as well Needed for Polkadot * Try updating crates after patching in the Polkadot CI job * Use another approach to update patched Substrate crates * Try to update all sp-core versions in Polkadot CI job * Simplify sp-core version checking * Apply another shellcheck lint * Just do the simplest thing I guess * Welp don't do --offline then * Clean up `unleash-check` job triggers Co-authored-by: Denis Pisarev <denis.pisarev@parity.io> * Fix a note in unleash-check cache step * Add a note about temporary optimization in cargo-unleash * Pin a newer version of cargo-unleash Co-authored-by: Igor Matuszewski <xanewok@gmail.com> Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
Collective system: Members of a set of account IDs can make their collective feelings known through dispatched calls from one of two specialized origins.
The membership can be provided in one of two ways: either directly, using the Root-dispatchable
function set_members, or indirectly, through implementing the ChangeMembers.
The pallet assumes that the amount of members stays at or below MaxMembers for its weight
calculations, but enforces this neither in set_members nor in change_members_sorted.
A "prime" member may be set to help determine the default vote behavior based on chain
config. If PrimeDefaultVote is used, the prime vote acts as the default vote in case of any
abstentions after the voting period. If MoreThanMajorityThenPrimeDefaultVote is used, then
abstentations will first follow the majority of the collective voting, and then the prime
member.
Voting happens through motions comprising a proposal (i.e. a dispatchable) plus a
number of approvals required for it to pass and be called. Motions are open for members to
vote on for a minimum period given by MotionDuration. As soon as the required number of
approvals is given, the motion is closed and executed. If the number of approvals is not reached
during the voting period, then close may be called by any account in order to force the end
the motion explicitly. If a prime member is defined, then their vote is used instead of any
abstentions and the proposal is executed if there are enough approvals counting the new votes.
If there are not, or if no prime member is set, then the motion is dropped without being executed.
License: Apache-2.0