Xen Security Problem Response Process (v2.0 Proposal) (Archived)

This document is a marked up archived proposal of the security problem response process, covering discussions that have been conducted over the last few months. Changes are highlighted like this and deletions like this. The pevious version of this document can be found here.

Introduction

Computer systems have bugs. Currently recognised best practice for bugs with security implications is to notify significant downstream users in private; leave a reasonable interval for downstreams to respond and prepare updated software packages; then make public disclosure.

We want to encourage people to report bugs they find to us. Therefore we will treat with respect the requests of discoverers, or other vendors, who report problems to us.

Scope of this process

This process primarily covers the Xen Hypervisor Project. Vulnerabilties reported against other Xen Project teams will be handled on a best effort basis by the relevant Project Lead together with the Security Response Team.

Specific process

  1. We request that anyone who discovers a vulnerability in Xen Project software reports this by email to security (at) xenproject (dot) org. (This also covers the situation where an existing published changeset is retrospectively found to be a security fix)

  2. Immediately, and in parallel:

    1. Those of us on the Hypervisor team who are aware of the problem will notify security@xenproject if disclosure wasn't made there already.

    2. If the vulnerability is not already public, security@xenproject will negotiate with discoverer regarding embargo date and disclosure schedule. See below for detailed discussion.

  3. Furthermore, also in parallel:
      1. security@xenproject will check whether the discoverer, or other people already aware of the problem, have allocated a CVE number. If not, we will acquire a CVE candidate number ourselves, and make sure that everyone who is aware of the problem is also aware of the CVE number.

      2. If we think other software systems (for example, competing hypervisor systems) are likely to be affected by the same vulnerability, we will try to make those other projects aware of the problem and include them in the advisory preparation process.

    (This may rely on the other project(s) having documented and responsive security contact points)

    1. We will prepare or check patch(es) which fix the vulnerability. This would ideally include all relevant backports. Patches will be tightly targeted on fixing the specific security vulnerability in the smallest, simplest and most reliable way. Where necessary domain specific experts within the community will be brought in to help with patch preparation.

    2. We will determine which systems/configurations/versions are vulnerable, and what the impact of the vulnerability is. Depending on the nature of the vulnerability this may involve sharing information about the vulnerability (in confidence, if the issue is embargoed) with hardware vendors and/or other software projects.

    3. We will write a Xen advisory including information from (b)-(f)

  4. Advisory pre-release:

    This occurs only if the advisory is embargoed (ie, the problem is not already public):

    As soon as our advisory is available, we will send it, including patches, to members of the Xen security pre-disclosure list. For more information about this list, see below.

    At this stage the advisory will be clearly marked with the embargo date.

  5. Advisory public release:

    At the embargo date we will publish the advisory, and push bugfix changesets to public revision control trees.

    Public advisories will be posted to xen-devel, xen-users and xen-annnounce and will be added to the Security Announcements wiki page. Copies will also be sent to the pre-disclosure list. unless the advisory was already sent there previously during the embargo period and has not been updated since.

  6. Updates

    If new information or better patches become available, or we discover mistakes, we may issue an amended (revision 2 or later) public advisory. This will also be sent to the pre-disclosure list.

  7. Post embargo transparency:

    During an embargo period the Security Response Team may be required to make potentially controverial decisions in private, since they cannot confer with the community without breaking the embargo. The Security Response Team will attempt to make such decisions following the guidance of this document and where necessary their own best judgement. Following the embargo period any such decisions will be disclosed to the community in the interests of transparency and to help provide guidance should a similar decision be required in the future.

Embargo and disclosure schedule

If a vulnerability is not already public, we would like to notify significant distributors and operators of Xen so that they can prepare patched software in advance. This will help minimise the degree to which there are Xen users who are vulnerable but can't get patches.

As discussed, we will negotiate with discoverers about disclosure schedule. Our usual starting point for that negotiation, unless there are reasons to diverge from this, would be:

  1. One working week between notification arriving at security@xenproject and the issue of our own advisory to our predisclosure list. We will use this time to gather information and prepare our advisory, including required patches.

  2. Two working weeks between issue of our advisory to our predisclosure list and publication.

When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honour such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honour the date specified by the discoverer.

