Re: [MirageOS-devel] Graduation Review: Windows PV Driver

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel