[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,
> firecracker)
> - 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
> thoughts/feedback.
> 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.
> Thanks,
> Jonathan
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm

More information about the Rust-vmm mailing list