docs/setup_new_repo: add some staging guidelines #153
Conversation
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. Signed-off-by: Alex Bennée <[email protected]>
|
referencing #133 (comment): |
Good point! I would be in favor, but maybe with restrictions, for example we could allow only |
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. |
Also sounds reasonable to me. I got no strong opinion here. |
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. |
Let's discuss that on the other ticket :) |
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:
git commit -s), and the commitmessage has max 60 characters for the summary and max 75 characters for each
description line.
test.
Release" section of CHANGELOG.md (if no such section exists, please create one).
unsafecode is properly documented.