docs/setup_new_repo: add some staging guidelines

[stsquad]

We have introduced a staging area in vhost-device to facilitate the development of pre-production code alongside the wider project. Lets formalise the approach with some guidelines for how staging areas should operate in rust-vmm.

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR are signed (with git commit -s), and the commit
  message has max 60 characters for the summary and max 75 characters for each
  description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• [n/a] All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• [n/a] Any newly added unsafe code is properly documented.

[Ablu]

referencing #133 (comment):
Do we want to allow public releases to crates.io for libraries under staging? 🤔

[stefano-garzarella]

LGTM!

I just wonder if it makes sense to add links to vhost-device as an example to follow (even for CI part using custom-pipelines)

[stefano-garzarella]

referencing #133 (comment): Do we want to allow public releases to crates.io for libraries under staging? 🤔

Good point!

I would be in favor, but maybe with restrictions, for example we could allow only 0.0.z releases when a crate is in staging and allow 0.1.0 only after it has been promoted.

[stsquad]

referencing #133 (comment): Do we want to allow public releases to crates.io for libraries under staging? 🤔

I guess there is more of an argument for libraries (we explicitly said no for binaries). However what does it gain? It's not like its hard to import a crate from a git tree.

[Ablu]

referencing #133 (comment): Do we want to allow public releases to crates.io for libraries under staging? 🤔

I guess there is more of an argument for libraries (we explicitly said no for binaries). However what does it gain? It's not like its hard to import a crate from a git tree.

Yep. I think I agree.

But I think this probably rules this out as a mechanism for vhost-user-frontend. There we probably want a release so that cloud-hypervisor can switch over.

[Ablu]

I would be in favor, but maybe with restrictions, for example we could allow only 0.0.z releases when a crate is in staging and allow 0.1.0 only after it has been promoted.

Also sounds reasonable to me. I got no strong opinion here.

[stsquad]

referencing #133 (comment): Do we want to allow public releases to crates.io for libraries under staging? 🤔

I guess there is more of an argument for libraries (we explicitly said no for binaries). However what does it gain? It's not like its hard to import a crate from a git tree.

Yep. I think I agree.

But I think this probably rules this out as a mechanism for vhost-user-frontend. There we probably want a release so that cloud-hypervisor can switch over.

Does cloud-hypervisor want to switch over given we are going to immediately start making changes and updates? I would have thought they could track via git trees if they are interested in testing where the changes go and then just switch when we get to production state?

If we publish an initial release they will still have the pain if there are API changes between 0.1 and 0.2.

[Ablu]

Does cloud-hypervisor want to switch over given we are going to immediately start making changes and updates? I would have thought they could track via git trees if they are interested in testing where the changes go and then just switch when we get to production state?

Let's discuss that on the other ticket :)