prepare orchestra crate publishing

[drahnr]

Prepare it to be published as an independent crate (all crates are reserved to avoid the squatting pitfal).

• metered-channel -> prioritized-metered-channel in prep for Avoid using unbounded channels for prioritization polkadot-sdk#824
• apply a definite version 0.0.1 for prioritized-metered-channel, orchestra and orchestra-proc-macro
• use metered = { package = "prioritized-metered-channel", .. } consistently

Note publishing with unleash is currently borked due to paritytech/cargo-unleash#77 , so the following should work but currently does not. One has to publish them one by one

cargo unleash version set 0.0.1 -p orchestra -p orchestra-proc-macro
cargo unleash em-dragons --dry-run -p orchestra -p orchestra-proc-macro -p prioritized-metered-channel

[sandreim]

Just one nit, otherwise LGTM!

Is this one flaky test or something really broke ?
thread 'tests::import_approval_bad' panicked at 'msg send timeout', node/network/approval-distribution/src/tests.rs:86:10

[drahnr]

Just one nit, otherwise LGTM!

Is this one flaky test or something really broke ? thread 'tests::import_approval_bad' panicked at 'msg send timeout', node/network/approval-distribution/src/tests.rs:86:10

Flaky test timeouts I assume, since no functionality was changed

[bkchr]

Why should they be published? What is the reasoning behind this?

[drahnr]

Why should they be published? What is the reasoning behind this?

It's been a long sought milestone, to give the "pattern" a clear interface boundary and not interleave polkadot specifics with the guts of the generated orchestra-code. In the past, things bled into one another, i.e. this whole Event and NetworkBridge message stuff was pulled into the Overseer where there was no need to do so, besides a minor dispatch benefit.

We don't want to repeat past mistakes, publishing is stage one, there should be a discussion to separate it into it's own repo eventually - but that's out of scope for this PR.

[bkchr]

I'm not sure how publishing will help with this. How often will this be updated on crates.io? How will take care to update it? What is the benefit of having it on crates.io? I mean if you want to separate it, fine, but crates.io doesn't solve this magically. Or is the expected working style then to first publish and integrate the changes in a new pr?

[drahnr]

I'm not sure how publishing will help with this. How often will this be updated on crates.io? How will take care to update it? What is the benefit of having it on crates.io? I mean if you want to separate it, fine, but crates.io doesn't solve this magically. Or is the expected working style then to first publish and integrate the changes in a new pr?

Publishing was a long standing nice-to-have goal ( CC @rphmeier ) since the it's actually completely independent of any polkadot specifics. @vstakhov will be taking care of the maintenance, and I'll be available for code review on for the foreseeable future.

Or is the expected working style then to first publish and integrate the changes in a new pr?

This has yet to be discussed, but in my books, that would be desirable mid-term.

[rphmeier]

Orchestra is a pretty stable component at this point, and as Bernhard says it deliberately avoids Polkadot specifics. This is code which doesn't need to change very often, although there will be a few changes over the next months as we work on optimizations in subsystem communication.

IMO we will really want this to be a library for the community to build parachains whose nodes also do custom DB and networking logic. I don't think publishing it on crates.io will cause any major issues, so we might as well.