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

Zach Reizner zachr at google.com
Fri Mar 8 21:15:01 UTC 2019


On Fri, Mar 8, 2019 at 12:05 PM Matt Wilson <msw at linux.com> wrote:
>
> On Wed, Feb 20, 2019 at 02:25:56PM -0600, Jonathan Bryce wrote:
> > 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:
>
> Hi Jonathan,
>
> Thanks for writing this up, and for the infrastructure services from
> OpenDev. I have some thoughts about this that I'd like to share after
> a few disclosures:
>
> 1) I am an Amazon employee, and Amazon is contributing to rust-vmm
>    through the efforts of other employees. I have an interest in how
>    the rust-vmm community grows in that context.
> 2) I have not contributed code to rust-vmm, and I probably won't be
>    able to participate in things like community calls due to my
>    schedule.
> 3) My thoughts about how to foster open source communities that
>    I'm sharing today are my own, and do not represent the views of my
>    employer. Therefore I'm wearing my individual hat and sending this
>    from my msw at linux.com email address.
>
> > - 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)
>
> I think it is much too early to establish this level of process about
> governance, number of maintainers, approval process, etc. Before
> establishing rules like this, I encourage communities to have a
> transparent discussion about exactly what problems they (as a
> community) are trying to solve. Due to my understanding of the
> intended nature of rust-vmm crates, as building blocks that can be
> used in other VMMs, this community may embrace a more decentralized
> approach with smaller numbers of contributors, and healthy forking of
> projects if the needs of a "downstream" are not met in the "upstream."
I agree with your statement about it being too early to establish such
a high-level of governance. What you said about forking and
decentralized approaches certainly matches my observations so far.
>From my perspective, a decentralized fork (firecracker from crosvm) is
part of how this organization got started. I don't see any signs of
that stopping, as crosvm is starting to incorporate and modify
vhost-user pieces posted here in order to adapt it to our code base.
>
> There is no "one right way" to do open source. From past experience,
> we know of many successful patterns, and many anti-patterns. I have
> similar opinions about agile software development, and I encourage
> teams to discuss what works the best for them, rather than prescribing
> "you shall do agile development this way."
>
> I have found the most accessible way to have these discussions is via
> plain text email. Phone meetings and video conferences can be useful,
> but there are challenges in scheduling due to timezones and competing
> priorities. Additionally, they can exclude contributors that are
> unable to participate in speech based conversations. I encourage this
> emerging community to find what works well for the individuals who are
> showing up to collaborate, but be aware of who you may be
> unconsciously excluding.
I also agree with that. The phone calls are somewhat earlier than my
ordinary sleep schedule, which means I've only got to 2 of the last 3.
The only other crosvm representative has only been to the first phone
call.
>
> > - 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'm not sure what the overheads are here, having never done GitHub
> organization management. Again, my suggestion is to get experience
> with running the project before optimizing for a problem that might
> not exist.
>
> > 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.
>
> The idea that bootstrapping maintainers to reach a critical mass does
> not sit well with me. I would like to encourage a much more organic
> approach where natural leaders emerge based on their contributions
> establishing the direction and shared technology of a project.
>
> Finally, while things like logos are helpful promoting your project,
> it's probably not the first order of business. Nor is it the first
> order of business to obtain additional services from foundations. When
> I was a board member of Software Freedom Conservancy (of which QEMU is
> a member), and part of the Evaluation Committee considering
> applications to join, we established the following as part of the key
> criteria [1]:
>
>    * The project should have an existing, vibrant, diverse community that
>      develops and documents the software. For example, projects that
>      have been under development for less than a year or only a "proof
>      of concept" implementation are generally not eligible.
>
> Figure out who you are as a community, what problems you're trying to
> solve, and how you want to interact with one another as
> individuals. Creating a safe environment where people can collaborate
> and earn trust of one another should be a high priority.
I think this is a perfect take-away. A lot of us are just meeting each
other for the first time and it will take time for us to build up
trust with each other. That should be our first goal as a shared
organization.
>
> Make very intentional decisions here first. Experiment, double down on
> what works, and re-evaluate when things don't. Discuss it intently on
> a mailing list (... or don't, I do not have all of the answers here.)
>
> --msw
>
> [1] https://sfconservancy.org/projects/apply/
>
> _______________________________________________
> 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