[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MirageOS-devel] Graduation Review: Windows PV Driver



Dear Community members,
please find attached (and in markdown, but without graphs) the case to graduate 
the Windows PV Driver project to become a mature project.
The process is two-stage
1: Community Review to  gather final feedback and input from the community - we 
are here. I propose to let this run for a week
2: Voting by Leadership Teams of mature projects (Hypervisor and XAPI) - if 
there is no substantial feedback by next Monday, I will ping the relevant 
people as part of this thread for a vote
Best Regards
Lars

Attachment: Windows PV Driver - Incubation.pdf
Description: Adobe PDF document


# Windows PV Driver - Case for Graduation

This document makes the case for graduation for the ​Windows PV Driver project​ 
(which
became an incubation project in June 2014). The criteria follow those outlined 
in
xenproject.org/governance.html

#### Graduation Review

The review is initiated by the project lead and follows the rules outlined in 
"Requesting
Reviews, Reviews and Voting". In essence the project lead makes a pitch to the
community, why the project should graduate. A project must fulfil the following
requirements before it can graduate:
* It follows the principles of openness, transparency and meritocracy
* It has delivered at least one functioning release of what it is aiming to 
deliver
* It has a public code line which shows active development and has mechanisms to
accept patches (and a history of accepting patches)
* It has a public mailing list that is active (as we get more experience we 
will add
some guidelines)
* It has a mechanism for users to raise bugs and for developers to work on bugs
* It has an active developer community (as we get more experience we will add
some guidelines). But things to look for are number of maintainers, different
organisations involved, number of users, etc.
* It has a project leadership team that resolves conflicts and participates in
cross-project decision making
* It adheres to the Xen Project governance as outlined in this document, or
documents areas where the sub-project differs
Other items to look at during the review (depending on project are):
* It has an up-to-date wiki and a core and group of people maintaining it
* It publishes regular builds and tests
* It promotes itself at events and on the blog
According to our governance, mature subprojects, must also document their 
development
process. Projects can deviate from the default as outlined in 
​xenproject.org/governance.html​,
but needs to document deviations.
The following section highlights, how the Graduation Review is initiated:


#### Requesting Reviews, Reviews and Voting

**Requesting Reviews:** ​ Project Proposal and Graduation Reviews are requested 
by the
(prospective) project lead of the project by contacting the community manager 
providing
the necessary documentation. An archivation review can be requested by any 
maintainer
of a mature project or by the Xen Project community manager. The community 
manager
will then publish relevant material on the respective mailing lists.
This document is the outcome of the engagement between Paul Durrant (project 
lead) and
Lars Kurth (community manager).

### Development Process and Deviations from the default

Roles are in line with the default: the project has maintainers as described in 
the
MAINTAINERS file of each git repository.
The Project Leadership Team is made up of maintainers and committers with Paul 
Durrant
the project lead and Ben Chalmers and Owen Smith being committers. The team 
follows the
conventions - in particular those related to decision making - laid out in the 
governance
document.
There is no security team, which is not a requirement.
The project follows a mailing list base review process, with DCO and a 
review-then-commit
pattern: an example can be found ​here​.
In summary: the project completely follows, and has been doing so since 
inception, the
conventions of the Hypervisor project, which are the default.

### Openness, Transparency, Meritocracy

Development of drivers is done in the open. That is, patch series are sent to 
the mailing list
for consideration before being applied to the code base. Subscription to the 
list is open to
anyone and comments from all subscribers are considered. Project decisions and 
personnel
decisions (such as nomination new maintainers) are made on the public mailing 
list.

### Codeline, Mailing Lists, Bugs

There are several git repositories which are accessible from
xenbits.xenproject.org/gitweb/?a=project_list;pf=pvdrivers/win


Technical discussions happen on ​win-pv-devel@​ : below can a list of major 
participants can
be found. Traffic on the list is stable, which given the maturity of the 
project, is expected.
Bugs are raised on ​win-pv-devel@​ (or sometimes on xen-devel@ or xen-users@), 
and then
addressed using the Hypervisor workflow.

### Build, Tests & Releases

Development builds of the Win PV Drivers are built by a Jenkins server when ​ 
_new patches_

#### are pushed into the repo ​ and build output can be found at 
​xenbits.xen.org/pvdrivers/win/

Development builds are not subject to automated test through OSSTEST. However 
Citrix
runs regular and very comprehensive automated testing on the latest
xenbits.xen.org/pvdrivers/win/​ stable branches (plus a small additional series 
of branding
related patches). Citrix also logo certifies the drivers distributed with 
XenServer and is
therefore motivated to make sure the source is maintained to a high standard 
such that logo
testing can be performed at short notice.
Amazon also have experienced Windows driver developers and do extensive 
automated and
manual tests on their own builds of the driver code. They have provided useful 
feedback as
well as some patches to fix issues that they have discovered in testing.
The project has delivered ​several releases​:
8.1.0: Released 2016-07-
8.2.0: Released 2017-02-
8.2.1: Released 2018-04-


Releases follow the same approach as in the Hypervisor project, with stable 
branches in git
repositories, release candidates and final releases. Releases follow 
approximately an annual
cadence.

### User and Developer Communities

**User community** ​ engagement on the mailing list has steadily increased 
since the creation
of the project, as the graphs below show

(^)
2014 2015 2016 2017
In 2014 and 2015, traffic came from a few major vendors (who most likely 
adopted the
drivers in their products which likely correlates to a spike of questions from 
specific vendors).
From 2016 most questions have been driven by community members which we could 
not
map to specific organizations. Interestingly, engagement with individuals 
(rather than
organisations) has increased in parallel with the project delivering signed 
drivers.
This indicates increasing adoption: unfortunately, we do not have usage 
confirmation by any
organizations besides AWS, Citrix and Invisible Things Labs (Qubes OS) are 
using our
drivers.
**Developer community** ​ engagement has grown from 0% to 4% by vendors outside 
of Citrix,
primarily submitting bug fixes. This is not surprising given the maturity and 
stability of these
drivers, which does not create a high need to make contributions to upstream. 
The biggest
contributions have come from ITL and AWS, as the diagram below shows.
(^)
ITL: change of around 6 K SLOK AWS: change of around 1 K SLOK


### Events, Blogs

The team presents about new developments and blogs whenever there are major new
developments: on average 1-2 per year.

## Summary/Recommendation

Assessment by Lars Kurth, Community Manager:

_Given the maturity of the drivers and thus limited need to fix issues or 
develop new features,
I would recommend to graduate the project. The project has shown increased user
engagement, adoption and delivered several releases which is consistent with a 
​ mature
project ​. I have no objections on grounds of process adherence, values and 
developer
community diversity and ​ propose to the project leadership teams of other 
mature
projects to agree to graduate the Windows PV Driver subproject​._

_Recommendations: ​ Given that ​ Windows PV Drivers ​ development today depends 
on 3rd
party testing, I would like to recommend a public discussion whether some 
testing of
Windows PV Drivers ​ in OSSTEST is feasible and desirable._



_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.