[Rust-VMM] Proposal for contribution and crate approval process

[Peng, Chao P]

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.

Thanks,
Chao
> -----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