Naturally, if a vulnerability is being exploited in the wild we will make immediately public release of the advisory and patch(es) and expect others to do likewise.

Pre-disclosure list

The Xen Project operates a pre-disclosure list. This list contains the email addresses (ideally, role addresses) of the security response teams for significant Xen operators and distributors.

This includes:

  • Large-scale Public hosting providers;
  • Large-scale organisational users of Xen;
  • Vendors of widely-deployed Xen-based systems;
  • Distributors of widely-deployed operating systems with Xen support.

This includes both corporations and community institutions.

Here "provider", "vendor", and "distributor" is meant to include anyone who is making a genuine service, available to the public, whether for a fee or gratis. For projects providing a service for a fee, the rule of thumb of "genuine" is that you are offering services which people are purchasing. For gratis projects, the rule of thumb for "genuine" is measured in terms of the amount of time committed to providing the service. For instance, a software project which has 2-3 active developers, each of whom spend 3-4 hours per week doing development, is very likely to be accepted; whereas a project with a single developer who spends a few hours a month will most likey be rejected.

For organizational users, a rule of thumb is that "large scale" means an installed base of 300,000 or more Xen guests. Other well-established organisations with a mature security response process will be considered on a case-by-case basis.

The list of entities on the pre-disclosure list is public. (Just the list of projects and organisations, not the actual email addresses.)

If there is an embargo, the pre-disclosure list will receive copies of the advisory and patches, with a clearly marked embargo date, as soon as they are available. The pre-disclosure list will also receive copies of public advisories when they are first issued or updated

Organizations on the pre-disclosure list are expected to maintain the confidentiality of the vulnerability up to the embargo date which security@xenproject have agreed with the discoverer, and are committing to ensuring that any members/employees of that organisation who come into contact with confidential information will do so as well..

Specifically, prior to the embargo date, pre-disclosure list members should not make available, even to their own customers and partners:

  • the Xen Project advisory
  • their own advisory
  • the impact, scope, set of vulnerable systems or the nature of the vulnerability
  • revision control commits which are a fix for the problem
  • patched software (even in binary form) without prior consultation with security@xenproject and/or the discoverer.

List members are allowed to make available to their users only the following:

  • The existance of an issue
  • The assigned XSA and CVE numbers
  • The planned disclosure date

Organisations who meet the criteria should contact security@xenproject if they wish to receive pre-disclosure of advisories. Please include in the e-mail:

  • The name of your organization
  • A brief description of why you fit the criteria, along with evidence to support the claim
  • A security alias e-mail address (no personal addresses -- see below)
  • A link to a web page with your security policy statement
  • A statement to the effect that you have read this policy and agree to abide by the terms for inclusion in the list, specifically the requirements to regarding confidentiality during an embargo period
  • Evidence that will be considered may include the following:
    • If you are a public hosting provider, a link to a web page with your public rates
    • If you are a software provider, a link to a web page where your software can be downloaded or purchased
    • If you are an open-source project, a link to a mailing list archive and/or a version control repository demonstrating active development
    • A public key signed with a key which is in the PGP "strong set"

Organizations already on the list who do not have a security alias or have not sent a statement that they have read this policy and will abide by, it will be asked to do so. 

Organisations should not request subscription via the mailing list web interface, any such subscription requests will be rejected and ignored.

A role address (such as security@example.com) should be used for each organisation, rather than one or more individual's direct email address. This helps to ensure that changes of personnel do not end up effectively dropping an organisation from the list.

Organisations should not request subscription via the mailing list web interface, any such subscription requests will be rejected and ignored.

Normally we would prefer that a role address be used for each organisation, rather than one or more individual's direct email address. This helps to ensure that changes of personnel do not end up effectively dropping an organisation from the list.

The pre-disclosure list will also receive copies of public advisories when they are first issued or updated.

Organizations on the pre-disclosure list:

This is a list of organisations on the pre-disclosure list (not email addresses or internal business groups).

  • Amazon
  • CentOS
  • Citrix
  • Debian
  • Intel
  • Invisible Things Lab
  • Linode
  • Mageia
  • Novell
  • Oracle
  • Rackspace
  • Redhat
  • SuSE
  • Ubuntu
  • Xen Security Response Team
  • Xen 3.4 stable tree maintainer

