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

Christophe de Dinechin cdupontd at redhat.com
Thu Feb 28 08:48:53 UTC 2019



> On 27 Feb 2019, at 13:49, Peng, Chao P <chao.p.peng at intel.com> wrote:
> 
> 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.

I understand your concern, but I also disagree about the “single binary” approach. As other have already said, I think the objective is to make crates that are reusable in a variety of binaries. That’s a good way to identify parts that are reusable, and parts that are “details of the implementation”. As a matter of fact, I think it would be interesting to start thinking about small binaries that we could start working on “right away”, i.e. things that could work using only, say, the memory-model crate.

The whole rust-vmm project also builds on a lot of earlier designs, experiments and experience. As a result, core design concepts are already “just there” simply by citation. For example, the memory-model crate currently being defined began as a simple extraction of existing code by Jiang. Paolo then started doing a lot of heavy lifting to isolate generic code and concepts. To me, discussing design changes based on real code proposals such as this is an effective way to move forward.

> 
> 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…

What I wrote above does not imply that it’s not a good time to talk about processes and documentation. In particular, Rust brings a lot of things in terms of testing, we should leverage that. Similarly, Rust has a clean approach to modularity, and writing code that is idiomatic in that respect seems quite important. Do we need more about “how to divide the crates”? I’m not sure we do, and I’m not sure we really can at this stage.

As an example, Paolo’s current work takes advantage of generic traits as a mechanism to delineate common interfaces that, to a large extent, match an existing implementation. To me, this looks really promising (as in "forward-looking”). I was reviewing Jiang’s code when Paolo shared his intent to go that way, and as soon as he said it, it seemed “obvious” to me that it was the right choice.

Of course, I understand that doing a larger redesign like this may cause more disruption if we want to reintegrate these changes in existing projects. But that’s precisely how we can discuss the trade-offs wrt. “how to abstract the common code”, I believe.

So I completely agree that we should document what we are doing, but I think it makes sense to document it while we are doing it, for example by reviewing design changes that are currently being proposed, by trying to build small tools around them to see if the interface is lacking in some respect, etc.

In a later reply, you also wrote:
> As an example, let's say, we will have all the device emulation in one crate, one may argue this can't satisfy their requirement since they want to configure their own device combination.  Then let's say, on the other hand, we have a design that each device being a standalone crate. Oh, this is crazy, I guess we will have crate pollution and crate dependency issue. So the right design will be likely a balance between the two. Then in which granularity can we build our device crates? I have no answer,  may PCI-related device in one crate or something else for example. At this point the clear requirement should help us on getting the answer.

I completely agree with the example and the related concern. On the other hand, I think this is precisely the kind of problem that we are likely to expose by testing and reviewing code more than by writing specifications ahead of time.

> 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
> _______________________________________________
> 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