Mailing List Archive

Re: Graduation Review: Windows PV Driver
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._
>
>
>


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