Change History

  • v2.0 May 2013: Significant changes to the document
    • Expand eligibility of who can join the predisclosure list
    • Clarify definitions of who can join the predisclosure list
    • Clarify information that needs to be supplied when joining the predisclosure list
    • Change e-mail alias to security@xenproject
  • v1.6 Apr 2013: Added Mageia to predisclosure list
  • v1.5 Nov 2012: Added Invisible Things Lab to pre-disclosure list
  • v1.4 Oct 2012: Various minor updates
  • v1.3 Sept 2012: Added CentOS to pre-disclosure list
  • v1.2 Apr 2012: Added pre-disclosure list
  • v1.1 Feb 2012: Added link to Security Announcements wiki page
  • v1.0 Dec 2011: Intial document published after review

 

Security Policy v1.6 (Archived)

This is an archived version of the Security Problem Response Process..

Xen.org Security Problem Response Process

Computer systems have bugs. Currently recognised best practice for bugs with security implications is to notify significant downstream users in private; leave a reasonable interval for downstreams to respond and prepare updated software packages; then make public disclosure.

We want to encourage people to report bugs they find to us. Therefore we will treat with respect the requests of discoverers, or other vendors, who report problems to us.

Scope of this process

This process primarily covers the Xen Hypervisor Project. Vulnerabilties reported against other Xen.org projects will be handled on a best effort basis by the relevant Project Lead together with the security team.

Specific process

  1. We request that anyone who discovers a vulnerability in xenproject.org software reports this by email to security (at) xenproject (dot) org.

    (This also covers the situation where an existing published changeset is retrospectively found to be a security fix)

  2. Immediately, and in parallel:

    1. Those of us on the xenproject.org team who are aware of the problem will notify security@xenproject.org if disclosure wasn't made there already.

    2. If the vulnerability is not already public, security@xenproject.org will negotiate with discoverer regarding embargo date and disclosure schedule. See below for detailed discussion.

  3. Furthermore, also in parallel:
      1. security@xenproject.org will check whether the discoverer, or other people already aware of the problem, have allocated a CVE number. If not, we will acquire a CVE candidate number ourselves, and make sure that everyone who is aware of the problem is also aware of the CVE number.

      2. If we think other software systems (for example, competing hypervisor systems) are likely to be affected by the same vulnerability, we will try to make those other projects aware of the problem and include them in the advisory preparation process.

    (This may rely on the other project(s) having documented and responsive security contact points)

    1. We will prepare or check patch(es) which fix the vulnerability. This would ideally include all relevant backports. Patches will be tightly targeted on fixing the specific security vulnerability in the smallest, simplest and most reliable way. Where necessary domain specific experts within the community will be brought in to help with patch preparation.

    2. We will determine which systems/configurations/versions are vulnerable, and what the impact of the vulnerability is. Depending on the nature of the vulnerability this may involve sharing information about the vulnerability (in confidence, if the issue is embargoed) with hardware vendors and/or other software projects.

    3. We will write a Xen advisory including information from (b)-(f)

  4. Advisory pre-release:

    This occurs only if the advisory is embargoed (ie, the problem is not already public):

    As soon as our advisory is available, we will send it, including patches, to members of the Xen security pre-disclosure list. For more information about this list, see below.

    At this stage the advisory will be clearly marked with the embargo date.

  5. Advisory public release:

    At the embargo date we will publish the advisory, and push bugfix changesets to public revision control trees.

    Public advisories will be posted to xen-devel, xen-users and xen-annnounce and will be added to the Security Announcements wiki page.

    Copies will also be sent to the pre-disclosure list, unless the advisory was already sent there previously during the embargo period and has not been updated since.

  6. Updates

    If new information or better patches become available, or we discover mistakes, we may issue an amended (revision 2 or later) public advisory. This will also be sent to the pre-disclosure list.

  7. Post embargo transparency:

    During an embargo period the XenProject.org security response team may be required to make potentially controverial decisions in private, since they cannot confer with the community without breaking the embargo. The security team will attempt to make such decisions following the guidance of this document and where necessary their own best judgement. Following the embargo period any such decisions will be disclosed to the community in the interests of transparency and to help provide guidance should a similar decision be required in the future.

