Xen Project Developer & Design Summit

In this talk, we will give an overview of the state of the Xen Project, trends that impact the project, see whether challenges that surfaced last year have been addressed and how we did it, and highlight new challenges and solutions for the coming year.

Note that I am waiting for a short description of the talk.

If you are new to the Xen community and want to know how the development process works -- and in particular, if you want to know how you can get your changes in -- this talk is for you. My goal is that by the end you will have a framework for how the process works, and a good set of pointers and principles for being ready to dive in and submit your first patch -- or your first series. Topics will include: What's a maintainer? How does the development window and feature freeze work? How do I make a good patch series? What if I'm not sure if my code is a good idea or not? What if I need to make a big change and I'm not sure the correct approach?

This session is intended to tackle a number of community issues:

Code Review: Patch Volume vs Review Bandwidth
Patch volume has been increasing recently (from 4.8 to 4.9 it grew by 30%) can be quite high, and review bandwidth often does not cope. This has been an ongoing problem, and we have looked measuring (see https://xen.biterg.io), improved efficiency and encouraging community members to review more. Although these measures have been successful (some more than others) and more people do reviews and reviews seem to be working more effectively, review bandwith has not grown at the same rate as patch volume.

We are seeing clear bottlecks in ARM and x86 code, where the number of contributions (and new contributors) has grown and is expected to grow further. This is obviously a problem. 

Most options to address this would incur either undesirable restrictions (after all we want people to contribute), but without taking some measures the inflow is going to remain (almost) unmanageable.

This is an open session to look at all available options.

x86 Community Meeting (or other community meetings)
Currently we have a monthly ARM Community Meeting, which has been very successful. Should we have any more? I have had interest for x86 related meetings. Any others? 

A communiuty meeting requires a meeting chair who will a) reach out to attendees, b) put together the agenda, c) write up and post minutes to xen-devel@ and d) chair the meeting

Gandi.net is a cloud provider running about 10000 VMs since 2008. We recently updated our infrastructure from Xen 4.1 to Xen 4.8 and decided to move all of our platform to Xen (from a mix of Xen and KVM). This plaform uses home-made code based on Xen python bindings and xl to orchestrate VMs. This talk will present our use cases and the experience we had with Xen, the shortcomings or issues we had while upgrading our platform, what features we use, and present some new features we would like to have in Xen. For example, it will discuss how we use live patching and live migration. The talk will consider both the Xen hypervisor and its associated userspace utilities.

Ten years ago, Xen was an open-source software challenger to incumbent VMware. Today, VMware is owned by a hardware OEM, virtualization hardware extensions are widely available in modern x86 and ARM CPUs, and Xen competes for developer attention with OS-bundled hypervisors and container namespaces. This presentation offers a structured approach for developers to communicate the business benefits of Xen-based virtualization to product management and investors.

The Xen Project has in-principle agreement to become a CVE Numbering Authority. However to do this, we need to define the scope of the CNA. A number of have worked on this, but we need some community inout.

Consolidate Security Coverage Documents
Consolidate security coverage documents where possible (we have a proposal). Specifically

• Review the proposal (currently in a google doc - export attached) 
• Review the scope (currently in a google doc) - this may involve clarifying the supported status of some components 

Once we have agreement, we basically just need to document the outcome, publish it and get the process started.

Other Operational Issues

• Automated checking of XSAs against releases (see https://xenbits.xenproject.org/gitweb/?p=people/larsk/xen-release-scripts.git;a=summary)
• Usage of RT and issues that has caused => does it work, what to change?

Possible/Proposed Process Changes?

• Bundling of issues / once every other week or monthly XSA publication?
• Include maintainers on pre-disclosure when affected and not on security team