[Rust-VMM] Proposal for contribution and crate approval process
Peng, Chao P
chao.p.peng at intel.com
Wed Feb 27 12:49:56 UTC 2019
Sounds like a good process to start with.
Meanwhile my feeling is that we need a high-level project-wide design first. The reason is that the creates are not really standalone projects. They are closely related and most likely they will form up a single binary from user' point of view. They should be well designed from the high-level at the very beginning.
To me, we'd better design the project from the user point of view: it's a single project as a whole. The division of the codes into creates is OK, but that's just kind of internal thing for the project. Also every designed creates should meet some release criteria otherwise a failure in one creates may result the failure of the whole project.
There are several things we can start with:
- Discuss #14(https://github.com/rust-vmm/community/issues/14) to come up a 'must have list' that will be included in the first release.
- Come up a project-wide high-level design. For example:
how to divide the creates
how to abstract the common code
how creates interact each other and come up possible traits definition
what interfaces we want to expose to users...
- Discuss how code/doc/test will be organized
- Define process/work flow/governance...
But even before those, we need understand and write down our requirement clearly so everybody involved will be on the same page.
Just my thoughts. Welcome for further discussion.
> -----Original Message-----
> From: Jonathan Bryce [mailto:jonathan at openstack.org]
> Sent: Thursday, February 21, 2019 4:26 AM
> To: rust-vmm at lists.opendev.org
> Subject: [Rust-VMM] Proposal for contribution and crate approval process
> Hi everyone,
> On the rust-vmm community meeting this morning there was a discussion about the approval process for new crates. From the
> discussion a basic proposal emerged:
> - Create a group of rust-vmm project-wide maintainers
> - Group size would start out with around 5 individuals
> - Maintainers should come from a variety of backgrounds and affiliations
> - Inclusion of a new crate would require approval from at least 3 maintainers
> - Maintainers should look for approval and feedback from multiple “consumer" communities (e.g. qemu, crosvm, kata,
> - As the number of crates scale, maintenance at the crate level would be distributed beyond the project-wide group to avoid
> overloading the project-wide maintainers or creating bottlenecks within individual crates
> I offered to write this up and post on the list to make sure everyone had a chance to see and comment on it, so please send your
> If this is agreeable as a process, we’ll need to bootstrap the initial set of maintainers. I have thoughts on that as well, but would love to
> hear others’ opinions too.
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org
More information about the Rust-vmm