Embargo and disclosure schedule

If a vulnerability is not already public, we would like to notify significant distributors and operators of Xen so that they can prepare patched software in advance. This will help minimise the degree to which there are Xen users who are vulnerable but can't get patches.

As discussed, we will negotiate with discoverers about disclosure schedule. Our usual starting point for that negotiation, unless there are reasons to diverge from this, would be:

  1. One working week between notification arriving at security@xenproject.org and the issue of our own advisory to our predisclosure list. We will use this time to gather information and prepare our advisory, including required patches.

  2. Two working weeks between issue of our advisory to our predisclosure list and publication.

When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honour such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honour the date specified by the discoverer.

Naturally, if a vulnerability is being exploited in the wild we will make immediately public release of the advisory and patch(es) and expect others to do likewise.

Pre-disclosure list

XenProject.org operates a pre-disclosure list. This list contains the email addresses (ideally, role addresses) of the security response teams for significant Xen operators and distributors.

This includes:

  • Large-scale hosting providers;
  • Large-scale organisational users of Xen;
  • Vendors of widely-deployed Xen-based systems;
  • Distributors of widely-deployed operating systems with Xen support.

This includes both corporations and community institutions.

Here as a rule of thumb "large scale" and "widely deployed" means an installed base of 300,000 or more Xen guests; other well-established organisations with a mature security response process will be considered on a case-by-case basis.

The list of entities on the pre-disclosure list is public. (Just the list of projects and organisations, not the actual email addresses.)

Pre-disclosure list members are expected to maintain the confidentiality of the vulnerability up to the embargo date which security@xenproject.org have agreed with the discoverer.

Specifically, prior to the embargo date, pre-disclosure list members should not make available, even to their own customers and partners:

  • the XenProject.org advisory
  • their own advisory
  • the impact, scope, set of vulnerable systems or the nature of the vulnerability
  • revision control commits which are a fix for the problem
  • patched software (even in binary form) without prior consultation with security@xenproject.org and/or the discoverer.

List members are allowed to make available to their users only the following:

  • The existence of an issue
  • The assigned XSA and CVE numbers
  • The planned disclosure date

Organisations who meet the criteria should contact security@xenproject.org if they wish to receive pre-disclosure of advisories. Organisations should not request subscription via the mailing list web interface, any such subscription requests will be rejected and ignored.

Normally we would prefer that a role address be used for each organisation, rather than one or more individual's direct email address. This helps to ensure that changes of personnel do not end up effectively dropping an organisation from the list

The pre-disclosure list will also receive copies of public advisories when they are first issued or updated.

Organizations on the pre-disclosure list:

This is a list of organisations on the pre-disclosure list (not email addresses or internal business groups).

  • Amazon
  • CentOS
  • Citrix
  • Debian
  • Intel
  • Invisible Things Lab
  • Linode
  • Mageia
  • Novell
  • Oracle
  • Rackspace
  • Redhat
  • SuSE
  • Ubuntu
  • XenProject.org security response team
  • Xen 3.4 stable tree maintainer

Change History

  • Apr 2013: Added Mageia to predisclosure list
  • v1.5 Nov 2012: Added Invisible Things Lab to pre-disclosure list
  • v1.4 Oct 2012: Various minor updates
  • v1.3 Sept 2012: Added CentOS to pre-disclosure list
  • v1.2 Apr 2012: Added pre-disclosure list
  • v1.1 Feb 2012: Added link to Security Announcements wiki page
  • v1.0 Dec 2011: Intial document published after review

Governance v1.2 (Archived)

This document has been archived: a newer version is available here.

Goals

The goals of Xen.org Project Governance are to:

  • Create a set of minimum requirements for a project
  • Create a lightweight project life cycle that
    • leads the project to articulate its goals and how to achieve them
    • encourages desired behaviours (e.g. open development)
    • provides motivation for the project to succeed
    • leads to non-viable projects failing quickly
    • provides opportunities for other community member
  • Avoid bureaucracy, i.e. the life cycle should be as informal as possible
  • Encourage Xen related projects to be hosted on Xen.org rather than going elsewhere
  • Set clear expectations to vendors, upstream and downstream projects and community members

