Re: Graduation Review: Windows PV Driver

Re: Graduation Review: Windows PV Driver

[Lars Kurth]

The attachment is also at https://wiki.xenproject.org/images/c/cf/Windows_PV_Driver_-_Graduation_Proposal.pdf
Lars

> On 23 Apr 2018, at 18:14, Lars Kurth <lars.kurth@xenproject.org> wrote:
> 
> 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
> 
> <Windows PV Driver - Incubation.pdf>
> 
> # 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/mirageos-devel

Re: Graduation Review: Windows PV Driver

[George Dunlap]

On Mon, Apr 23, 2018 at 6:14 PM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
> ## 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._

+1 from me.  I think if this project doesn't make the cut, nothing will. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Graduation Review: Windows PV Driver

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] Graduation Review: Windows PV Driver"):
> On Mon, Apr 23, 2018 at 6:14 PM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
> > ## 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._
> 
> +1 from me.  I think if this project doesn't make the cut, nothing will. :-)

+1

I don't think the lack of testing in osstest is a blocker.  TBH the
level of community engagement with the current Windows tests in
osstest (which do not use any PV drivers) is rather weak.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Graduation Review: Windows PV Driver

[Lars Kurth]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

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 #2: Windows PV Driver - Incubation.pdf --]
[-- Type: application/pdf, Size: 436112 bytes --]

[-- Attachment #3: Type: text/plain, Size: 7876 bytes --]



# 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._




[-- Attachment #4: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel