 Hi, my name's Daniel Parange, and I'm here to give you a status report on the Libvert project covering the past year. Since the start of this calendar year, we've released nine versions of the Libvert project, and we're on course to do our usual 11 releases by the end of the year. We have a regular monthly release schedule, except for the start of the year when we have two releases six weeks apart. We've had 144 contributors to the releases this year, and of those 144, 87 of them have been new contributors to the project who haven't submitted any code before this calendar year. The releases comprise 4100 commits, and we estimate that by the end of this year, if the current rate continues, we'll have up to 5200. About 450 of those commits were sent by brand new contributors to the project. Those stats may sound great, but it's useful to look at them in historical context to see whether they were getting better or worse than the previous years. So if we take this graph of contributions to the Libvert project since it started in 2005, we can see a good healthy growth in the project for the first five or six years, and then it's kind of leveled out a bit at between 4,000 and 5,000 commits per year. We can see that the vast majority of the commits are from so-called old authors. These are people who've been contributing to Libvert for more than one year, and then we have a fairly consistent number of commits from new authors, which are people who have been contributing for less than one year. If we now look at the breakdown of the authors instead of the breakdown of commits, we can see there's generally a fairly even split between the long-term contributors and the new contributors. Last year, looking at this graph for 2019, we saw a dip in the new contributors for the four years between 2015 and 2019. It's good to see that this year the number of new contributors has picked up dramatically, and we'll talk a little bit about why that might be later in the presentation. Now the Libvert project comprises multiple Git repositories, and it might be interesting to see what the breakdown is for the different Git repositories. So first we'll look at just the core Libvert library. This is the main C library and the Libvert daemon, which is where the bulk of the project code lives. We can see there's not much difference in the split between new and old contributors versus the previous slide. There's still a fairly even split, and we can see there's a marked increase in the number of new contributors this year, which is great to see after a few years of declining contributors. We'll kind of back up towards our peak. Then if we look at the other Git repositories, this is principally the language bindings to the main C library. We can see there's a bit more variation from year to year, but again we've got a growth in new contributors this year. We're not up at the level where we were a few years ago, but this is to be expected because most of the language bindings are fairly mature. Once they've got full API coverage then the activity tends to tail off. This is to be expected to a large degree. What's happened in the project in the past year? First of all, we've adopted gitlab.com as the primary project infrastructure. This means moving the Git repositories off the Libvert.org server onto GitLab. The issue trackers have moved off the Red Hat bugzilla onto GitLab. The main Libvert website is now populated based on CI jobs running in GitLab. The main CI for testing the builds and unit tests of Libvert has moved off the CentOS Jenkins into GitLab. As you can see, the vast majority of the project infrastructure is now using GitLab as its platform. In switching to GitLab, we've also adopted a merge request workflow for a number of the repositories. We've rolled this out gradually and this now covers all of the repositories except for the main Libvert Git repository. All of the language bindings in particular are using the merge request workflow. This replaces the traditional email-based workflow that we've used prior to this year. The main Libvert.git repository will switch at a later date, hopefully in the not too distant future. The translation platform that Libvert uses has also changed. The Zanata project that Libvert used to use was abandoned by its maintainers. And so Fedora adopted the WebLate translation system. And since Libvert outsources its translations to the Fedora translation team, we've adopted WebLate as well. This has a nice property of integrating directly with GitLab. So whenever new translations come in, it opens merge requests on GitLab. And as a result, we now get accurate author attribution in the commits for translations as well. A big focus of the past year has been tackling technical debt. One of the most notable things has been the conversion of the build system to MISON. This means we've eliminated the majority of Shell, M4, Make, Autoconf, and Automake code from the project. As well as being a nicer build system to read and write, the MISON build system has led to a dramatic speed up in the build time for Libvert. On one of my development servers, the old Automake-based system would take around three minutes to do a complete build of Libvert. And now with the adoption of MISON, we've pretty much cut that in half to one and a half minutes. So that makes a big difference to developer productivity. The vast majority of the build scripts have been converted to Python 3. We've got a little bit of Perl code left, but the majority has been converted to Python. And support for Python 2 has been dropped at the same time. We adopted the GLIB project. And in doing so, we managed to remove the GNU-LIB code, which was a prerequisite for adopting MISON. We've also converted a large portion of our website documentation to the restructured text format. And we've also converted the manual pages to restructured text. In adopting the GLIB library, we have changed our memory management approach. We now use an abort on out of memory paradigm and use the GLIB allocation functions. We've also adopted use of the GCC or C-Lang extensions for automatic memory cleanup. Combined, these changes lead to code flow that's much easier to follow. We've got fewer memory leaks, and overall the code is more robust. Now looking at some of the big changes in the virtualization drivers, we have refactored the block device code in the QMU driver quite significantly. We now use the modern block dev approach to configuring QMU disks instead of the legacy drive approach. And this has an immediate benefit for all applications using Libvert, because they are transparently switched to the new block dev approach. And one of the notable things that this unlocks is support for new checkpoint or backup APIs in Libvert. The other thing we have enabled is support for firmware image auto-selection, which is useful when configuring UEFI firmware in Libvert. We've introduced support for Verteo FS, which is a modern alternative to the 9P file system pass-through. And we've got NIC teaming for a failover between assigned PCI devices and emulated NICs, which allows you to do live migration when you have PCI device assignment for NICs. In the secondary drivers, we've introduced support for NAT with IPv6 in our virtual network. We've removed the old HAL device driver, which has been obsolete on Linux for a long time, and we had kept it around for free BSD, but now we've removed it entirely. And Udev is our preferred device driver. We also have support for the creation of mediated devices, which goes along with support for mediated devices in the QMU driver. In the other hypervisor drivers, we have introduced support for QMU command line pass-through in the Zen driver. The Beehive driver for free BSD has gained support for many more configuration options. We've got new active contributions for the Hyper-V driver, which has been looking for a maintainer for quite a number of years now. And the VirtualBox driver has been updated to the 6.0 release APIs, and support for the older VirtualBox releases has been discontinued. And that is a good overall summary of the work that's gone on in the last year. The technical debt and modernization of the code is an ongoing effort that will continue into the next year, and we think this is leading to very nice improvements in the maintainability of Libvert and making it a more attractive project for contributors to participate in. And that concludes my presentation for today.