Principles

Openness

Xen.org is open to all and provides the same opportunity to all. Everyone participates with the same rules. There are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace.

Transparency

Project discussions, minutes, deliberations, project plans, plans for new features, and other artefacts are open, public, and easily accessible.

Meritocracy

Xen.org is a meritocracy. The more you contribute the more responsibility you will earn. Leadership roles in Xen are also merit-based and earned by peer acclaim.

Consensus Decision Making

Xen.org projects are normally auto-governing and driven by the people who volunteer for the job. This functions well for most cases. When more formal decision making and coordination is required, decisions are taken with a lazy consensus approach: a few positive votes with no negative vote are enough to get going.

Voting is done with numbers:

  • +1 : a positive vote
  • 0 : abstain, have no opinion
  • -1 : a negative vote

A negative vote should include an alternative proposal or a detailed explanation of the reasons for the negative vote. The project community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed.

Conflict Resolution

Refereeing

Xen.org projects are not democracies but meritocracies. In situations where there is disagreement on issues related to the day-to-day running of the project, Committers and Project Leads are expected to act as referees and make a decision on behalf of the community. Referees should however consider whether making a decision may be divisive and damaging for the community. In such cases, the committer community of the project can privately vote on an issue, giving the decision more weight.

Last Resort

In some rare cases, the lazy consensus approach may lead to the community being paralyzed. Thus, as a last resort when consensus cannot be achieved on a question internal to a project, the final decision will be made by a private majority vote amongst the committers and project lead. If the vote is tied, the project lead gets an extra vote to break the tie.

For questions that affect several projects, committers and project leads of mature projects will hold a private majority vote. If the vote is tied, the chairman of Xen.org will break the tie through a casting vote.

Roles

Maintainers

Maintainers own one or several components in the Xen tree. A maintainer reviews and approves changes that affect their components. It is a maintainer's prime responsibility to review, comment on, co-ordinate and accept patches from other community member's and to maintain the design cohesion of their components. Maintainers are listed in a MAINTAINERS file in the root of the source tree.

Committers

Committers are Maintainers that are allowed to commit changes into the source code repository. The committer acts on the wishes of the maintainers and applies changes that have been approved by the respective maintainer(s) to the source tree. Due to their status in the community, committers can also act as referees should disagreements amongst maintainers arise. Committers are listed on the project page (e.g. Xen HV project page).

Project Lead

Xen.org projects are managed by a Project Lead, who also is a committer of the project he/she leads. Project Leads are the public figurehead of the project and is responsible for the health of the project. Due to their status in the community, project leads can also act as referees should disagreements amongst committers of the project arise. The project lead typically also has write access to resources, such as the web page of a specific project.

Mentor

Younger projects may have a need for a mentor to help ensure that the project will be successful. Mentors are typically maintainers, project leads or other distinguished community members.

Sponsor

To form a new project on Xen.org, we require a sponsor to support the creation of the new project. A sponsor can be a project lead or committer of a mature project, a member of the Xen.org advisory board or the community manager. This ensures that a distinguished community member supports the idea behind the project.

Making Contributions

Making contributions in Xen follows the conventions as they are known in the Linux Kernel community. In summary contributions are made through patches that are reviewed by the community. Xen does not require community members to sign contribution or committer agreements. We do require contributors to sign contrinbutions using the sign-off feature of the code repository, following the same approach as the Linux Kernel does (see Developer Certificate Of Origin).

More information on making contributions can be found in the following documents:

Elections

Maintainer Elections

Developers who have earned the trust of maintainers (including the project lead) can be promoted to Maintainer. A two stage mechanism is used

  • Nomination: A maintainer should nominate himself by proposing a patch to the MAINTAINERS file or mailing a nomination to the project's mailing list. Alternatively another maintainer may nominate a community member. A nomination should explain the contributions of proposed maintainer to the project as well as a scope (set of owned components). Where the case is not obvious, evidence such as specific patches and other evidence supporting the nomination should be cited.
  • Confirmation: Normally, there is no need for a direct election to confirm a new maintainer. Discussion should happen on the mailing list using the principles of consensus decision making. If there is disagreement or doubt, the project lead or a committer should ask the community manager to arrange a more formal vote.

Committer Elections

Developers who have earned the trust of committers in their project (including the project lead) can through election be promoted to Committer. A two stage mechanism is used

  • Nomination: A committers should nominate a community member publicly explaining the candidate's contributions to the project and thus why they should be elected as a maintainer on the project's public mailing list. The nomination should include a project, cite evidence such as patches and other contributions where the case is not obvious.
  • Election: A committer will be elected using the decision making process outlined earlier. Voting will be done by committers for that project privately using a voting form that is created by the community manager. Should there be a negative vote the project lead and community manager will try and resolve the situation and reach consensus. Results will be published on the public mailing list.

Project Lead Elections

Projects which lose their project lead are at risk of failing. Should this occur, the project's maintainer community should agree who would want to be/be able to be the new project lead and follow the election process as outlined above.

Project Governance

Basic Project Life Cycle

The proposal is to follow a simple basic flow:

governance-xen projectstages

A project starts with an idea which through the process of project formation will grow into a project proposal. The project proposal will need to satisfy some basic conditions, will be put out for community review and is then put to a vote to all maintainers and project leads of mature Xen.org projects following the usual decision making process.

For agreed project proposals Xen.org will provide basic infrastructure and the project can get started. Projects in incubation are working towards a set of goals, will get additional support and marketing opportunities from Xen.org. However there will also be regular checkpoints to see whether the project is progressing. Should it turn out that a project is not viable any more, it will be archived after an archivation review and vote. For a project to graduate, some basic conditions must be satisfied. If a project in incubation has achieved the point where it believes it is mature enough to graduate, it can request a Graduation community review followed by a vote.

Mature projects are pretty much expected to run themselves. However at some point a mature project will lose momentum and developers. If this is the case the Xen.org community can request an archivation review, which follows the usual pattern.

Archivation reviews have two purposes:

  • give somebody in the community an opportunity to step up and continue a project,
  • archive the project outcomes such that they are still available to people who want to use them, but promotion of such projects will cease.

It is also possible to revive archived projects. However these are treated almost like new projects as projects would only be archived if they have become inactive.

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.org community manager. The community manager will then publish relevant material on the respective mailing lists.

Reviews: These are off-line reviews which are open to all community members by which a proposal is published for review. The purpose of the review is two-fold:

  • gather final feedback and input from the community (it is good practice to informally do this before the review),
  • advertise the project with the aim to attract interest, users and contributors.

After a review, the requester of the review may decide to withdraw, request a re-review or progress to a vote by arranging with the community manager.

Voting: The community manager arranges a timed private vote as outlined above (voting should be open for a minimum of a week). Any maintainer of a mature project and the Xen.org community manager is allowed to vote. Voting follows the conventions as laid out in "Principle: Consensus Decision Making".

Forming a Project

Requirements for forming a Xen.org project:

  • A project needs a lead, who is willing to become the project lead of the project
  • A project needs a sponsor, which can be a project lead of a mature project, a member of the Xen.org advisory board or the community manager
  • There should be no dissent from other community members who would qualify as sponsor (see "Principle: Consensus Decision Making")
  • A project needs a mentor, which can be the project sponsor or a maintainer of a mature project
  • A project needs to have a relationship to other Xen.org projects, i.e. it aims to develop software that has a dependency on other Xen.org projects. If the project needs components in other Xen.org projects to work, then this should also be stated.
  • A project needs to be large and long-term enough to grant a separate project. For example adding support for a new CPU architecture, adding additional functionality on top of existing projects, etc. Adding a new feature to an existing project should be performed within an existing project.
  • A project will deliver code using a license that is compatible with other Xen.org projects (ideally GPLv2).

The purpose of the project formation phase is to work out what the project is about, get community buy-in and help the future project gain publicity and momentum. The formation phase is driven by the project lead. The project mentor's role is to advise and support the project lead in getting the project started.

The project proposal is a document that describes and is published on wiki.xen.org:

  • What the project is aiming to achieve (i.e. the project charter and project goals)
  • What components/code and in which code lines (new or components in other projects) the project aims to deliver
  • Key dependencies on other Xen.org projects (if applicable)
  • Lists initial maintainers (if applicable)
  • Lists any interested parties in the project (if applicable)
  • Lists any planned initial code contributions (if applicable)
  • A rough plan on how to get through the Incubation phase

Project Proposal Review

The review is initiated by the project lead and follows the rules outlined in "Requesting Reviews, Reviews and Voting".

After a successful review, the following resources will be created for the project:

  • A mailing list
  • A codeline
  • A project portal on Xen.org (in an area separate from mature projects)
  • A wiki page on wiki.xen.org (this is expected to be maintained by the project lead)

Incubating a Project

The purpose of the incubation phase is for a project to show that it is gathering momentum and adheres to the "Principles & Roles" of Xen.org projects. The project mentor will work closely with the project lead and there are at least quarterly informal review meetings with the mentor on how the project is doing. Should a mentor not be able to fulfil his/her role any more, it is the responsibility of the project lead to find another mentor. We advise that the project lead gives at least quarterly updates on the Xen.org blog on how the project is doing.

Xen.org will provide support to incubating projects. The project lead will work closely with the Xen.org community manager as well as with the project mentor.

Archiving an Incubating project

The mentor can request for a project to be archived, if the project is not making sufficient progress. See "archivation review".

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.

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

Mature Projects

Mature projects are expected to be run and promote themselves. The project lead has significant responsibility in ensuring that this happens. Xen.org and the community manager will help organize events, provide opportunities for the project to get new contributors and build a community, promote new releases on the blog and to the press, work with project members, etc. However Xen.org and the community manager will not get involved in the day-to-day running of the project.

At some point during its life cycle a project may lose momentum. In other words developers and users are not interested in the project any more. If this is the case, it may be time to archive the project. If the project has achieved its goals and is thus completed, it may also be time to archive the project.

Archivation Review

These can happen in a number of situations:

  • An incubation project shows clear signs of failing and not progressing
  • A mature project has lost its developer and user base (and there is little or no activity)
  • The project has achieved its goals and/or fulfilled its charter: in other words it has completed

In the first case the review is triggered by the incubation project's mentor. Failing this the review can be requested by any maintainer of a mature project (including the projec's lead) or by the Xen.org community manager. See "Requesting Reviews, Reviews and Voting".

The review is essentially a pitch why the project should be archived. The purpose of the review is not necessarily to archive a project, but also to provide a last opportunity for interested parties in the Xen.org community to save the project and step up. The Xen.org community manager will support efforts to save the project, should community members want to step up. There is the special case that a project has been completed: in this case the normal situation would be for the project lead to make the case, why this is so.

Archived Projects

When a project is archived the following happens:

  • The codeline and mailing list will be made read-only and made accessible from an archived projects section on Xen.org
  • The project's wiki pages will be tagged as archived. A project may be completed (i.e. it has achieved its goals and/or fulfilled its charter) in which case it is tagged as completed and archived.
  • The project portal on Xen.org will be moved into an Archive section. We may have a Completed section within the Archive section.

In cases where the project has delivered code into other Xen.org projects, the code will be

  • Deprecated at the point where the project is archived
  • The project which now contains the archived code can (but does not have to) remove the code in a subsequent release (it should however give users sufficient time to adapt)

Exceptional Circumstances

Projects without Project Lead

Projects which lose their project lead during the incubation or maturity phase are at risk of failing. Should this occur, the project's maintainer community should agree who would want to be/be able to be the new project lead and follow the election process as outlined in "Electing Maintainers".

If a project lead leaves during the formation phase, without finding a successor we assume that the project does not have enough momentum and will not go ahead.

Incubation projects without Mentor

Should an incubation project lose its mentor, the Xen.org community manager will support the project lead in finding a new mentor.

Change History

  • v1.0 Jun 2011: Intial document approved
  • v1.1 Oct 2011: Minor changes
    • Clarified the roles of Committer and Maintainer.
    • Added Making Contributions which contains links to other documentation and highlights that Xen.org required a DCO for contributions since 2005.
  • v1.2 May 2012: Minor changes
    • Fixed typo and ambiguity in the role of Project Lead.
    • Added section on Conflict Resolution.